分布式事务

分布式事务特性: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按异步的方式协调完成事物,性能较高 缺点: 这个方式基于关系型数据库本地事务来实现,会出现频繁读写数据库记录,浪费数据库资源,另外对于 高并发操作不是最佳方案

results matching ""

    No results matching ""