资料内容：
方案一：延时双删
先删除缓存
再更新数据库
休眠一会（比如1秒），再次删除缓存。
这个休眠一会，一般多久呢？都是1秒？
1 这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。
这种方案还算可以，只有休眠那一会（比如就那1秒），可能有脏数据，一般业务也会接受的。但是如果第二次删除缓存失败呢？缓存和数据库的数据还是可能不一致，对吧？给Key设置一个自然的expire过期时间，让它自动过期怎样？那业务
要接受过期时间内，数据的不一致咯？还是有其他更佳方案呢？
方案二： 删除缓存重试机制
因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制
删除缓存重试流程:
写请求更新数据库
缓存因为某些原因，删除失败
把删除失败的key放到消息队列
消费消息队列的消息，获取要删除的key
重试删除缓存操作
方案三：读取biglog异步删除缓存
重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。
其实，还可以这样优化：通过数据库的binlog来异步淘汰key。
