适用对象：后端架构师 / 高级开发 / 分布式系统设计者
适用场景：订单系统、支付系统、库存系统、账户系统、积分系统、异步解耦系统
MQ 示例：RocketMQ（Kafka、Pulsar 原理一致）
一、问题背景：为什么分布式系统一定会“不一致”？
在微服务架构中，最常见的模式是：
业务服务 → MySQL → MQ → 下游服务但 MySQL 与 MQ 是两个独立系统：
- MySQL 成功，MQ 失败 → 消息丢失
- MQ 成功，MySQL 回滚 → 脏消息
- MQ 重复投递 → 重复消费
- 消费端失败 → 状态不一致
这本质是一个 分布式事务问题。
二、定性：为什么选择最终一致性？
CAP 定理告诉我们：
| 属性 | 含义 |
|---|---|
| C | 强一致性 |
| A | 可用性 |
| P | 分区容错 |
在 MQ + DB 场景中：
不可能同时满足 C + A + P
如果追求强一致性： - 性能下降 - 系统复杂度指数级上升 - 容错能力下降
因此业界选择：
最终一致性 = 工程最优解
</
