redis与数据库的一致性是个老生常谈的话题，也是面试官的最爱，之前我没有总结过，所以总是答的不完善，所以我把我知道的方案做了个总结，应该算是比较全，拿来做方案或者应付面试官应该是绰绰有余的。
这里我把更新和删除数据，都合成一个操作，对于redis来说都是删除，然后请求再访问，redis拿不到数据就直接数据库拿，数据库拿到就塞到redis，数据库没有的话，就什么也不做了。
一. 先 删除或者更新数据库，然后再删redis缓存。
这种操作的问题是在操作完数据库，再去删除缓存的时候，如果操作redis缓存的请求因为存在
网络抖动，或者一些不可预测的问题(redis宕机或者短时不可用)，这样redis就是旧数据，然后就存 在的数据不一致的情况。对于这种情况，可以在代码里做处理，如果redis操作不成功，可以把这个请求，单独推到一个队列里，至于什么队列，自己斟酌，可以上mq中间件，也可以用java的一些阻塞队列，不过中间件还是最靠谱的。然后搞一个线程来消费队列，消费端进行重试删除，可以设置一个阈值，比如重试3次，因为有时候，故障不是可以及时恢复的，一直重试，占用资源，造成浪费。
二. 先删除redis缓存,再操作数据库。
这个方案乍一看，好像很完美。先把redis删了，再操作数据库，及时操作数据库这一步挂了，
再去访问数据库，然后再刷到redis里，这数据还是一致的呀？好像没什么问题，但是细想一下如果
在删完redis的瞬间，另外一个请求又去查，查到redis没有值，然后就去数据库里拿了，这时候旧请求还没来得及做操作，新的请求就把旧数据又刷到缓存里了，然后旧请求执行完数据库操作，这时候，数据就又不一致了。。。其实在低并发情况下，这种情况发生的概率并不大，但是作为一个严谨的程序员，咱们必须想到这个问题。
怎么解决这个问题呢？这就诞生了一种，延迟双删，刚才那个旧请求删完redis之后，操作完数据库，再删一次redis，这样即使新的请求把旧值刷到redis,旧的请求也能把它搞掉，这样，再来请求访问的仍旧是最新值。其实我之前一直有个疑问：把旧值刷到redis的这个请求拿到的就不是旧值吗？
后来细想了下，你拿这个值的时候，数据库还没改呢，所以在逻辑上说，这时候数据还是一致的。
问题又来了，什么时候再去做一次删除呢？这个就不太好说呢，理论上是大于一次请求的时间，但是具体还得做测试去评估。
三. 搞一个定时任务，隔段时间去检查不一致的数据，校对之后做更新。
这种方案应该是比较差的一个方案，如果你面试说了，可能不背面试官认可，哈哈哈。
四. 利用中间件
基于canal这类同步中间件，原理也是数据库的log推给canal,然后canal推到相应的mq，监听
mq的消费端去执行redis相应数据操作。这种方案我也只是了解，所以也不详细说了。
从上面几个方案看，其实没有太完美的方案，其实都是带有一些延迟滞后的，如果要追求极致的
一致性，个人认为还是放弃Redis吧哈哈哈。
就我个人来说，我比较喜欢第二种方案，因为代价是最小的。
