分布式事务
分布式事务特性:CAP
一致性
强一致性?最终一致性?
分布式节点数据一致
可用性
一致性和可用性是矛盾的
服务整体可用?
(个人理解:拆分的越多,服务总体可用性越强)
分区容忍性(坚决要满足)
分区容忍性解决由于网络分区(各个系统通过网络协同工作),导致数据的不完整及无法访问等问题
CAP组合
1.CA: 放弃分区容忍性,加强一致性和可用性,关系型数据库符合CA设计 2.AP: 放弃一致性,加强可用性和分区容忍性,追求最终一致性,很多nosql按照AP设计 3.CP: 放弃可用性,加强一致性和分区容忍性,追求强一致的系统按照CP设计,比如跨行转账
分布式事务解决方案
2PC协议流程图
(1)阶段一:准备阶段(prepare) 协调者通知参与者准备提交订单,参与者开始投票 (2)阶段二:提交(commit)/回滚阶段(rollback) 协调者根据参与者的投票结果发起提交指令 如果有参与者没有准备好则发起回滚指令
优点: 实现强一致性,部分关系数据库支持(Oracle.mysql) 缺点: 整个事务的执行需要由协调者在多个节点去协调,增加了事务的时间,性能低下!
事务补偿TCC
(1)T:try 检查及预留业务资源,完成提交事务前的检查,并预留好资源 (2)C:confirm 确定执行业务操作,对try阶段预留的资源正式执行 (3)C:cancel 取消执行业务操作, 对try阶段预留的资源释放
优点: 最终保证数据的一致性,在业务层实现事业控制,灵活性好 缺点: 开发成本高,每个事物操作每个参与者都需要实现try/confirm/cancel接口(繁琐)
消息队列实现最终一致性
事物A执行事物并记录消息到本地(标记未回执) -> MQ -> 事物B执行操作,并回执给A
优点: 由MQ按异步的方式协调完成事物,性能较高 缺点: 这个方式基于关系型数据库本地事务来实现,会出现频繁读写数据库记录,浪费数据库资源,另外对于 高并发操作不是最佳方案