分布式事务

简介

分布式事务是企业集成中的一个难点,也是每个分布式架构都会涉及到的一个东西,特别是在微服务的架构中,几乎是无法避免的

数据库事务

数据库事务的几个特性: 原子性,一致性,隔离性和持久性

分布式的网络环境很复杂,容易出现问题:机器宕机,网络异常,消息丢失....

分布式系统CAP与BASE

CAP定理

CAP定理是由加州大学伯克利分校Eric
Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

• 一致性 :客户端的一系列操作都会同时发生
• 可用性: 每个操作都必须以可预期的响应结束
• 分区容错性:即使出现单个组件不能用了,操作依然可以完成

BASE理论

在分布式系统中,我们往往追求的可用性,他的重要程度比一致性要高,那么如何实现高可用呢?就是base理论,它是对cap理论的进一步的扩充

• Basically Available 基本可用
• Soft state 软状态
• Eventually consistent 最终一致性

BASE理论是对cap理论中一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但是每个应用可以根据自身的业务特点,采用适当的方式来是系统达到最终的一致性

---

分布式事务的解决方案

基于XA协议的两阶段提交方案

交易中间键与数据库通过XA接口规范,使用两阶段提交来完成一个全局事务,XA规范的基础是两阶段提交协议

XA方案

1.第一阶段是表决阶段,所有的参数者都将本事务能够成功的信息反馈发给协调者;

2.第二阶段是执行阶段,协调者根据所有参与者的反馈,通知所有的参与者,步调一致的在所有的分支上提交或者回滚;

---

TCC方案

TCC方案在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try 、Confirm 、Cancel三个操作.try完成业务的准备工作,confirm完成业务的提交,cancel完成事务的回滚

TCC方案

基于消息的最终一致性解决方案

---

阿里的GTS

记录数据库的变化,回改数据库

• 在业务函数外围使用@TxcTransaction注解即可开启分布式事务。Dubbo应用通过隐藏参数将GTS的事务xid传播到服务端。
• 什么都好,就是收费

---

最佳实践

分布式事物产生的两个原因

• 微服务过多
• 资源阶段分散

其中有个原因是因为微服务太多。太多团队一个人维护几个微服务，过度设计，搞得所有人都很疲惫。

微服务多就会引出分布式事务，这个时候不会建议任何一种分布式事务解决方案，而是将这些服务聚合成一个单机服务，使用数据库的本地事务。因为无论什么方案都会增加系统的复杂度和不可靠性。

分布式事物应该是我们积极去避免的,而不是努力去拥抱的,一句话,能不用就不用