如何保障mysql和redis之间的数据一致性？

前后双删除解决了MySQL和Redis的不一致问题。

先清除缓存，再更改数据库。
5 00毫秒后，再次清除缓存。

使用MQ异步清除缓存更加可靠。

缓存设置1 小时后过期，可解决。

无法删除缓存。
再试一次。

先清除缓存，再更改数据库。
监控数据库binlog并写入MQ。
MQ 使用并更新缓存。

使用 MQ 分区来确保顺序缓存刷新。

先读缓存，漏读数据库。
数据写入MQ，稍后清除缓存。

自己掂量一下。

如何去衡量数据库的一致性和业务连续性

说实话，谈数据一致性和业务连续性是我刚创业时很头疼的事情。
后来我觉得我发现自己把它拆开并看到了它。
每个场景在被揭示之前都对应着一个特定的操作。

先说数据库一致性。
这件事给我印象最深的是，在某理财计划中，问题被业主复制，数据延迟了五分钟。
你知道这有多可怕吗？某用户A刚刚查看了1 00元的余额，立即将钱转给了用户B。
于是，同步后，他发现用户A的余额突然变成了0，而用户B却没有收到钱。
幸好他们用的是补偿服务，不然机房里早就被投诉淹没了。
因此，一种技术上的同步机制，比如Raft算法，听起来很高端，但是如果在测试中无法观察到日志，那就真的很不方便了。
我记得每天都会观看测试同步。
如果延迟超过两秒，它将进行监控并强制开发团队将复制间隔调整为更好的值。

再次关注服务的一致性。
我遇到过的最令人沮丧的案例是电子商务系统。
后端架构从单主动改为双主动后，我突然发现两个射击中心的规则不一致。
用户同时打开两个浏览器。
浏览器A显示购买超过2 00的折扣为3 0，浏览器B显示购买超过1 9 9 的折扣为2 5 最后，系统抱怨它到达了。
说白了，这是因为跨数据中心逻辑不统一，价格计算实际上是在本地配置的，导致数据不一致。
后来他们改变了所有柜台的中央配置服务，问题就解决了。

会话一致性也是一个常见问题。
有一次在一次远程容灾演习中，我突然发现，登录用户访问数据中心后，购物车里的物品全部被清空了。
其实很简单。
会话存储不同步。
他们正在使用集群，但配置中未启用复制。
后来我们切换到Redis watch模式，会话状态自动同步，所以没有出现错误。

作为业务连续性，我参与了保险系统的升级，直接从单活变成了多活架构。
这个过程就像炸弹一样爆炸。
首先，机房数据全量同步运行7 7 4 9 天，上线延迟小于5 00毫秒。
有趣的是，他们实际上在周末做了一次模拟失败，当测试通过时，一些用户反映“订单状态为灰色”。
后来发现延迟是消息队列丢失造成的，最终公开添加了灰度机制来解决问题。

说到信息的准确性，我印象最深刻的是物流系统。
后者用作最终一致性的示例。
结果，用户看到“包裹已密封”，但送货员根本没有去。
原因是没有正确完成强一致性要求，物流状态更新实际上使用了最终一致性。
最后他们改成MQ的确认消息模式，每次签收时都发送确认消息，问题就解决了。

因为归根结底，这些维度中我最关心的是所需要的一致性程度。
比如社交系统的点赞数，A用户刚刚点赞了B，C用户看到他还是0，肯定会骂死的。
但对于电商库存来说，如果用户A下单，用户B立即购买，就说明它还在品类中，也就是根本不可能。
当时我不明白为什么游戏中的武器掉落行为会延迟销售和闪现，但是转账到银行系统会实时到账。
后来我才意识到，这是出于监管要求和用户期望。

我们个人还没有遇到过这方面的原生场景，但听说现在很多大厂都在使用混合一致性模型，比如系统级一致性的鲁棒一致性和用户镜像的未来一致性。
不管怎样，还是根据业务场景选择最合适的。
从数据上我们记得目前分布式事务的协议都是在Paxos中进行优化的，比如SAGA方式，但是具体的环境还是要看你的业务场景。

MySQL 怎么保证备份数据的一致性？