【说明】
  对于热点数据（经常被查询，但不经常被修改的数据），我们可以将其放入redis缓存中，以增加查询效率，但需要保证从redis中读取的数据与数据库中存储的数据最终是一致的。本文基于“孤独烟”与“58沈剑”两位的文章，针对一致性的问题进行了汇总总结，两位的原文链接见文末。

【前言】

  客户端对数据库中的数据主要有两类操作，读(select)与写(DML)。针对放入redis中缓存的热点数据，当客户端想读取的数据在缓存中就直接返回数据，即命中缓存(cache hit)，当读取的数据不在缓存内，就需要从数据库中将数据读入缓存，即未命中缓存(cache miss)。所以读操作并不会导致缓存与数据库中的数据不一致。
  对于写操作(DML)，缓存与数据库中的内容都需要被修改，但两者的执行必定存在一个先后顺序，这可能会导致缓冲与数据库中的数据不再一致，此时主要需要考虑两个问题：
  1、执行顺序的问题：先更新缓存还是先更新数据库？
  2、更新缓存的策略问题：当缓存中的内容变化时，是选择修改缓存(update)，还是直接淘汰缓存(delete)？

针对这两点问题，一共可以分为四种方案：
  1、先更新缓存，再更新数据库；
  2、先更新数据库，再更新缓存；
  3、先淘汰缓存，再更新数据库；
  4、先更新数据库，再淘汰缓存。

【疑问一】更新cache还是淘汰cache？

  我们先来讨论缓存更新的策略问题：即更新缓存时，是直接淘汰cache中的旧数据，还是将更新操作也放在缓存中进行？

淘汰cache：
优点：操作简单，无论更新操作是否复杂，直接将缓存中的旧值淘汰
缺点：淘汰cache后，下一次查询无法在cache中查到，会有一次cache miss，这时需要重新读取数据库
更新cache：
  更新chache的意思就是将更新操作也放到缓冲中执行，并不是数据库中的值更新后再将最新值传到缓存
优点：命中率高，直接更新缓存，不会有cache miss的情况
缺点：更新cache消耗较大
  当更新操作简单，如只是将这个值直接修改为某个值时，更新cache与淘汰cache的消耗差不多
  但当更新操作的逻辑较复杂时，需要涉及到其它数据，如用户购买商品付款时，需要考虑打折等因素，这样需要缓存与数据库进行多次交互，将打折等信息传入缓存，再与缓存中的其它值进行计算才能得到最终结果，此时更新cache的消耗要大于直接淘汰cache
所以选择直接淘汰缓存更好，如果之后需要再次读取这个数据，最多会有一次缓存失败

【更新cache的另一个问题】
  我们现在已经知道直接淘汰cache比更新cache要更好，现在再进一步思考下更新cache的其它问题。
  对于上文列举的四种方案的前两种，即：
    1、先更新(update)缓存，再更新数据库；
    2、先更新数据库，再更新(update)缓存；
  当并发较大，同时有两个线程需要对同一个数据进行更新时，可能会出现以下问题：
方案一、先更新(update)缓存，再更新数据库
  线程A更新了缓存
  线程B更新了缓存
  线程B更新了数据库
  线程A更新了数据库
方案二、先更新数据库，再更新(update)缓存
  线程A更新了数据库
  线程B更新了数据库
  线程B更新了缓存
  线程A更新了缓存
如果不同的线程对同一个数据进行更新时，更新的先后顺序有明确要求，那么上述两种方案都会导致数据的不一致
解决的思路是“串行化”，即对同一个数据的修改，要以串行化的方式先后执行

结论：更新cache的消耗更大，且很有可能造成数据的不一致，所以推荐直接淘汰cache

【疑问二】执行顺序的问题

  究竟是先淘汰缓存还是先更新数据库？
这里主要分为两个方面来考虑：
  1、更新数据库与淘汰缓存是两个步骤，只能先后执行，如果在执行过程中后一步执行失败，哪种方案的影响最小？
  2、如果不考虑执行失败的情况，但更新数据库与淘汰缓存必然存在一个先后顺序，在上一个操作执行完毕，下一个操作还未完成时，如果并发较大，仍旧会导致数据库与缓存中的数据不一致，在这种情况下，用哪种方案影响最小？

另外，对于数据库而言，读写操作可以只作用在同一台服务器上，即底层只有一个数据库，也可以将读操作放在从库，写操作放在主库，即底层是主从架构，对于主从架构还需要考虑主从延迟，本文针对的是单节点模式。

【数据库是单节点】

情景一：更新数据库与淘汰缓存需要先后执行，如果在执行过程中后一步执行失败，哪种方案对业务的影响最小？
  方案一、先淘汰缓存，再更新数据库
如果第一步淘汰缓存成功，第二步更新数据库失败，此时再次查询缓存，最多会有一次cache miss
  方案二、先更新数据库，再淘汰缓存
如果第一步更新数据库成功，第二部淘汰缓存失败，则会出现数据库中是新数据，缓存中是旧数据，即数据不一致
解决办法：为确保缓存删除成功，需要用到“重试机制”，即当删除缓存失效后，返回一个错误，由业务代码再次重试，直到缓存被删除。

但对于方案一，如果更新数据库失败其实也是一个问题，为了确保数据库中的数据被正常更新，也需要“重试机制”，即当数据库中的数据更新失败后，也需要人工或业务代码再次重试，直到更新成功。

【结论】总体而言，虽然方案二导致数据不一致的可能性更大，但在业务中，无论是淘汰缓存还是更新数据库，我们都需要确保它们真正完成了，所以个人认为在情景一下两种方案并没有什么优劣之分。

重试机制的原理图：

情景二：假设没有操作会执行失败，但执行前一个操作后无法立即完成下一个操作，在并发较大的情况下，可能会导致数据不一致。此时，哪种方案对业务的影响最小？

方案一、先淘汰缓存，再更新数据库

1、在正常情况下，A、B两个线程先后对同一个数据进行读写操作：
  A线程进行写操作，先淘汰缓存，再更新数据库
  B线程进行读操作，发现缓存中没有想要的数据，从数据库中读取更新后的新数据
此时没有问题
2、在并发量较大的情况下，采用同步更新缓存的策略：
  A线程进行写操作，先成功淘汰缓存，但由于网络或其它原因，还未更新数据库或正在更新
  B线程进行读操作，发现缓存中没有想要的数据，从数据库中读取数据，但此时A线程还未完成更新操作，所以读取到的是旧数据，并且B线程将旧数据放入缓存。注意此时是没有问题的，因为数据库中的数据还未完成更新，所以数据库与缓存此时存储的都是旧值，数据没有不一致
  在B线程将旧数据读入缓存后，A线程终于将数据更新完成，此时是有问题的，数据库中是更新后的新数据，缓存中是更新前的旧数据，数据不一致。如果在缓存中没有对该值设置过期时间，旧数据将一直保存在缓存中，数据将一直不一致，直到之后再次对该值进行修改时才会在缓存中淘汰该值
此时可能会导致cache与数据库的数据一直或很长时间不一致

3、在并发量较大的情况下，采用异步更新缓存的策略：
  A线程进行写操作，先成功淘汰缓存，但由于网络或其它原因，还未更新数据库或正在更新
  B线程进行读操作，发现缓存中没有想要的数据，从数据库中读取数据，但B线程只是从数据库中读取想要的数据，并不将这个数据放入缓存中，所以并不会导致缓存与数据库的不一致
  A线程更新数据库后，通过订阅binlog来异步更新缓存
此时数据库与缓存的内容将一直都是一致的

进一步分析：
如果采取同步更新缓存的策略，即如果缓存中没有数据，就读取数据库并将数据直接放入缓存，可能会导致数据长时间的不一致
在这种情况下，可以用一些方法来进行优化：
1、用串行化的思路
  即保证对同一个数据的读写严格按照先后顺序串行化进行，避免并发较大的情况下，多个线程同时对同一数据进行操作时带来的数据不一致性。
  关于如何用串行化保证一致性，详见“58沈剑”的文章“缓存与数据库一致性保证”，原文链接见文末。
2、延时双删+设置缓存的超时时间
  不一致的原因是，在淘汰缓存之后，旧数据再次被读入缓存，且之后没有淘汰策略，所以解决思路就是，在旧数据再次读入缓存后，再次淘汰缓存，即淘汰缓存两次(延迟双删)
引入延时双删后，执行步骤变为下面这种情形：
  A线程进行写操作，先成功淘汰缓存，但由于网络或其它原因，还未更新数据库或正在更新
  B线程进行读操作，从数据库中读入旧数据，共耗时N秒
  在B线程将旧数据读入缓存后，A线程将数据更新完成，此时数据不一致
  A线程将数据库更新完成后，休眠M秒(M比N稍大即可)，然后再次淘汰缓存，此时缓存中即使有旧数据也会被淘汰，此时可以保证数据的一致性
  其它线程进行读操作时，缓存中无数据，从数据库中读取的是更新后的新数据

利用延迟双删，可以很好的解决数据不一致的问题，其中A线程休眠的M秒，需要根据业务上读取的时间来衡量，只要比正常读取消耗的实际稍大就可以。但是个人感觉实际业务中需要根据场景来设置休眠的时间，这个不好确定。

引入延时双删后，存在两个新问题：
  1、A线程需要在更新数据库后，还要休眠M秒再次淘汰缓存，等所有操作都执行完，这一个更新操作才真正完成，降低了更新操作的吞吐量
解决办法：用“异步淘汰”的策略，将休眠M秒以及二次淘汰放在另一个线程中，A线程在更新完数据库后，可以直接返回成功而不用等待。
  2、如果第二次缓存淘汰失败，则不一致依旧会存在
解决办法：用“重试机制”，即当二次淘汰失败后，报错并继续重试，直到执行成功个人

“异步淘汰”策略：

A线程执行完步骤2不再休眠Ms，而是往消息总线esb发送一个消息，发送完成之后马上就能返回

【小结】
在单节点下，用“先删缓存，再更新”的策略，如果采用同步更新缓存的策略，可能会导致数据长时间的不一致，可以通过一些方法来尽量避免不一致；如果采用异步更新缓存的策略，就不会导致数据不一致

方案二、先更新数据库，再淘汰缓存

在正常情况下：
  A线程进行写操作，更新数据库，淘汰缓存
  B线程进行读操作，从数据库中读取新的数据
不会有问题

在并发较大的情况下，情形1：
  A线程进行写操作，更新数据库，还未淘汰缓存
  B线程从缓存中可以读取到旧数据，此时数据不一致
  A线程完成淘汰缓存操作
  其它线程进行读操作，从数据库中读入最新数据，此时数据一致
不过这种情况并没有什么大问题，因为数据不一致的时间很短，数据最终是一致的

在并发较大的情况下，情形2：
  A线程进行写操作，更新数据库，但更新较慢，缓存也未淘汰
  B线程进行读操作，读取了缓存中的旧数据
但这种情况没什么问题，毕竟更新操作都还未完成，数据库与缓存中都是旧数据，没有数据不一致

在并发较大的情况下，情形3：
  A线程进行读操作，缓存中没有相应的数据，将从数据库中读数据到缓存，
此时分为两种情况，还未读取数据库的数据，已读取数据库的数据，不过由于网络等问题数据还未传输到缓存
  B线程执行写操作，更新数据库，淘汰缓存
  B线程写操作完成后，A线程才将数据库的数据读入缓存，对于第一种情况，A线程读取的是B线程修改后的新数据，没有问题，对于第二种情况，A线程读取的是旧数据，此时数据会不一致
不过这种情况发生的概率极低，因为一般读操作要比写操作要更快
万一担心存在这种可能，可以用“延迟双删”策略，在A线程读操作完成后再淘汰一次缓存

【小结】
在该方案下，无论是采用同步更新缓存(从数据库读取的数据直接放入缓存中)，还是异步更新缓存(数据库中的数据更新完成后，再将数据同步到缓存中)，都不会导致数据的不一致
该方案主要只需要担心一个问题：如果第二步淘汰缓存失败，则数据会不一致
解决办法之前也提到过，用“重试机制”就可以，如果淘汰缓存失败就报错，然后重试直到成功

【单节点下两种方案对比】
先淘汰cache，再更新数据库：
  采用同步更新缓存的策略，可能会导致数据长时间不一致，如果用延迟双删来优化，还需要考虑究竟需要延时多长时间的问题——读的效率较高，但数据的一致性需要靠其它手段来保证
  采用异步更新缓存的策略，不会导致数据不一致，但在数据库更新完成之前，都需要到数据库层面去读取数据，读的效率不太好——保证了数据的一致性，适用于对一致性要求高的业务
先更新数据库，再淘汰cache：
  无论是同步/异步更新缓存，都不会导致数据的最终不一致，在更新数据库期间，cache中的旧数据会被读取，可能会有一段时间的数据不一致，但读的效率很好——保证了数据读取的效率，如果业务对一致性要求不是很高，这种方案最合适

【其它】
重试机制可以采利用“消息队列MQ”来实现
通过订阅binlog来异步更新缓存，可以通过canal中间件来实现

原文链接：
【58沈剑原文链接】
缓存架构设计细节二三事2016-03-08
缓存与数据库一致性保证2016-03-16
主从DB与cache一致性 2016-03-24
缓存，究竟是淘汰，还是修改？2018-07-02
究竟先操作缓存，还是数据库？ 2018-07-09
Cache Aside Pattern 2018-07-11
缓存与数据库不一致，咋办？ 2018-07-12

【孤独烟原文链接】
分布式之数据库和缓存双写一致性方案解析 2018-05-15
分布式之数据库和缓存双写一致性方案解析(二) 2018-06-28
分布式之数据库和缓存双写一致性方案解析(三)2018-07-13