前言
第一篇我们大概讲了4种保持缓存和数据库一致性的方式，那是不是就只有第四个方式是真爱呢？其他方式就完全不能用了呢？
1、优化先删除缓存，再更新数据库策略
对于方案2先删除缓存，再更新数据库 我们来抢救下改造成删除-->更新-->延时删除
image.png
上述的操作就是所谓的延时双删。这种策略可以解决原来方案的缺陷，同时当我们的数据库是主从同步时，也可以采用延时双删策略。
具体的延时时间可以根据主从同步的延时时间基础上，加几百ms。
2、复杂场景-读写分离
当我们使用mysql读写分离时，读操作是访问的是从库，主库和从库之间同步数据是需要时间的。
image.png
同样可以使用延时双删
但是使用双删多了一步，系统的吞吐量会降低，我们可以采用启动线程异步延时操作。
如果删除再失败怎么办，可以采用补偿保证最后删除成功。
3、更新数据库，再删除缓存（最佳实践）
这个策略我们上一篇说过，是我们推荐的最佳实践，但它就没有问题了吗？
image.png
假设2个并发线程，A正好写，B正好读，同时缓存里没有数据。
1、B读数据库，取出旧数据，还没写入缓存
2、A这时更新数据库，并且删除缓存后，B才写入缓存
也是说B先读数据库+写缓存，比A更新数据库+删缓存要慢，这个概率还是比较低的，但如果真出现这种情况，该如何处理。可以延迟删除操作，保证在读完再删除。
4、异常情况
上面都没有考虑
5、Cache Aside Pattern
翻译过来是旁路缓存方案的经验实践，这个实践分为读实践、写实践。
