简介
分布式事务是企业集成中的一个难点,也是每个分布式架构都会涉及到的一个东西,特别是在微服务的架构中,几乎是无法避免的
数据库事务
数据库事务的几个特性: 原子性,一致性,隔离性和持久性
分布式的网络环境很复杂,容易出现问题:机器宕机,网络异常,消息丢失....
分布式系统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传播到服务端。
- 什么都好,就是收费
最佳实践
分布式事物产生的两个原因
- 微服务过多
- 资源阶段分散
其中有个原因是因为微服务太多。太多团队一个人维护几个微服务，过度设计，搞得所有人都很疲惫。
微服务多就会引出分布式事务，这个时候不会建议任何一种分布式事务解决方案，而是将这些服务聚合成一个单机服务，使用数据库的本地事务。因为无论什么方案都会增加系统的复杂度和不可靠性。
分布式事物应该是我们积极去避免的,而不是努力去拥抱的,一句话,能不用就不用
