分布式事务可行解决方案

2PC

image.png

2阶段提交第一阶段询问个服务参与者是否能提交事务，参与者记录事务日志，需要等待所有服务反馈yes才执行事务，有服务返回no/超市未响应则中断，对性能上损耗明显。之后执行事务。2阶段事务解决方案存在单点故障的问题，当协调者宕机，参与者会处于阻塞响应阶段，一直不释放资，即使协调者通过选举机制恢复使用，也无法解决阻塞的问题。同时存在事务环节中数据不一致的问题。

3PC

image.png

3阶段提交，canCommit阶段发送指令，等待所有服务反馈，与2阶段提交相似。服务都返回yes则进入preCommit阶段，等待服务反馈可执行ack，并记录事务日志。如果服务都返回可执行，则提交事务请求，否则取消事务。在doCommit阶段则返回服务执行结果决定是否rollback事务。3阶段提交引入超时机制，对于参与者节点反馈超时的情况执行事务中断，但仍然存在数据不一致问题。

TCC

image.png

TCC三个操作分别如下：
Try：预留业务资源
Confirm：确认执行业务操作
Cancel：取消执行业务操作
应用向TM提出事务请求，TM向各服务节点发起try请求。服务节点返回失败，则执行参与者的cancel方法。如果参与者都返回ok，则调用commit参与者的方法，这是参与者的commit都返回ok则事务完成，否则重试或作事务补偿。

使用MQ可靠消息

image.png

通过MQ的可靠消息实现数据的最终一致性。在服务1调用服务2的场景下，通过MQ做中间过渡作用。服务1业务下事务完成，则发送消息到MQ，并记录发送的消息记录，MQ返回ack再更新消息状态为发送成功。消费端消费MQ消息，实现自身服务的业务，记录接受的消息记录。事务处理成功则返回ack到MQ，不成功记录消息消费记录，并通知MQ重发。其中需要设计消息的容错策略，例如：生产者发送消息失败，可以通过定时任务判断消息的状态及产生时间进行重试处理。消费者则需要做接口的幂等，防止消息重复消费。
另外对于消息消费失败重试次数达到一定次数的进行告警并分析原因人工处理。通过MQ的实现方式通用性强，拓展性高，但需要业务上能够容忍异步的延迟。

---