(二)分布式事务？No, 最终一致性（2）

最终一致性解决方案

1. 两阶段提交

2.异步确保（没有事务消息）

3.异步确保（事务消息）

4. 补偿交易（Compensating  Transaction）

5.消息重试

6.幂等（接口支持重入）

A给B转100元。

1. 两阶段提交

有协调者，协调操作流程。Pre commit锁资源，commit或rollback时提交或释放资源。

调用A的commit接口超时了，继续重试。要求下游接口幂等。下游故障，短时重试不能解决，定时处理中间状态：扔到重试MQ。重试策略，失败返回

2.异步确保（没有事务消息）

不只为一致性，考虑响应时间，下游稳定性等

关键要有消息表。一般有队列(不丢消息，但不支持事务消息)，基本思路：

生产方：消息表记录消息发送状态，和数据一个事务提交(存储耦合)。只是增加一个字段跟业务强耦合，处理不同交易数据可通用处理。

消费方：需处理消息成功，给生产方confirm。失败放MQ。支持重试省事儿，不支持放回队尾或建队列处理。如成功才继续，block（不会这么做）。Kafka lowlevel接口是支持自己设置offset的，可实现block。

生产方定时扫描本地消息表，没处理完的消息由发送一遍。自动对账补账，这一步可省略。丢消息或者下游处理失败场景少。看业务上能不能容忍不一致到对账补账周期。

ps：不要MQ。脚本处理低频场景，离线扫表让人不爽。业务量初期也可以

一致性要求不高兜底方案（对账补账），不需要confirm，扔给消息万事大吉

3.异步确保（事务消息）

理想：消息扔到MQ，肯定被消费成功。不用担心失败，丢失。

现实：处理失败，继续消费，直到成功为止

大部分MQ都不支持事务消息比如kafka。RocketMQ号称支持，事务消息关键封装消息状态和重发等。没成熟事务消息MQ。网传RMQ提供2PC提交接口。

1.生产方发送prepared消息给RMQ。、失败返回。

2.执行本地事务，成功发Confirm消息给RMQ。失败，调用RMQ cancel接口。

3.步超时如何处理呢？

4.生产方实现check接口，告知RMQ自己本地事务是否执行成功（第4步）。定时轮训pre消息，调用check接口，决定是否可提交。

5.可能失败。这时候需要RMQ支持消息重试。处理失败的消息果断时间再进行重试，直到成功为止（超过重试次数后会进死信队列，可能得人肉处理了，因为没用过所以细节不是很了解）。

支持消息重试

P.S. 阿里内部因历史原因，用notify比RMQ要多，原理类似。

4. 补偿交易（Compensating  Transaction）

和操作本身一个事务里完成。跟2PC比，核心价值少锁代价。

如A:-100  B:+100。如B:+100失败，补偿A:+100。看起来跟注册个单库事务一样简单。做到业务无感知。

5.消息重试

事务消息解决生产者和MQ之间一致性，重试确保消费者和MQ之间的一致性

pull，push模式。失败，放重试队列。延迟时间固定（2s），队首消息，时间到达才被消费。

时间为水位，期望执行时间大于当前时间的消息高于水位。其他消息对consumer不可见。如消息延迟时间不一样：

(1)基于队列方案：按秒建多个队列。按执行时间入不同队列，一天86400个队列（一般丑陋）。按时间消费不同队列。

(2)基于DB：不依赖队列，支付时消息进去时候，设置下次执行时间，对时间做索引

(3)redis的延时队列，支持重试。zset按处理时间排序。遇到的持久化问题，内存数据丢失问题，重试次数控制，消息追溯等

总结：MQ提供消息重试最好

6.幂等（接口支持重入）

没有MQ，重试也是无处不在的。幂等怎么做？

insert，依赖唯一键，异常回滚事务。

update，那么状态机控制和版本控制异常重要。这里要多加小心。

引入log表。该log对操作id（消息id？）插入log失败整个回滚

不能查log表或者用redis，加锁。除非在事务里查。唯一键冲突回滚掉就好

用唯一键挡重入是目前为止个人觉得最有安全感的方式。当然对数据库会有一些额外性能损耗。问题就变成了有多大的并发，其中又有多大是需要重试的？

Fasion IO卡+分库分表之后，不会到db性能瓶颈（对金融类场景）。

后记

最终一致性问题，万恶之源是RPC本身会失败。生涯大部分时间都会跟各种失败和timeout搏斗了。用MQ实现最终一致性原因：

1. MQ强大，可不丢数据。对事务消息更普及。

2. 异步处理能力（响应时间、吞吐量）和稳定性（99.99%的服务依赖99.9%的服务）服务之间解耦

https://zhuanlan.zhihu.com/p/25933039