分布式系统：缓存与数据库一致性问题

前言

缓存设计是应用系统设计中重要的一环，是通过空间换取时间的一种策略，达到高性能访问数据的目的；但是缓存的数据并不是时刻存在内存中，当数据发生变化时，如何与数据库中的数据保持一致，以满足业务系统要求，本篇将给出具体分析。

一致性分类

强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大，这种情况比如秒杀系统，商家后台，他会设置秒杀商品，参与秒杀活动，一旦说他参与了秒杀活动，商品的库存本来是在数据库里的，此时必须直接被加载到缓存里，缓存立马就要可以被使用。
弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型，比如微博的粉丝数，页面每天的访问数

缓存更新机制

缓存的更新，一般分为被动更新与主动更新，被动更新是指缓存在有效期到后，被淘汰。

被动更新如下步骤：
step1: 发起方查数据，缓存中没有，从数据库中获取，并写入缓存，同时设置过期时间 t；
step2: 在 t 内，所有的查询，都由缓存提供，所有的写，直接写数据库；
step3: 当缓存数据到过期时间 t 后，缓存数据失效。后面的查询，回到了第 1 步。

主动更新，一般为调用方发起缓存与数据库同时更新，缓存分为删除、更新，数据库分为更新，通过组合与先后顺序，分为如下四种情况：
更新缓存、更新数据库，更新数据库，更新缓存，删除缓存，更新数据库，更新数据库，删除缓存

更新缓存、更新数据库

这种情况，当缓存更新成功，数据库更新不成功时，数据不一致的风险比较高，所以一般不采用。

更新数据库、更新缓存

当更新完数据库，缓存的加载前需要通过大量复杂计算才能得出缓存的值，不仅让发起方阻塞，影响性能；而且如果缓存命中率不高，很少使用，更浪费前期的复杂计算成本与缓存空间，这里就不符合懒加载的设计思想，故一般也不采用。

删除缓存、更新数据库

如图所示，当两个调用方线程高并发访问的情况下，A 线程先删除缓存，再更新数据库，此过程时间较长，B 线程在 A 删除缓存后，迅速读取缓存，因缓存每命中，从数据库中读取再加载缓存，此时缓存还是旧值，等 A 线程更新完数据库后，发现又出现数据不一致的现象。

一般大概率情况下，出现此根源的原因是读比写快，所以这种一般也不采用，如果非得采用，需要在写完数据库之后延迟一段时间再删除一次缓存，也就是我们熟知的 延时双删，延迟多久呢，一般看数据库的更新时长来决定，此做法也会带来系统吞吐量下降。

Cache-Aside

也叫做旁路缓存模式，流程就是先更新数据库，再删除缓存，虽然这种方式也会带来不一致的情况，比如如下场景：

前提：缓存无数据，数据库有数据。
A：查询，B：更新
过程如下：
step1: A 查缓存，无数据，去读数据库，旧值；
step2: B 更新数据库为新值；
step3: B 删除缓存；
step4: A 将旧值写入缓存。

该场景最终也会出现不一致，产生的根源是是读比写慢，这种是小概率事件，一般很少出现，如果非要解决这种情况，还是上面说的延迟双删

Read/Write Through

上面的方式，数据库是缓存的来源，主导是数据库，而 Read/Write Through模式，相当于缓存占主导。在 cache-aside 模式中，我们的应用代码需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。而 Read/Write Through 做法是把更新数据库（Repository）的操作由缓存自己代理了，所以，对于应用层来说，就简单很多了。可以理解为，应用认为后端就是一个单一的存储，而存储自己维护自己的 Cache。

Read Through

Read Through 就是在查询操作中更新缓存，也就是说，当缓存失效的时候（过期或 LRU 换出），Cache Aside 是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载，从而对应用方是透明的。

这个简要流程和 Cache-Aside 很像，其实Read-Through就是多了一层Cache-Provider，流程如下：

Read-Through 实际只是在Cache-Aside之上进行了一层封装，它会让程序代码变得更简洁，同时也减少数据源上的负载

Write Through

Write Through，和 Read Through 相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由 Cache 自己同步更新数据库

值得注意的是，该方案在实现过程中，程序启动时，需将数据库的数据，提前放到缓存中，不能等启动完成，再放缓存中。

Read Through/Write Through 策略的特点是由缓存节点而非应用程序来和数据库打交道，在我们开发过程中相比 Cache Aside 策略要少见一些，原因是我们经常使用的分布式缓存组件，无论是 Memcached 还是 Redis 都不提供写入数据库和自动加载数据库中的数据的功能。而我们在使用本地缓存的时候可以考虑使用这种策略。

Write Behind

Write Behind 又叫 Write Back。底层思想就是在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的 I/O 操作速度飞快（因为是直接操作内存），同时带来吞吐量大幅上升；因为异步，Write Behind 还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。

但是，其带来的问题是，数据不是强一致性的，而且可能会丢失（我们知道 Unix/Linux 非正常关机会导致数据丢失，就是因为这个事）。在软件设计上，我们基本上不可能做出一个没有缺陷的设计，就像算法设计中的时间换空间，空间换时间一个道理，有时候，强一致性和高性能，高可用和高性性是有冲突的。如果说软件功能模块的思维是逻辑与实现，那么软件架构设计的思维是权衡与取舍。

这种方式下，缓存和数据库的一致性不强，对一致性要求高的系统要谨慎使用。但是它适合频繁写的场景，MySQL 的InnoDB Buffer Pool 机制就使用到这种模式。

Write Behind 实际应用

按照实际架构应用层面落地参考方案，流程图如下（以用户发表视频为例）

按照这种方案，正常来说只要 10 分钟内数据正常写完就没问题，可以实现最终一致性，但是一旦超出 10 分钟，就会缓存失效，造成缓存不一致

如果出现这种 kafka 消费入库失败，则会触发报警系统，看具体是什么问题，基本上 kaka 入库失败只有两种情况，一种是出错了，另外一种是消费能力不够，那么直接扩容即可

后记

说到底这个问题根本没有通用方案，需要根据场景做权衡，比如类似于微博这样高并发场景，那么上边只要涉及删除缓存的方案基本都很难实现，因为很可能删除缓存的下一时间热点数据直接全部打在数据库上，整个服务直接崩溃

然后本质上缓存和数据库的更新就不是一个原子操作，想要彻底实现强一致性，可以了解下分布式事务或是其他强一致性协议，比如说两阶段提交协议 —— prepare, commit/rollback，比如 Java 7 的 XAResource，还有 MySQL 5.7 的 XA Transaction，有些 cache 也支持 XA，比如 EhCache