这是我参与「第五届青训营」伴学笔记创作活动的第 14 天。

1 Redis 简介

1.1 为什么需要Redis

数据库从单表，演进出了分库分表
MySQL从单机演进出了集群
- 数据量增长
- 读写数据压力的不断增加
数据分冷热
- 热数据：经常被访问到的数据
- 将热数据存储到内存中

1.2 Redis基本工作原理

数据从内存中读写
数据保存到硬盘上，防止重启税局丢失
- 增量数据保存到AOF文件（append only file）
- 全量数据RDB文件
单线程处理所有操作命令

2 Redis 应用案例

2.1 连续签到

每日连续签到：用户每日有一次签到机会，如果断签，连续签到计数归0

实现：

key: 与 user_id 唯一对应的字符串
value: 签到计数
expireAt（过期时间）：下一天的0点

Redis 的 Sting 数据结构

数据结构：sds
可以存储字符串、数字、二进制数据
通常和expire配合使用
场景：存储技术、Session

2.2 消息通知

消息通知：例如当文章更新时，将更新后的文章推送到ES，用户就能搜到最新的文章数据

实现：使用list最为消息队列

Redis 的 List 数据结构：Quicklist

由一个双向链表和listpack实现
listpack包含了长度、元素个数、所有元素、end-byte（结尾）

2.3 计数

例如文章点赞次数、阅读次数。

实现：一个用户有多项计数需求，可用过hash结构存储

key：与 user_id 唯一对应的字符串
value：多个计数项

Redis 的 Hash 数据结构：dict

rehash：将 ht[0]中的数据全部迁移到ht[1]中
- 数据量小时较快
- 数据量大时会明显阻塞
渐进式rehash
- 每次用户访问时只迁移少量数据
- 将整个迁移过程平摊到所有的访问请求过程中

2.4 排行榜

积分变化时，排名要实时变更

实现：结合dict，实现通过key操作跳表的功能

ZINCRBY myzset 2 "Alex"
ZSCORE myzset "Alex"

Redis 的 zset 数据结构：zskiplist

zset可以理解为有序集合，根据zscore来排序

2.5 限流

要求1秒内放行的请求为N，超过N则禁止访问

实现：

key：与时间戳唯一对应的字符串
value：已放行请求次数
对key调用incr，超过N则禁止访问

2.6 分布式锁

并发场景，要求一次只能有一个协程执行。

执行完成后，其他等待中的协程才能执行

实现：使用redis的setnx实现，利用了两个特性

Redis 是单线程执行命令
setnx只有未设置过时才能执行成功

3 Redis 使用注意事项

3.1 大key

3.1.1 大key的标准

string类型：value字节数大于10KB
hash, set, zset, list 等复杂数据类型：元素个数大于5000个或value总字节数大于10MB

3.1.2 大key的危害：

读取成本高
容易导致慢查询（过期、删除）
主从复制异常，服务阻塞，无法正常相应请求

3.1.3 业务侧使用大key的表现

请求redis超时报错

3.4.1 消除大key的方法

拆分：将大key拆分为小key。例如一个string拆分成多个string
压缩：将value压缩后写入redis，读取时解压后再使用。
集合类结构hash, list, set, zset
- 拆分：使用hash取余、位掩码的方式决定放在哪个key中
- 区分冷热：如榜单列表场景使用zset，只缓存前10页数据，后续数据走DB

3.2 热key

3.2.1 热key的标准

用户访问一个key的QPS特别高，导致Server实例出现CPU负载突增或不均的情况。

热key没有明确标准，QPS超过500就可能被识别为热key

3.2.2 解决热key的方法

设置Localcache：在访问redis前，在业务服务侧Localcache，降低访问Redis的QPS。Localcache中缓存过期或未命中，则从redis中将数据更新得到Localcache。
拆分：将key:value这一个热key复制写入多分，例如key1:value, key2:value，访问的时候访问多个key，但value是同一个，以此将qps分散到不同实例上，降低负载。代价是更新时需要更新多个key，存在数据短暂不一致的风险
使用redis代理的热key承载能力。本质上是结合了热key发现、Localcache两个功能

3.3 慢查询场景

容易导致redis慢查询的操作：

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

3.4 缓存穿透

3.4.1 定义

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

3.4.2 危害

查询一个一定不存在的数据：通常不会缓存不存在的数据，这类查询请求都会直接打到DB，如果有系统bug或人为攻击，容易导致DB响应慢或甚至宕机

3.4.3 如何减少

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

3.5 缓存雪崩

3.5.1 定义

大量缓存同时过期

3.5.2 危害

在高并发场景下，一个热key如果过期，会有大量请求同时打到DB，容易影响DB性能和稳定。同一时间有大量key集中过期时，也会导致大量请求打到DB，导致查询变慢，甚至出现DB无法响应新的查询

3.5.2 如何避免

缓存空值：将缓存失效时间分散开，比如在原有失效时间基础上增加一个随机值。对于热点数据，过期时间尽量设置得长一些，冷门数据可以设置得短一些
使用缓存集群，避免单机宕机造成的缓存雪崩

Redis原理与实践 ｜ 青训营笔记