mysql双主双写一致性_分布式之数据库和缓存双写一致性方案总结

总结：

强一致性和缓存，这个本身就是伪命题。。用了缓存，只能保证最终一致性

一定有可能在一段时间内，缓存是不新鲜的，哪怕只是几百毫秒。

像下订单这种要求不能出错的业务场景，如果真的超大并发，只能是通过增加集群，分库分表，总之就是各种路由分流策略来提升吞吐量，尽可能的去避免并发带来的问题，最后配合多重补偿机制来保证近似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尝试进行处理。

根据业务来吧