redis 与 DB 的一致性 7 种策略

为什么要使用 redis 做缓存?

高性能

• redis压力测试: 20w QPS(瓶颈是网络 io)
• MySQL: 2w QPS(瓶颈是磁盘io)

封底估算

是否使用缓存是有单行数据的 QPS 决定的

为什么是单行数据的QPS,而不是总的?

• 使用(Redis)缓存主要是利用 缓存( Redis)高性能的特性减少DB的重复查询
• 就是数据需要多次查询,并且每次查询的结果是相同的,这时候加到缓存中,可以拦截大量的请求在缓存层,减少db的请求压力
  举个例子
• 一些 IM 系统的总的 QPS 有几十万(qq,wx 这些)
• 但是每个人接受的消息是不同的,并且消息是一次性消费的,所以针对单行消息而言,QPS 是小于 1 的并且是一次性消费,不涉及多次重复查询,即使总的 QPS 非常高,也不会使用缓存(IM 系统会使用Redis,但是不是做缓存使用的)

什么时候使用DB,Redis,本地缓存

使用 DB

• 当数据是部分人可见的(比如后台管理/GM 的需求):单行数据的QPS<1(是一个常数)

使用Redis 缓存

• 数据所有用户可见,单行数据的QPS>1 ,就需要考虑 Redis 缓存了

本地缓存

• 原因 Redis 有 20 万 QPS,但是单 key 的 QPS 只有几千;
• 而本地内存的读写性能有千万(map 读写)
• 所以当单行数据的 QPS>5000(参考阿里云的热 key 二级缓存标准 QPS) 就可以考虑使用本地缓存了

数据的分类

• 热数据: 考虑极端热数据的情景(1w 的 QPS)
• 冷数据: 0 QPS(没人访问)
• 由冷数据突然变成热数据: QPS 0 突变-> QPS 2000

我们的核心要求是:

1. 热数据不能失效,因为热数据失效容易造成缓存击穿的问题
2. 冷数据不能长时间储存在缓存(redis)中: 控制成本
3. 冷数据(没有缓存)突变到热数据(大量请求): 不能全部请求都回源(查询 DB),否则会造成缓存击穿问题

一致性的方案

1. 先清除Redis,再更新 DB

• 存在的问题:
  • 间隙查询的不一致问题
  • 有缓存击穿的风险

举个例子:

1. 不一致

• 再清除 Redis 后,更新 DB 前有一个查询请求
• 因为 DB 没有更新,查询请求查询到旧数据,然后将旧数据更新到 Redis
• 这时 Redis 中的就是一条脏数据,造成数据不一致的问题

2. 如果清除到一条有 1万 QPS 的 key 很容易发生击穿的问题

2. 先更新DB,再清除 Redis

• 存在的问题:
  • 缓存击穿的问题

还是清除到 1 万 QPS 的 key 很容易发生击穿

使用场景:

• QPS不高(单行数据QPS<20,不存在热key 的场景)的非核心业务:比如用户的主页

3. 延迟删除与延迟双删

工作流程: 先更新 DB,再等一段时间清除 Redis / 先清除 Redis,再更新 DB,再等一段时间清除 Redis

核心解决的问题: 查询从库导致的数据不一致的问题

举个例子:

• 更新 DB 是更新的主库,从库需要一段时间进行同步
• 但是 DB更新完后,从库没有同步好,这时有一个查询,查询到有个未同步的从库(旧数据)
• 然后将数据更新到 Redis

所以延迟的作用就是等待从库的数据同步好,保证数据一直

延迟多久?

• 具体要根据项目中的同步的耗时与单行数据的 qps来确定是否需要延迟删除/延迟双删

使用场景

• QPS不高(单行数据QPS<20,不存在热key 的场景)的非核心业务:比如用户的主页 (本质与方案 2 是相同的,不能有热 key; 只是增加了延迟解决从库查询的不一致问题)

4. 监听 binlog 清除

解决的问题:

• 将自当成 DB 的一个从节点,监听主节点的 binlog,并删除Redis
• 服务解耦和: 与之前不同的是这种方案是低耦合实现

问题:

• 同样只适用于 QPS<20(没有热 key 问题的需求)
• 实现复杂: 监听 binlog 的逻辑是比较复杂的(比如 binlog 的获取,解析,消费等)

5. 双写

工作流程: 先更新 DB,再更新 Redis

• 存在的问题与解决方案
  • 并发写的不一致问题
    • 举个例子: 有两个写请求(请求 1,将数据改为 A; 请求 2 将数据改为 B)
    • 这时请求 1 先执行,将DB 改为 A,然后请求 1 阻塞
    • 请求 2 后执行,先将 DB 改成 B , 再将 Redis 改成 B
    • 这时请求 1 阻塞恢复了,将 Redis 改成 A
    • 这时 DB 是 B,Redis(缓存)是 A,造成了一个数据不一致的问题
  • 解决方案: 加分布式锁,不允许同时更改,只能一个执行完成才能执行下一个

使用场景:

• 完善一下

  • 热数据的过期失效问题(自动续期)
  • 冷数据突变为热数据(只放一个请求回源更新,其他请求返回空)

• 完善后可以适用于高读,高写,高一致性的场景: 比如抢红包业务

• 抢红包业务分析:

  • 红包发出会有大量的抢红包的操作,就涉及到大量的写(并发写)
  • 红包发出有大量的人查询抢红包的记录: 大量读
  • 抢完红包后需要所有人看到最新的记录: 高的一致性

6. 监听binlog更新

核心解决的问题

• binlog 是有序的,如果能顺序消费 binlog 就可以解决双写中并发写的问题

如何订阅 binlog?

1. 使用Canal组件(原理就是伪装成从节点向主节点发送 dump)

缺点:

• 复杂,binlog 的获取,解析,消费整套是比较复杂的逻辑(比锁实现起来要更复杂),并且还要考虑过期失效的问题与冷数据突变为热数据的问题
• 一致性没有双写好(双写使用了分布式锁,基本就是一个强一致的方案)

7.定时刷新

实现方式:

• 储存(Redis)缓存的时候储存一个数据的更新标记(val 是一个空值),并且 更新标记的过期时间<数据的过期时间

  • 比如:更新标记 10s 过期; 数据 10 分钟过期

• 查询的时候先使用 set nx px 命令检查更新标记是否存在,

  • 如果存在(写失败): 就使用 Redis 的数据
  • 如果不存在(写成功): 就回源(查询 DB)更新 Redis(更新数据与过期时间)

如此就可以实现数据的定时刷新(每个更新标记的存活时间刷新一次),这样可以解决一致性的问题与热数据过期失效的问题,一举两得

解决完热数据的问题还剩冷数据与冷数据突变为热数据

1. 冷数据: 不使用会自动过期,释放空间
2. 冷数据突变为热数据: 第一个会回源(set nx 成功),其他请求暂时返回空,知道回源完成

为什么是返回空而不是回源或者阻塞?

1. 回源的问题: 击穿
2. 阻塞的问题: 阻塞大量的请求(协程)(假设有 1万 QPS,回源需要 10s,就会阻塞 10 万个请求)

优点:

1. 实现简单: 定时刷新同时解决了一致性问题与热数据的失效问题
2. 好拓展: 不仅适用于 Redis 与 DB 的一致性,还适用于内存与 Redis 的一致性

使用场景

1. 一致性要求不高(不敏感): 比如要求是更新后 10 分钟内可以看到数据最新的状态
2. 读高: 有大量读并存在热点问题

比如: 短视频平台的视频数据

选择

1. 封顶估算: 对单行数据进行封顶估算决定是否使用缓存,使用什么缓存
2. 任务分解: 将实际需求中可能遇到的情况罗列出来(比如:热数据,冷数据,冷数据突变为热数据)
3. 分析每一种情况,并提供对应的解决方案.

参考: https://blog.csdn.net/weixin_42338901/article/details/129231758

其他问题

上面主要解决的是击穿问题,Redis 缓存的常见的三大问题还有两个

1. 缓存穿透: 使用不存在的 key 进行访问
2. 缓存雪崩: 缓存大面积失效

缓存穿透

常见的解决方案:

1. 布隆过滤器
   实现: 多次哈希,然后标记对应的 bit 位(变为 1)
   判断是否出现过: 多次哈希,所有 bit 位都为 1 才算

问题:

• 不是 100% 准确的,存在误判的可能
• 只能记录是否出现过(适合做加法,很难做减法)
  举个例子: 某个 key 开始是不存在的,加到布隆过滤器中防止穿透,后面存在了;这时候别人访问这个 key 就会拦截掉.

2. 记录空值

• 相同的不存在的 key 重复访问会拦截到 Redis 层

缺点:
比布隆过滤器消耗空间更大