java架构设计面试题-对账系统-分布式事务一致性

主流实现分布式系统事务一致性的方案：

1、最终一致性：也就是基于 MQ 的可靠消息投递的机制；

2、基于重试加确认的的最大努力通知方案。

理论上也可以使用（2PC两阶段提交、3PC三阶段提交、TCC短事务、SAGA长事务方案），但是这些方案工业上落地代价很大，不适合互联网的业界场景。针对金融支付等需要强一致性的场景可以通过前两种方案实现。（展开说的话参考分布式事务）

本地数据库事务原理：undo log（原子性） + redo log（持久性） + 数据库锁（原子性&隔离性） + MVCC（隔离性）

分布式事务原理：全局事务协调器（原子性） + 全局锁（隔离性） + DB本地事务（原子性、持久性）

一、我们公司账单系统和第三方支付系统对账时，就采用“自研补偿/MQ方案 + 人工介入”方式

落地的话：方案最“轻”，性能损失最少。可掌控性好，简单易懂，易维护。 考虑到分布式事务问题是小概率事件，留有补救余地就行，性能的损失可是实打实的反应在线上每一个请求上

二、也了解到业界比如阿里成熟Seata AT模式，平均性能会降低35%以上

我觉得不是特殊的场景不推荐

三、RocketMQ事务消息

听起来挺好挺简单的方案，但它比较挑业务场景，同步性强的处理链路不适合。

【重要】要求下游MQ消费方一定能成功消费消息。否则转人工介入处理。
【重要】千万记得实现幂等性。