23. 数据库和缓存的一致性
1 前言
通常针对服务器的访问速度越来越差，基本**性能瓶颈是在数据库，**那么我们通常会给服务器加上 Redis，让其作为数据库的缓存或者本地缓存，这样，在客户端请求数据时，如果能在缓存中命中数据，那就查询缓存，不用在去查询数据库，从而减轻数据库的压力，提高服务器的性能。
缓存无非就是对数据的一份Copy，但是不管是何种缓存，既然你Copy了，你就要去管人家，多个地方的数据的一致性就是一个问题，我们这节就来聊聊。
2 先更新数据库，还是先更新缓存？
有了这个想法后，就准备开始着手优化服务器，但是挡在前面的这样的一个问题。
由于引入了缓存，那么在数据更新时，不仅要更新数据库，而且要更新缓存，这两个更新操作存在前后的问题：
- 先更新数据库，再更新缓存；
- 先更新缓存，再更新数据库；
造成缓存和数据库的数据不一致的现象，是因为并发问题，我们来看看。
先更新数据库，再更新缓存
举个例子，比如「请求 A 」和「请求 B 」两个请求，同时更新「同一条」数据，则可能出现这样的顺序：
A 请求先将数据库的数据更新为 1，然后在更新缓存前，请求 B 将数据库的数据更新为 2，紧接着也把缓存更新为 2，然后 A 请求更新缓存为 1。
此时，数据库中的数据是 2，而缓存中的数据却是 1，出现了缓存和数据库中的数据不一致的现象。
先更新缓存，再更新数据库
那换成「先更新缓存，再更新数据库」这个方案，还会有问题吗？
依然还是存在并发的问题，分析思路也是一样。
假设「请求 A 」和「请求 B 」两个请求，同时更新「同一条」数据，则可能出现这样的顺序：
A 请求先将缓存的数据更新为 1，然后在更新数据库前，B 请求来了， 将缓存的数据更新为 2，紧接着把数据库更新为 2，然后 A 请求将数据库的数据更新为 1。
此时，数据库中的数据是 1，而缓存中的数据却是 2，出现了缓存和数据库中的数据不一致的现象。
所以，无论是「先更新数据库，再更新缓存」，还是「先更新缓存，再更新数据库」，这两个方案都存在并发问题，当两个请求并发更新同一条数据的时候，可能会出现缓存和数据库中的数据不一致的现象。
3 先更新数据库，还是先删除缓存？
另一种做法就是，在更新数据时，不更新缓存，而是删除缓存中的数据。然后，到读取数据时，发现缓存中没了数据之后，再从数据库中读取数据，更新到缓存中。学术名叫 Cache Aside 策略，中文是叫旁路缓存策略。
该策略又可以细分为「读策略」和「写策略」。
写策略的步骤：
- 更新数据库中的数据；
- 删除缓存中的数据。
读策略的步骤：
- 如果读取的数据命中了缓存，则直接返回数据；
- 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。
在「写策略」的时候，就会又陷入更深层次的思考，到底该选择哪种顺序呢？
- 先删除缓存，再更新数据库；
- 先更新数据库，再删除缓存。
先删除缓存，再更新数据库
假设某个用户的年龄是 20，请求 A 要更新用户年龄为 21，所以它会删除缓存中的内容。这时，另一个请求 B 要读取这个用户的年龄，它查询缓存发现未命中后，会从数据库中读取到年龄为 20，并且写入到缓存中，然后请求 A 继续更改数据库，将用户的年龄更新为 21。
最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库的数据不一致。
可以看到，先删除缓存，再更新数据库，在「读 + 写」并发的时候，还是会出现缓存和数据库的数据不一致的问题。
先更新数据库，再删除缓存
继续用「读 + 写」请求的并发的场景来分析。
假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。
最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。
从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，但是在实际中，这个问题出现的概率并不高。
因为缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。
而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。
所以，「先更新数据库 + 再删除缓存」的方案，是可以保证数据一致性的。
「先更新数据库，再删除缓存」的方案虽然保证了数据库与缓存的数据一致性，但是每次更新数据的时候，缓存的数据都会被删除，这样会对缓存的命中率带来影响。
所以，如果我们的业务对缓存命中率有很高的要求，我们可以采用「更新数据库 + 更新缓存」的方案，因为更新缓存并不会出现缓存未命中的情况。
但是这个方案前面我们也分析过，在两个更新请求并发执行的时候，会出现数据不一致的问题，因为更新数据库和更新缓存这两个操作是独立的，而我们又没有对操作做任何并发控制，那么当两个线程并发更新它们的话，就会因为写入顺序的不同造成数据的不一致。
所以我们得增加一些手段来解决这个问题，这里提供两种做法：
- 在更新缓存前先加个分布式锁，保证同一时间只运行一个请求更新缓存，就会不会产生并发问题了，当然引入了锁后，对于写入的性能就会带来影响。
- 在更新完缓存时，给缓存加上较短的过期时间，这样即时出现缓存不一致的情况，缓存的数据也会很快过期，对业务还是能接受的。
对了，针对「先删除缓存，再更新数据库」方案在「读 + 写」并发请求而造成缓存不一致的解决办法是「延迟双删」。
延迟双删实现的伪代码如下：
#删除缓存
redis.delKey(X)
#更新数据库
db.update(X)
#睡眠
Thread.sleep(N)
#再删除缓存
redis.delKey(X)加了个睡眠时间，主要是为了确保请求 A 在睡眠的时候，请求 B 能够在这这一段时间完成「从数据库读取数据，再把缺失的缓存写入缓存」的操作，然后请求 A 睡眠完，再删除缓存。
所以，请求 A 的睡眠时间就需要大于请求 B 「从数据库读取数据 + 写入缓存」的时间。
但是具体睡眠多久其实是个玄学，很难评估出来，所以这个方案也只是尽可能保证一致性而已，极端情况下，依然也会出现缓存不一致的现象。
因此，还是比较建议用「先更新数据库，再删除缓存」的方案。
删除缓存操作失败的话，如何保证两个操作都能执行成功？
在删除缓存（第二个操作）的时候失败了，导致缓存还是旧值，而数据库是最新值，造成数据库和缓存数据不一致的问题，会对敏感业务造成影响。
举个例子，来说明下。
应用要把数据 X 的值从 1 更新为 2，先成功更新了数据库，然后在 Redis 缓存中删除 X 的缓存，但是这个操作却失败了，这个时候数据库中 X 的新值为 2，Redis 中的 X 的缓存值为 1，出现了数据库和缓存数据不一致的问题。
那么，后续有访问数据 X 的请求，会先在 Redis 中查询，因为缓存并没有 诶删除，所以会缓存命中，但是读到的却是旧值 1。
其实不管是先操作数据库，还是先操作缓存，只要第二个操作失败都会出现数据一致的问题。
问题原因知道了，该怎么解决呢？有两种方法：
- 重试机制。
- 订阅 MySQL binlog，再操作缓存。
先来说第一种：重试机制
我们可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。
- 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
- 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。
举个例子，来说明重试机制的过程。
第二种：订阅 MySQL binlog，再操作缓存
「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。
于是我们就可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。
Canal 模拟 MySQL 主从复制的交互协议，把自己伪装成一个 MySQL 的从节点，向 MySQL 主节点发送 dump 请求，MySQL 收到请求后，就会开始推送 Binlog 给 Canal，Canal 解析 Binlog 字节流之后，转换为便于读取的结构化数据，供下游程序订阅使用。
下图是 Canal 的工作原理：
所以，如果要想保证「先更新数据库，再删缓存」策略第二个操作能执行成功，我们可以使用「消息队列来重试缓存的删除」，或者「订阅 MySQL binlog 再操作缓存」，这两种方法有一个共同的特点，都是采用异步操作缓存。
4 思考
（1）当缓存未命中，都去数据库拿，是不是数据库就疯了，所以缓存未命中的话，我们的做法：
- 加锁，只有一个人去拿，并在锁内要注意先取一下缓存，这样一个人拿完，其它的人拿到锁后，发现缓存中有了就直接拿缓存了，不用走数据库了
- 可以直接返回空或者默认值，背后有异步任务会判断缓存是否失效重新放入缓存
（2）我们的数据的根是在数据库，所以上来操作应该是在数据库操作，而不是删除或者更新缓存，因为你不敢保证数据库是百分百的能更新成功的，
- 假如上来就更新缓存，万一数据库失败，你还要还原缓存？删除缓存？
- 假如你上来删除缓存，万一数据库失败，是不是白白删除了，还要引来数据库的至少一次查询组装缓存数据
所以更新上来都应该先对数据库操作。
（3）可能有的人会想，更新完数据库，更新缓存的时候是不是可以根据缓存里的更新时间来比较更新。比如缓存中是20，更新时间是6月1日，现在有21（6月2日 13:14:22），22（6月2日 13:14:23） 的来了，
假如21先更新，22的来了发现我的更新时间更新就把21覆盖调，缓存数据库这时一致。
假如22先更新，21的来了发现我的更新时间比缓存中的22的小，我就不是最新的，我不更新缓存，缓存数据库一致。
看似合理哈，但是有问题，比如21 22 都去更新的时候（都要先从缓存中get一下）发现缓存中失效了（get的都是空），没有对比了，22先写入缓存 ，21再写入，是不是就不一致了。所以还是我们上边说的，get的时候要通过加锁，只有一个人去操作，不管是22 21谁先谁后，比如21先，21写完缓存，22get的时候拿到21发现更新时间比自己小是历史数据，那么22写入自己。22先的话，22写入自己，21get的时候得到22发现更新时间比自己大说明21的数据旧数据，所以21不写了，缓存数据库一致。但其实还是有问题，比如21get的时候，22失效了，21get的就是null，21把自己写入，所以缓存数据库又不一致了。啊啊啊啊，心态崩了。这都是因为21 22 并发是多个线程，所以最好的还是21 22 更新完交给一个第三方，由第三方统一去更新缓存。
为什么是删除缓存，而不是更新缓存呢？
删除一个数据，相比更新一个数据更加轻量级，出问题的概率更小。在实际业务中，缓存的数据可能不是直接来自数据库表，也许来自多张底层数据表的聚合。
比如商品详情信息，在底层可能会关联商品表、价格表、库存表等，如果更新了一个价格字段，那么就要更新整个数据库，还要关联的去查询和汇总各个周边业务系统的数据，这个操作会非常耗时。 从另外一个角度，不是所有的缓存数据都是频繁访问的，更新后的缓存可能会长时间不被访问，所以说，从计算资源和整体性能的考虑，更新的时候删除缓存，等到下次查询命中再填充缓存，是一个更好的方案。
系统设计中有一个思想叫 Lazy Loading，适用于那些加载代价大的操作，删除缓存而不是更新缓存，就是懒加载思想的一个应用。