适用对象：后端架构师 / 高级开发 / 分布式系统设计者
适用场景：订单系统、支付系统、库存系统、账户系统、积分系统、异步解耦系统
MQ 示例：RocketMQ（Kafka、Pulsar 原理一致）

一、问题背景：为什么分布式系统一定会“不一致”？

在微服务架构中，最常见的模式是：

业务服务 → MySQL → MQ → 下游服务

但 MySQL 与 MQ 是两个独立系统：

• MySQL 成功，MQ 失败 → 消息丢失
• MQ 成功，MySQL 回滚 → 脏消息
• MQ 重复投递 → 重复消费
• 消费端失败 → 状态不一致

这本质是一个 分布式事务问题。

二、定性：为什么选择最终一致性？

CAP 定理告诉我们：

在 MQ + DB 场景中：

不可能同时满足 C + A + P

如果追求强一致性： - 性能下降 - 系统复杂度指数级上升 - 容错能力下降

因此业界选择：

最终一致性 = 工程最优解

</