1.主流解决分布式事务框架
1)单项目多数据源,jta+Atomikos
2)基于rabbitmq
3)基于rocketmq
4)LCN采用lcn模式(目前已经淘汰)tcc/txc/lcn 3种模式
5)基于seata
2.分布式事务产生背景
项目 |
数据源 |
事务管理器 |
是否产生分布式事务问题 |
备注 |
单项目 |
一个数据源 |
相同 |
否 |
因为有事务的传播行为 |
单项目 |
多个数据源 |
不相同 |
是 |
jta+Atomikos |
多项目 |
多个数据源 |
不相同 |
是 |
seata/lcn |
注意:不同的数据源(不同的事务管理器)或者不同的项目(不同的JVM)会产生分布式事务的问题 |
如:订单系统下单和派单,在分布式项目的情况下,调用下单服务成功,调用派单失败,在没有分布式事务的情况下会产生脏数据
3.ACID理论、BASE理论、CAP理论
ACID理论 | |
原子性 |
一个事务中的所有操作,要么全部成功、要么全部失败 |
一致性 |
事务前后数据的完整性必须保持一致 |
隔离性 |
多个事务之间互不影响 |
持久性 |
事务结束后,对数据的修改是永久的 |
CAP理论 | |
一致性 |
故障后保证各地方备份数据保证一致 |
可用性 |
故障后保证可用性 |
分区容错性 |
分区后产生的网络通讯故障 |
总结: CAP无法三者兼顾、要么cp要么ap CP:网络通讯故障后保证数据一致性、不保证可用性。如zk AP:网络通讯故障后保证可用性、不保证数据一致性。如eureka |
BASE理论 | |
基本可用 |
分布式系统出现故障后,允许损失部分可用性,但要保证核心可用 |
软状态 |
允许系统存在中间状态,但是中间状态不会影响系统整体可用性 |
最终一致性 |
允许短暂延迟、但是最终结果必须一致 |
4.强一致性和弱一致性
强一致性 |
弱一致性 |
不会出现脏读 |
可能会出现脏读 |
注意:分布式系统无法保证强一致性,允许短暂延迟、但是最终结果必须一致 | |
脏读:一个现在正在修改、一个线程正在读取。修改线程还没提交事务的情况下可能会存在脏读 |
5.二阶段提交协议和三阶段提交协议
二阶段提交协议 |
第一阶段:预备阶段 第二阶段:同步阶段 |
三阶段提交协议 |
第一阶段:预备阶段 第二阶段:询问阶段 第三阶段:同步阶段 |