Redis初识 ｜青训营

ZJHao
142 阅读6分钟

from: bytedance.feishu.cn/file/TcbGb6…
author: June
created: 2023-08-15 14:22
aliases: []
tags:

课程代码样例库： gitee.com/wedone/redi…

1. Redis 是什么

随着数据库业务的发展，1. 数据从单表演进出了分库分表；2. MySQL 从单机演进出了集群，这样数据量增大并且读写压力增大；3. 需要将数据分为热数据和冷数据，即经常被访问的数据和不经常被访问的数据。->计算机体系分层缓存思想，可将热数据存储到内存中。

所以 Redis 产生了：

  • 数据从内存中读写；
  • 数据保存到硬盘上防止重启数据丢失
    • 增量数据保存到 AOF 文件（Append Only File）
    • 全量数据 RDB 文件
  • 单线程处理所有操作命令

2. Redis 应用案例

1. 连续签到

分析数据：

Key: cc_uid_123456789 value: 252 expireAt: 后天的零点

使用合适的数据结构：String

可以存储字符串、数字、二进制数据 通常和 expire 配合使用 场景：存储计数，Session

2. 消息通知

用 List 作为消息队列
List数据结构：Quicklist，由一个双向列表和 listpack 实现\

3. 计数

一个用户有多项计数需求，可通过 hash 结构存储
Hash 数据结构：dict
一个优化技术: rehash 与 渐进式 rehash

  • rehash：rehash 操作是将 ht[0]中的数据，全部迁移到 ht[1]中。数据量小的场景下，直接将数据从 ht[0]拷贝到 ht[1]速度是较快的。数据量大的场景，例如存有上百万的 KV 时，迁移过程将会明显阻塞用户请求。
  • 渐进式 rehash：为避免出现这种情况，使用了 rehash 方案。基本原理就是，每次用户访问时都会迁移少量数据。将整个迁移过程，平摊到所有的访问用不请求过程中。

4. 排行榜

需求：积分变化后，排名要实时变更
操作：结合 dict 特性，通过 key 操作跳跃表(skiplist)的功能
zest 数据结构 zskiplist

5. 限流

需求：要求1秒内放行的请求为 N，超过 N 则禁止访问
数据：Key: comment_freq_limit_1671356046
操作：对这个 Key 调用 incr，超过限制 N 则禁止访问，1671356046 是当前时间戳

6. 分布式锁

需求：并发场景，要求一次只能有一个协程执行。执行完成后，其它等待中的协程才能执行。

数据：可以使用 redis 的 setnx 实现，利用了两个特性: 1. Redis 是单线程执行命令；2. setnx 只有未设置过才能执行成功。

3. Redis 使用注意事项

1. 大 Key，热 Key

大 Key

大 Key 的定义：

数据类型大Key标准
String类型value的字节数大于10KB即为大key
Hash/Set/Zset/list 等复杂数据结构类型元素个数大于5000个或总 value 字节数大于10MB 即为大 key

大 Key 的危害：

  • 读取成本高
  • 容易导致慢查询
  • 主从复制异常，服务堵塞

业务侧使用大 Key 的表现：请求 Redis 超时报错

解决办法：

  • 拆分：将大 key 拆分为小 key。例如一个 String 拆分成多个 String
    • eg：
KeyValue
拆分前article:70011abcdefghigklmnopqrst
拆分后article:70011[3][70011]abcdefg
article: 70011_2[70011]higklmn
article: 70011_3[70011]opqrst
  • 压缩：将 value 压缩后写入 redis，读取时解压后再使用。
    • 压缩算法可以是 gzip、snappy、lz4等。通常情况下，一个压缩算法压缩率高、则解压耗时就长。需要对实际数据进行测试后，选择一个合适的算法。
    • 如果存储的是 JSON 字符串，可以考虑使用 MessagePack 进行序列化。
  • 集合类结构 hash, list, set
    • 拆分：可以用hash取余、位掩码的方式决定放在哪个key中
    • 区分冷热：如榜单列表场景使用 zset，只缓存前10页数据，后续数据走 db

热 Key

热 Key 的定义：用户访问一个 Key 的 QPS 特别高，导致 Server 实例出现 CPU 负载突增或者不均的情况。没有明确的标准，QPS 超过500就有可能被识别为热 Key。

解决办法：

  • 设置 Localcache

    • 在访问 Redis 前，在业务服务侧设置 Localcache，降低访问 Redis 的 QPS。LocalCache 中缓存过期或未命中，则从 Redis 中将数据更新到 LocalCache。Java 的 Guava、Golang 的 Bigcache 就是这类 LocalCache。

  • 拆分

    • 将 key: value 这一个热 Key 复制写入多份，例如 key1: value, key2: value，访问的时候访问多个 key，但 value 是同一个，以此将 qps 分散到不同实例上，降低负载。代价是，更新时需要更新多个 key，存在数据短暂不一致的风险

  • 使用 Redis 代理的热 Key 承载能力

    • 字节跳动的 Redis 访问代理就具备热 Key 承载能力。本质上是结合了“热 Key 发现”、“LocalCache”两个功能

2. 慢查询场景

  1. 批量操作一次性传入过多的 key/value，如 mset/hmset/sadd/zadd 等 O (n)操作，建议单批次不要超过100，超过100之后性能下降明显。
  2. zset 大部分命令都是 O (log (n))，当大小超过5k 以上时，简单的 zadd/zrem 也可能导致慢查询
  3. 操作的单个 value 过大，超过10KB。也即，避免使用大 Key
  4. 对大 key 的 delete/expire 操作也可能导致慢查询，Redis4.0之前不支持异步删除 unlink，大 key 删除会阻塞 Redis

3. 缓存穿透，缓存雪崩

缓存穿透

定义：热点数据查询绕过缓存，直接查询数据库

危害：

  1. 查询一个一定不存在的数据：通常不会缓存不存在的数据，这类查询请求都会直接打到 db，如果有系统 bug 或人为攻击，那么容易导致db响应慢甚至宕机
  2. 缓存过期时：在高并发场景下，一个热 key 如果过期，会有大量请求同时击穿至 db，容易影响 db 性能和稳定。同一时间有大量 key 集中过期时，也会导致大量请求落到 db 上，导致查询变慢，甚至出现 db 无法响应新的查询

应对：

  1. 缓存空置：如一个不存在的 userID。这个 id 在缓存和数据库中都不存在。则可以缓存一个空值，下次再查缓存直接反空值
  2. 布隆过滤器：通过 bloom filter 算法来存储合法 Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量 key值

缓存雪崩

定义：大量缓存同时过期

应对：

  1. 缓存空值：将缓存失效时间分散开，比如在原有的失效时间基础上增加一个随机值，例如不同 Key 过期时间，可以设置为 10分1秒过期，10分23秒过期，10分8秒过期。单位秒部分就是随机时间，这样过期时间就分散了。对于热点数据，过期时间尽量设置得长一些，冷门的数据可以相对设置过期时间短一些
  2. 使用缓存集群，避免单机宕机造成的缓存雪崩
avatar
文章
阅读
粉丝