如何保证缓存和数据库一致性

[TOC]

多年前在一次面试中，被问到如果数据更新，先修改数据库还是先修改缓存。因为没有想过，所以比较懵逼，时候赶紧搜索，发现这里面很有学问。基本上所有的文章最终都指向了两个地方，就是oracle和Hazelcast对缓存更新策略的介绍。

Cache-Aside

常见的应用端策略，从数据库加载数据到缓存的模式。

应用服务自己选择是否使用缓存，并维护缓存的生命周期。这是最简单的实现方式，但是会有遇到一些问题。分为两种情况：

读取数据

检查缓存遗漏，然后查询数据库，填充缓存

1. 尝试读缓存
2. 如果命中，返回数据
3. 如果未命中，查询数据库，并写入缓存

这会导致缓存击穿，需要双重检查锁定（Double Check Lock）确保单个线程访问数据库，但是会增加锁开销。

修改数据

修改数据库和缓存，因为缓存和数据库是两个系统，操作的先后顺序会导致一致性问题。

通常由几种方案：

先更新数据库，后更新缓存

如果两个线程同时更新，先更新的线程因为某些原因（时间片耗尽），后更新缓存，那么缓存里就是脏数据。

participant 业务
participant 数据库
participant 缓存
业务->数据库: A线程：更新
业务->数据库: B线程：更新
数据库->数据库: A线程：挂起
数据库->缓存: B线程：更新
数据库->缓存: A线程：更新

先更新缓存，后更新数据库

数据库错误，然后回滚了，但是这段时间里，缓存被用了。

participant 业务
participant 数据库
participant 缓存
业务->数据库: A线程：更新
数据库->缓存: A线程：更新
业务->缓存: B线程：获取
缓存->业务: B线程：取得未提交的数据
缓存-->数据库: A线程：更新
note right of 数据库:回滚

先删除缓存，后更新数据库

一个线程删除了缓存，还没来得及更新数据库，另一个线程来取缓存，发现取不到，查询数据库，并把旧数据放入缓存。最后数据库被更新为最新值。

participant 业务
participant 缓存
participant 数据库
业务->缓存: A线程：删除
业务->缓存: B线程：获取
缓存-->业务: B线程：未命中
业务->数据库: B线程：查询
数据库->缓存: B线程：更新
缓存->数据库: A线程：更新

先更新数据库，后删除缓存

先更新数据库，后删除缓存，如果失败直接回滚，其他线程不会读到脏数据。事务提交后，后续线程从数据库读取最新值放入缓存。会引起缓存击穿，需要做DCL。在极端情况下，线程在删除缓存之前被终止，那么缓存里是脏数据。

participant 业务
participant 缓存
participant 数据库
业务->数据库: A线程：更新
数据库->缓存: A线程：删除
业务->缓存: B线程：获取
缓存-->业务: B线程：未命中
业务->数据库: B线程：查询
数据库->缓存: B线程：更新

还有一种更极端的情况，当前一个线程删除缓存之后。A线程查询缓存miss，然后查询数据库，并试图更新缓存，但是被挂起。此时B线程更新数据库，并删除缓存，然后A获得时间片，将B更新前的旧数据放入缓存。缓存里成为了脏数据。

Read-Through

应用尝试获取缓存时，如果未命中，由缓存负责查询数据库并更新缓存，然后返回数据。

Write-Through

尝试更新数据时，只更新缓存数据，由缓存负责把修改同步到数据库。如果操作数据库异常，则回滚事务，把异常抛给应用。

Read-Through和Write-Through 通常是缓存服务一起提供的策略，如果缓存服务不支持，需要自己动手封装。本质上就是把缓存操作纳入事务管理，由缓存服务封装在一起提供给应用。应用只需提供对数据库操作的实现，然后使用缓存即可。

仍然存在极端情况，即服务更新缓存后，在写入数据库之前被终止。

Write-Behind

一种缓存服务端的策略，当应用尝试更新数据时，只更新缓存数据。缓存服务会把修改放入一个队列，异步的更新到数据库。

有的缓存服务会批量同步，并合并对同一条记录的多次操作，只更新最新记录。

如果更新数据库异常，需要不断重试，知道数据库更新成功，因为缓存中数据已经生效。

这样做有四个优点：

• 对应用来说，性能更好，因为不需要等待数据库写入，只需要更新缓存，而缓存更新很快。
• 数据库压力减少了，因为会合并多次写操作，对于大量修改的数据，数据库只需执行最后一次。
• 减少数据库故障对应用的影响，因为即使数据库故障，应用仍然可以对缓存进行读写。
• 可扩展，当并发压力过大时，只需要增加缓存或者延长同步间隔，即可减小对数据库压力。

但是必须先解决几个问题：

• 数据库事务绝对不能失败。
• 缓存的同步操作不能跟其他应用对数据库的修改冲突。
• 缓存成为了数据库，所以必须支持持久化。
• 故障转移/故障恢复会导致数据丢失。

还有一种类似做法，就是通过订阅Mysql的binlog，异步更新缓存。可以保证最终一致性，但是需要容忍一定的延迟。

Refresh-Ahead

相比于上述为了保证一致性的策略，这是一个辅助措施。即对于设置了过期时间的缓存，在即将到期时，异步查询数据库，更新到缓存。能够尽可能减少脏数据，并保证一致性和效率。这是因为：

• 设置缓存有效期，并定时从数据库更新，可以尽量保证一致性
• 提前从数据库更新，防止缓存过期后导致的缓存穿透问题或为了解决缓存穿透加锁导致的性能开销。

总之，分布式系统很难两全其美，需要在A和C之间做出取舍，根据业务需要和经济基础选择最合适的方案。

其他参考资料：

• https://www.pixelstech.net/article/1562504974-Consistency-between-Redis-Cache-and-sql-Database