高并发场景下，到底先更新缓存（Redis）还是先更新数据库（MySQL）的问题？

对于热点数据（经常被查询，但不经常被修改的数据），我们可以将其放入redis缓存中，以增加查询效率，但需要保证从redis中读取的数据与数据库中存储的数据最终是一致的。针对一致性的问题进行了汇总总结。

【 问题介绍 】

  客户端对数据库中的数据主要有两类操作，读(select)与写(DML)。缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。
  对于写操作(DML)，缓存与数据库中的内容都需要被修改，但两者的执行必定存在一个先后顺序，这可能会导致缓冲与数据库中的数据不再一致，此时主要需要考虑两个问题：
  1、更新缓存的策略问题：当缓存中的内容变化时，是选择修改缓存，还是直接淘汰缓存
  2、执行顺序的问题：先更新缓存还是先更新数据库
针对这两点问题，一共可以分为四种方案：
  1、先更新缓存，再更新数据库；
  2、先更新数据库，再更新缓存；
  3、先淘汰缓存，再更新数据库；
  4、先更新数据库，再淘汰缓存。

【 问题一 】更新缓存还是淘汰缓存？

【淘汰缓存】
优点：操作简单，无论更新操作是否复杂，直接将缓存中的旧值淘汰
缺点：淘汰缓存后，下一次查询无法在缓存中查到，会有一次缓存缺失，这时需要重新读取数据库
【更新缓存】
更新缓存的意思就是将更新操作也放到缓冲中执行，并不是数据库中的值更新后再将最新值传到缓存
优点：命中率高，直接更新缓存，不会有缓存缺失的情况
缺点：更新缓存消耗较大
【更新缓存的问题】

• 问题一
  当更新操作简单，如只是将这个值直接修改为某个值时，更新缓存与淘汰缓存的消耗差不多
  但当更新操作的逻辑较复杂时，需要涉及到其它数据，并进行复杂的运算时，此时更新缓存的消耗要大于直接淘汰cache，所以选择直接淘汰缓存更好
• 问题二
  当并发较大，同时有两个线程需要对同一个数据进行更新时，可能会出现以下问题：
  方案一、先更新缓存，再更新数据库
    线程A更新了缓存
    线程B更新了缓存
    线程B更新了数据库
    线程A更新了数据库
  方案二、先更新数据库，再更新缓存
    线程A更新了数据库
    线程B更新了数据库
    线程B更新了缓存
    线程A更新了缓存
  如果不同的线程对同一个数据进行更新时，那么上述两种方案都会导致数据的不一致。

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

【 问题二 】淘汰缓存的执行顺序？

【 方案一 】先淘汰缓存，再更新数据库
在并发量较大的情况下，会导致数据的不一致。
  1. A线程进行写操作，先成功淘汰缓存，但由于网络或其它原因，还未更新数据库
  2. B线程进行读操作，发现缓存中没有想要的数据，从数据库中读取到的是旧数据，并把旧数据放入缓存。此时数据库与缓存都是旧值，数据没有不一致
  3. A线程将数据库更新完成，数据库中是更新后的新数据，缓存中是更新前的旧数据，造成数据不一致。

解决方式：采用串行化或者设置超时时间

【 方案二 】先更新数据库，再淘汰缓存
在并发量较大的情况下，会导致数据的短暂不一致，但是数据会最终一致。
  1. A线程进行写操作，更新数据库，还未淘汰缓存
  2. B线程从缓存中可以读取到旧数据，此时数据不一致
  3. A线程完成淘汰缓存操作，其它线程进行读操作，从数据库中读入最新数据，此时数据一致
这种情况并没有什么大问题，因为数据不一致的时间很短，数据最终是一致的

这种情况不存在并发问题么？

1. 缓存刚好失效，请求A查询数据库，得一个旧值
2. 请求B将新值写入数据库，
3. 请求B然后删除缓存，
4. 请求A将查到的旧值写入缓存。

此时的数据的会不一致，但是这种情况的概率几乎不可能发生。因为发生的条件就是步骤2（写操作）快于步骤1（读操作），然后步骤3才能快于步骤4，但是数据库的读操作要比写操作要更快，因此发生的概率极低。

【 总结 】

  先更新数据库，再淘汰缓存，不会导致数据的最终不一致，在更新数据库期间，缓存中的旧数据会被读取，可能会有一段时间的数据不一致，但读的效率很好——保证了数据读取的效率，如果业务对一致性要求不是很高，这种方案最合适。