分布式事务常用的解决方案及优缺点

全局事务(DTP模型) --标准的分布式事务

分布式事务常用的解决方案及优缺点_第1张图片

全局事务(DTP模型) --XA协议

分布式事务常用的解决方案及优缺点_第2张图片
mysql oracle 都是实现了XA协议

两阶段提交(Two Phase Commit)

分布式事务常用的解决方案及优缺点_第3张图片

J2EE平台中分布式事务的实现

分布式事务常用的解决方案及优缺点_第4张图片

标准分布式事务解决方案的利弊
  • 优点:
    严格的ACID
  • 缺点:
    效率非常低(微服务架构不太适用)
    • 全局事务下,全局事务管理器(TM) 通过XA接口适用两阶段提交协议(2PC) 与资源层(如数据库)进行交互。使用全局事务,数据被Lock的时间跨越整个事务,直到全局事务结束
    • 2PC是反可伸缩模式,在数据处理过程中,参与者需要一直持有资源直到整个分布式事务的结束。这样,当业务规模越来越大的情况下,2PC的局限性就越来越明显,系统可伸缩性就会变得很差
    • 与本地事务相比,XA协议的系统开销很大,因而应当珍重考虑是否确实需要分布式事务。而且只有支持XA协议的资源才能参与分布式事务
Base理论

分布式事务常用的解决方案及优缺点_第5张图片

CAP定理

分布式事务常用的解决方案及优缺点_第6张图片
例如:zookeeper是cp(一致性和分区容错性),Eureka是ap(可用性和分区容错性)

柔性事务
  • 两阶段类型
  • 补偿性
  • 异步确保性
  • 最大努力通知性
柔性事务中的服务模式(接口)
  • 可查询操作
    分布式事务常用的解决方案及优缺点_第7张图片
  • 幂等操作
    分布式事务常用的解决方案及优缺点_第8张图片
  • TCC操作
    分布式事务常用的解决方案及优缺点_第9张图片
  • 可补偿操作
    分布式事务常用的解决方案及优缺点_第10张图片

服务模式是柔性事务流程中的特殊操作的实现(实现上对应业务服务要提供相应模式的功能接口),还不算是某一种柔性事务解决方案

几种常见的柔性事务解决方案
可靠消息最终一致性(异步确保型)

分布式事务常用的解决方案及优缺点_第11张图片

  • 实现

业务处理服务在业务事务提交之前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不真正发送。业务处理服务在业务事务处理后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才真正发送

  • 消息

业务处理服务在业务事务回滚后,向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或者回滚发送的消息,向业务处理服务询问消息状态,业务处理服务根据消息ID或者消息内容确定该消息是否有效

  • 约束

被动方的处理结果不影响主动方的处理结果,被动方的消息处理操作是幂等操作

  • 成本

可靠消息服务建设成本
一次消息发送需要两次确认,业务处理服务需要实现消息状态回查接口

  • 优点,适用范围

消息数据独立存储,独立伸缩,降低业务系统与消息系统间的耦合
对最终一致性时间敏感度较高,降低业务被动方实现成本

  • 用到的服务模式

可查询操作,幂等操作

  • 方案特点

兼容所有实现JMS标准中间件
确保业务数据可靠性前提下,实现业务数据的最终一致性(理想状态下基本是准实时一致的)

  • 行业应用

支付宝,ebay,去哪儿,携程。。。

TCC(两阶段,补偿性)

分布式事务常用的解决方案及优缺点_第12张图片

  • 实现

一个完成的业务活动由一个主业务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务提供TCC型业务操作
业务活动管理器控制业务活动的一致性,它等级业务活动中的操作,并在业务活动提交时确认所有的TCC型操作的confirm操作,在业务员活动取消时调用所有TCC型操作的cancel操作

  • 成本

实现TCC操作的成本
业务活动结束时confirm或cancel操作执行成本
业务活动的日志成本

  • 适用范围

强隔离性,严格一致性要求的业务活动
适用于执行时间较短的业务,(比如处理账户,收费等业务)

  • 用到的服务模式

TCC操作,幂等操作,可补偿操作,可查询操作

  • 方案特点

不与具体的服务框架耦合(在RPC架构中通用)
位于业务服务层,而非资源层
可以灵活选择业务资源的锁定粒度
TCC里对每个服务资源的操作都是本地事务,数据被lock的时间短,可扩展性好(可以说是为独立部署的SOA服务而设计的)

  • 行业应用

支付宝XTS(蚂蚁金融云的分布式事务服务DTS)

最大努力通知(定期校对)

分布式事务常用的解决方案及优缺点_第13张图片

  • 实现

业务活动的主动方,在完成业务处理之后,向业务活动的被动方发送消息,允许消息丢失业
务活动的被动方根据定时策略,向业务活动主动方查询,恢复丢失的业务消息

  • 约束

被动方的处理结果不影响主动方的处理结果

  • 成本

业务查询与校对系统的建设成本

  • 适用范围

对业务最终一致性的时间敏感度低
跨企业的业务活动

  • 用到的服务模式

可查询操作

  • 方案特点

业务活动的主动方在完成业务处理后,向业务活动被动范发送通知消息(允许消息丢失)
主动方可以设置时间阶梯型通知规则,在通知失败后按规则重复通知,直到通知N次后不再通知
主动方提供小队校对查询接口给被动方按需校对查询,用于恢复丢失的业务消息

  • 行业应用案例

银行通知 商户通知等(各大交易业务平台间的商户通知:多次通知,查询校对,对账文件等)

总结

常用的分布式事务解决方案

  • 刚性事务

全局事务(标准的分布式事务)

  • 柔性事务

可靠消息最终一致性(异步确保型)
TCC(两阶段,补偿性)
最大努力通知(定期校对)
纯补偿性

你可能感兴趣的:(技术框架)