Redis 与 DB 的数据一致 / 双写一致性问题

前言

        Redis与MySQL的双写一致性如何保证？不管是工作还是面试，这都是老生常谈的问题。近期，我打算在公司做一期《分布式环境下如何保证数据一致性》的培训，所以决定把课题相关的资料好好整理了一下，希望可以成体系的研究一下。

        本文系统的介绍了 Redis 与 DB 双写数据一致性解决方案。当然，文章会参照最新的一些文章（毕竟知识点也就这么点东西），但是解决了内容重复、冗余的Bug，并且会重点介绍【多级缓存的一致性问题解决方案】。

你可能需要的文章：

• 高性能系统架构设计之：多级缓存
• Redis为什么快？基于内存就完事了？不要无视Redis如此完美的数据结构

---

正文

一、CAP理论

         所谓的一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。

• 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大；
• 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态；
• 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。

        CAP理论，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。分布式系统要么满足CA，要么CP，要么AP，无法同时满足CAP。

        因为使用缓存提升性能，就是会有数据更新的延迟，如果需要数据库和缓存数据保持强一致，就不适合使用缓存。但是，通过一些方案优化处理，是可以保证弱一致性，最终一致性的。

        所以，我们在设计时结合业务仔细思考是否适合用缓存，然后缓存一定要设置过期时间，这个时间太短、或者太长都不好：

• 太短的话：请求可能会比较多的落到数据库上，这也意味着失去了缓存的优势；
• 太长的话：缓存中的脏数据会使系统长时间处于一个延迟的状态，而且系统中长时间没有人访问的数据一直存在内存中不过期，浪费内存。

重要：缓存是通过牺牲强一致性来提高性能的，这是由CAP理论决定的，缓存系统适用的场景就是非强一致性的场景，它属于 CAP 中的 AP。

---

二、常见方案

3种常用方案可以保证缓存与数据库数据的一致性：

1. 延时双删；
2. 重试机制删除缓存；
3. 读取 biglog 异步删除缓存；

2.1 延时双删

方案：先删除缓存 → 再更新数据库 → 休眠一会（比如1秒），再次删除缓存 → 待后续请求落到DB后，将查询数据更新到缓存，去报后续请求一直落到缓存上。

        第二次删除的目的，是确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据，因为删除缓存和更新DB之间会有时间差。

         这个休眠一会，一般多久呢？是1秒吗？

休眠时间 ≈ 读业务逻辑数据的耗时 + 几百毫秒。