数据不一致，问题可能比你想象的更严重
上周三晚上十点，某电商平台的订单系统突然出现异常。用户下单成功后，库存没扣减，财务系统也没收到付款记录。运维团队紧急排查，发现是数据库主从同步延迟导致的数据不一致。这种情况在高并发场景下并不罕见，但一旦发生，轻则客户投诉，重则造成资损。
作为服务器维护人员，我们不能等到出事才去救火。提前设计好数据一致性保障方案，才是真正的专业体现。
什么是数据一致性？
简单说，就是同一份数据在不同地方、不同时间看起来都是一样的。比如用户充值100元，账户余额增加的同时，交易记录也要同步更新。如果只改了一边，另一边没跟上，就叫“数据不一致”。
常见的一致性问题场景
跨库操作是最容易翻车的地方。比如订单服务和库存服务各自用独立数据库，下单时要同时写订单表和减库存。网络抖动或服务宕机可能导致一个成功一个失败。
缓存也是个雷区。数据库更新了，Redis 没及时失效，下一次请求拿到的还是旧数据，用户看到的就是“钱扣了但商品没到账”。
基于事务的本地保障
单库操作优先用数据库事务。MySQL 的 InnoDB 支持 ACID，把相关操作包进 BEGIN 和 COMMIT 之间，出错自动回滚。
BEGIN;<br>INSERT INTO orders (user_id, amount) VALUES (1001, 99.9);<br>UPDATE inventory SET stock = stock - 1 WHERE product_id = 101;<br>COMMIT;只要两条语句都在同一个数据库里，这套机制很可靠。但微服务架构下，数据分散在各处，就得靠别的手段。
分布式事务：两阶段提交（2PC）
当多个服务必须协同完成一件事时，可以用 2PC。它分准备和提交两个阶段，所有参与者都同意才真正执行。
缺点也很明显：中间状态会锁资源，性能差，协调者挂掉整个流程就卡住。实际生产中用得不多，除非对一致性要求极高，比如银行转账。
最终一致性 + 补偿机制
大多数互联网系统选择最终一致。允许短暂不一致，但通过异步任务尽快修复。
比如下单失败后，发一条消息到 Kafka，由专门的补偿服务监听并重试扣库存。搭配定时对账脚本，每天凌晨扫一遍订单和库存，发现差异就报警或自动修正。
缓存一致性策略
别再用“先更新数据库再删缓存”这种老套路了。网络问题可能导致删除失败，缓存里还是旧值。
推荐“延时双删”：更新数据库 → 删除缓存 → 睡眠几百毫秒 → 再删一次。或者更彻底的，用 Binlog 订阅机制，通过 Canal 监听 MySQL 变更，精准清理对应缓存。
监控和告警不能少
再好的方案也得靠监控兜底。在关键业务路径埋点，记录数据变更前后状态。定期跑一致性校验脚本，像核对银行流水一样比对核心表。
某社交平台曾因点赞数和实际记录对不上被用户截图传播，影响很坏。后来他们在每小时自动生成统计报告，偏差超过0.1%就触发告警。
数据一致性不是一次性工程，而是持续维护的过程。方案选型要看业务容忍度，金融类宁可慢也不能错，电商可以接受短暂延迟，但必须可追溯、可修复。