掘地三尺搞定Redis与MySQL数据一致性问题(5)

不经常请求的数据也会写入缓存，从而导致缓存更大、成本更高。

2.4 Write-Behind

这个图一眼看去似乎与 Write-Through 一样，其实不是的，区别在于最后一个箭头的箭头：它从实心变为线。
这意味着缓存系统将异步更新数据库数据，应用系统只与缓存系统交互。
应用程序不必等待数据库更新完成，从而提高应用程序性能，因为对数据库的更新是最慢的操作。

Write-Behind
这种策略下，缓存与数据库的一致性不强，对一致性高的系统不建议使用。

3. 旁路缓存下的一致性问题分析

业务场景用的最多的就是 Cache-Aside (旁路缓存) 策略，在该策略下，客户端对数据的读取流程是先读取缓存，如果命中则返回；未命中，则从数据库读取并把数据写到缓存中，所以读操作不会导致缓存与数据库的不一致。
重点是写操作，数据库和缓存都需要修改，而两者就会存在一个先后顺序，可能会导致数据不再一致。针对写，我们需要考虑两个问题：
先更新缓存还是更新数据库？当数据发生变化时，选择修改缓存（update），还是删除缓存（delete）？
将这两个问题排列组合，会出现四种方案：
先更新缓存，再更新数据库；先更新数据库，再更新缓存；先删除缓存，再更新数据库；先更新数据库，再删除缓存。
接下来的分析大家不必死记硬背，关键在于在推演的过程中大家只需要考虑以下两个场景会不会带来严重问题即可：
其中第一个操作成功，第二个失败会导致什么问题？在高并发情况下会不会造成读取数据不一致？
为啥不考虑第一个失败，第二个成功的情况呀？
你猜？
既然第一个都失败了，第二个就不用执行了，直接在第一步返回 50x 等异常信息即可，不会出现不一致问题。