如何保证缓存和数据库的一致性
a.缓存双删：修改前删，修改后删，可以用aop去实现（不能保证一致性）
b.或者根据业务场景去看，需不需要满足强一致性
c.对强一致性要求特别高需要加业务锁，只要有修改请求进来，立马上一把锁，分布式锁禁止查询///或者加个版本号
d.弱一致性可以考虑修改后删除，如果业务场景不需要满足强一致性，那么可以给缓存都加上过期时间，比如说过期2s，那么这个数据不一致，最多只存在于2s。
缓存双删相关
1.延时双删有啥作用？
为了使得缓存和数据库数据最终一致。
2.为什么要删除缓存数据，而不是修改？
如果是修改，并发修改数据场景，先改缓存的有可能后改库，先改库的也可能后改缓存。
3.为什么要睡眠延时一段时间？
读写分离是解决高并发比较有效的方案，但是缓存/库的主从是异步更新数据的。
睡眠一段时间，就是为了库和缓存能实现数据主从同步。
4.延时双删能确保缓存和数据库最终一致吗？
不能确保。
只能通过延时最大程度上提高数据的最终一致的概率。
如果缓存和数据库负载很高，主从同步很慢，很有可能不能在延时的时间内实现同步。
5.脏读怎么办？
确实有这问题，要知道这是最终一致，并不是强一致，最后一次删除就是为了最终一致
所以要确保你的业务场景能忍受数据最终一致的缺陷，实在不行你读主库呗。
优化业务逻辑的设计，具体请参考下文的：通过业务设计加强数据一致性 章节。
6.为什么要有第一次删除缓存？
1> 删除脏读。
2> 提前实现其它操作的数据最终一致。
延时双删有 4 个步骤，全部执行完才能实现数据最终一致，可能会比较慢！
