一、定义
参考百度百科定义:
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
二、分布式事务的理论
2.1 CAP理论
CAP 是指在一个分布式系统下, 包含三个要素:Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),并且三者不可得兼。
-
C:Consistency,一致性,所有数据变动都是同步的。
-
A:Availability,可用性,即在可以接受的时间范围内正确地响应用户请求。
-
P:Partition tolerance,分区容错性,即某节点或网络分区故障时,系统仍能够提供满足一致性和可用性的服务。
2.2 Base理论
BASE 理论主要是解决 CAP 理论中分布式系统的可用性和一致性不可兼得的问题。BASE 理论包含以下三个要素:
-
BA:Basically Available,基本可用。
-
S:Soft State,软状态,状态可以有一段时间不同步。
-
E:Eventually Consistent,最终一致,最终数据是一致的就可以了,而不是时时保持强一致
三、一些实际的解决方法
3.1最大努力通知系统
应用场景:支付宝支付成功通知、短信通知
适用场景:对数据一致性要求不是特别高的场景,不是主业务流程的场景
最佳实践: 无
最大努力通知系统包含三个主题:上游应用、最大努力通知、下游应用
3.1.1发送通知时序
3.1.2 补偿时序
3.2可靠性消息系统
开源方案:myth(https://github.com/yu199195/myth)
可靠性消息系统包含三个主体:业务方、可靠消息服务、接收方
可靠性消息系统时序
3.2.1、发送消息系统时序
3.2.2、消息确认以及重发时序
针对3.1.1的4、5、6、10失败情况导致不一致情况的时序
3.3 TCC(Try-confirm-cancel)
业界实现方案:
atomkos
ByteTCC(https://github.com/liuyangming/ByteTCC.git)
hmily(https://github.com/yu199195/hmily)
EasyTransaction(https://github.com/QNJR-GROUP/EasyTransaction)
适用场景:long-running transaction,数据一致性要求高。如各种支付场景。
3.3.1 业务说明