#头条创作挑战赛#

hello，大家好，我是张张，「架构精进之路」公号作者。

延时双删策略是分布式系统中存储和缓存数据保持一致性的常用策略，但它不是强一致。

这里思考和分析一下它的工作原理。

• 1. 延时双删
• 2. Q & A
• 3. 系统布局
• 4. 缓存处理4.1. 更新缓存4.2. 删除缓存
• 5. 延时
• 6. 其它策略6.1. redis 数据过期6.2. 分布式路由策略
• 7. 缺点
• 8. 小结

1. 延时双删

延时双删常用步骤有 4 个，参考下面伪代码：

def update_data(key, obj):
    del_cache(key)     # 删除 redis 缓存数据。
    update_db(obj)     # 更新数据库数据。
    logic_sleep(_time) # 当前逻辑延时执行。
    del_cache(key)     # 删除 redis 缓存数据。

logic_sleep 是当前请求逻辑延时执行，例如：协程睡眠切换，或者异步逻辑放进时钟里延时执行下一个步骤。很多人会误认为这是线程/进程睡眠切换，当然这样也行，不觉得这样影响实在太大了么~

2. Q & A

1. 延时双删有啥作用？

为了使得缓存和数据库数据最终一致。

2. 为什么要删除缓存数据，而不是修改？

• 如果是修改，刚改完缓存，没来得及改库，服务进程挂了怎么办。
• 如果是修改，在多个线程/进程/节点改数据场景，先改缓存的有可能后改库，先改库的也可能后改缓存。

3. 为什么要睡眠延时一段时间？

• 读写分离是解决高并发比较有效的方案，但是缓存/库的主从是异步更新数据的。
• 睡眠一段时间，就是为了库和缓存能实现数据主从同步。

4. 延时双删能确保缓存和数据库最终一致吗？

• 不能确保。
• 只能通过延时最大程度上提高数据的最终一致的概率。
• 如果缓存和数据库负载很高，主从同步很慢，很有可能不能在延时的时间内实现同步。

5. 为什么要有第一次删除缓存？

• 为了能快点实现数据一致呗。
• 延时双删有 4 个步骤，全部执行完才能实现数据最终一致，可能会比较慢！
• 延时双删第三个步骤延时等待是比较漫长的，有可能在等待时间超时前，数据就已经完成同步了。在多线程/进程/节点的并发环境中，如果其它并发环节增加第一次删除，就能快速实现数据最终一致，不用等延时双删四个步骤都走完。

6. 主从架构，A 改主库，从库还没更新，B 读从库写入缓存，缓存与主库不一致啊？

• 确实有这问题，要知道这是最终一致，并不是强一致，最后一次删除就是为了最终一致！
• 所以要确保你的业务场景能忍受数据最终一致的缺陷，实在不行你读主库呗。
• 为啥我们在 12306 买票，明明看到有票，一进去买就没票了呢？—— 谁叫大伙刷票那么来劲，后台既要支持高并发，又要实现强一致，还得控制成本，你带我玩吧~ 所以个人认为：查票是最终一致，买票是强一致。——那些节假日能徒手抢到票的人都不是一般人啊….

3. 系统布局

先从宏观上观察系统布局，了解数据一致性。

因为多个节点间的数据异步操作，所以整个系统要实现强一致是比较难的。

1. 多个业务程序节点读写数据。
2. redis 读写分离，主从同步。
3. mysql 读写分离，主从同步。

4. 缓存处理

4.1. 更新缓存

为什么要删除缓存呢，更新缓存不行吗？

看看下面两种场景，不同服务节点修改存储数据，都可能出现 redis 和 mysql 出现数据不一致问题。

• 先改缓存再改数据库。

• 先改数据库再改缓存。

4.2. 删除缓存

第一次删除是为了快点实现一致，第二次删除为了最终一致。

5. 延时

为什么要延时呢？因为 mysql 和 redis 主从节点数据不是实时同步的，同步数据需要时间。

数据工作的大致流程：

1. 服务节点删除 redis 主库数据。
2. 服务节点修改 mysql 主库数据。
3. 服务节点使得当前业务处理 等待一段时间，等 redis 和 mysql 主从节点数据同步成功。
4. 服务节点从 redis 主库删除数据。
5. 当前或其它服务节点读取 redis 从库数据，发现 redis 从库没有数据，从 mysql 从库读取数据，并写入 redis 主库。

6. 其它策略

6.1. redis 数据过期

redis 作为高速缓存，优点很明显：快；缺点也很明显：消耗内存。

所以 redis 的定位是缓存热点数据，热点数据应该设置过期时间，当数据过期后，redis 会自动淘汰，这样当业务服务节点从 redis 查询已淘汰的数据时，查询不到数据，会重新从 mysql 数据库读取数据写入 redis。

这也是加强 redis / mysql 数据一致性的相对简单有效的方法。

用户应该根据自己的实际业务场景去设置 redis 数据的过期时间。

6.2. 分布式路由策略

高性能系统当然是越快越好，所以延时双删的 “延时” 不见得有多好，但是在读多写少的应用场景中，也算是性能和功能的折中处理。

很多时候，数据不一致是因为多个节点并行读写共享数据导致。如果某些特定业务只落在某个进程某个线程上独立 串行 处理，那问题处理是否会更好呢？

当然这里面涉及到节点的变动带来的问题，所以没有万能的方案，只能根据场景进行取舍。

7. 缺点

1. 延时双删，有等待环节，如果系统要求低延时，这种场景就不合适了。
2. 延时双删，不适合“秒杀”这种频繁修改数据和要求数据强一致的场景。
3. 延时双删，延时时间是一个预估值，不能确保 mysql 和 redis 数据在这个时间段内都实时同步或持久化成功了。

8. 小结

1. 延时双删 用比较简洁的方式实现 mysql 和 redis 数据最终一致性，但它不是强一致。
2. 延时，是因为 mysql 和 redis 主从节点数据同步不是实时的，所以需要等待一段时间，去增强它们的数据一致性。
3. 延时 是指当前请求逻辑处理延时，而不是当前线程或进程睡眠延时。
4. mysql 和 redis 数据一致性是一个复杂的课题，通常是多种策略同时使用，例如：延时双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等。

参考文章：
https://wenfh2020.com/2022/02/14/data-consistency/

- END -

希望今天的讲解对大家有所帮助，谢谢！

Thanks for reading!

作者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专注架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一起成长。
关注并私信我回复“01”，送你一份程序员成长进阶大礼包，欢迎勾搭。