https://www.cnblogs.com/rjzhe…
https://www.cnblogs.com/rjzhe…
https://www.cnblogs.com/rjzhe…
总结：
强一致性和缓存，这个本身就是伪命题。。用了缓存，只能保证最终一致性
一定有可能在一段时间内，缓存是不新鲜的，哪怕只是几百毫秒。
像下订单这种要求不能出错的业务场景，如果真的超大并发，只能是通过增加集群，分库分表，总之就是各种路由分流策略来提升吞吐量，尽可能的去避免并发带来的问题，最后配合多重补偿机制来保证近似 100% 的准确性。
一般互联网方案不会这么做的，有几个前提我们需要了解下。
1.cache 一定是缓存数据，不能当存储用，也就是说缓存的数据可以丢失。
2. 既然使用 cache 一定是能接受非实时一致性的，也就是说缓存不需要实时一致性，因为 cache 在多接点的情况下在加上 HA 的策略是无法做到实时一致性。
3.cache cluster 是多 node 工作，就拿 redis 简单的主从结构来说，也会存在复制延迟的问题，在业务设计上就已经考虑了这种场景的出现。
当使用 redis cluster 或者 cache proxy 方案 在加上跨机房问题这种问题出现的概率是非常大的，所以在设计架构的时候是必须要考虑进去的，整个 cache 架构一定是柔性的和被动 + 主动的 cache 策略。
4. 一般简单使用做法 db 数据操作成功后只会 del 掉 cache key 不会执行容易 blocking cache 实例的操作。
5.cache 的数据很多时候是在业务逻辑中产生的，所以你无法把刷入 cache 数据的代码从业务代码中剥离出来。这里还有一个就是 MQ 带来的一致性问题，MQ 不管是 push 模式还是 poll 模式都会一定程度的产生重复消息，所以也要考虑幂等问题。
so。。。。。
在分布式情况下，任何的一致性都是有代价的，牺牲系统的吞吐量和稳定性，所以分布式系统的可用性和稳定性及性能之间的平衡是架构设计的永恒话题。
建议采用更新 db+ 删除缓存的方式
如果删除缓存失败，看业务重要程度：
- 不重要的业务，如果返回脏数据没问题，就直接返回，让缓存自然过期即可
- 重要的业务，返回定义的错误码提示，可采用手工或者 worker 尝试进行处理。
根据业务来吧
主从不一致的方案：
https://mp.weixin.qq.com/s?__…