首先分为三种一致性：
强一致性： 完全的一致，数据库里是什么，redis就是什么
弱一致性： 数据库和redis存在不一致的情况
最终一致性： 某些时刻是弱一致但是最终会保证完全的强一致
方案一:
读的时候先读缓存，缓存没有再读数据库。
写的时候先修改数据库，在后再删除缓存。
方案二：
写的时候只更新缓存，不更新数据库，通过异步的方式来更新数据库。
项目采用的方案：
读的时候先读缓存，缓存没有再读数据库。
写的时候先更新缓存，再异步修改数据库，修改成功删除缓存。
问题1：为何是删除缓存不是更新缓存
更新缓存存在脏数据的问题。
假设两个线程A和B
线程A先更新了数据库，然后线程B再更新数据库。
但是由于网络原因，线程B先于线程A更新缓存，线程A将旧的数据更新到缓存中，从而出错。
问题2：为何是先更新缓存再操作数据库
假设一个下单的场景
A用缓存中的库存判断发现库存足够，进入数据库完成库存扣减下单操作，这是B来了又判断，发现缓存中库存也足够进入数据库完成库存扣减下单操作，但是A扣减完库存后库存不足了，这就导致了B扣减失败。
问题3：为何不先删除库存再操作数据库。
假设另外一个场景A写数据，B读数据
A发起一个写操作，将库存删除
此时B读取数据库相关信息，发现没有缓存进数据库读取，保存缓存
这个时候A再修改数据库，最后缓存中保存的还是老的数据。
保证最终一致性方案：
1.采用延迟双删策略
先删除缓存
再写数据
休眠一段时间（读业务时间+redis和数据库主从同步的耗时）
再删缓存
缺点：休眠时间难以把控，请求耗费时间长
2.删除重试机制
以上方案建立在删缓存成功的情况，如果删除失败
写请求更新数据库
由于某些原因缓存删除失败
把失败的key放在消息队列里面
消费消息队列的消息，获取要删的key
重试删除缓存
缺点：会造成大量业务代码入侵
3.读取biglog异步更新缓存
通过数据库的binlog来异步淘汰key
MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。
