婴儿睡袋网站建设,wordpress 免密码,吉林中岩峰建设有限公司网站,比较好的网站建设品牌升级分布式事务讲解 - 2PC、3PC、TCC
前置知识
BASE理论#xff1a;
BASE是Basically Availbale(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)三个词语的缩写。BASE理论是对CAP理论中AP的一个扩展#xff0c;通过牺牲强一致性来获得可用性#xff0c;当…分布式事务讲解 - 2PC、3PC、TCC
前置知识
BASE理论
BASE是Basically Availbale(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)三个词语的缩写。BASE理论是对CAP理论中AP的一个扩展通过牺牲强一致性来获得可用性当系统出现故障时允许部分功能不可用但是要保证核心功能可用允许数据在一段时间内不一致但是数据最终要达到一致状态。\基本可用分布式系统再出现故障时允许损失部分功能的可用性保证核心功能必须可用。软状态由于不要求数据的强一致性所以BASE理论允许系统中出现中间状态(软状态)如“支付中”、“数据同步中”等状态待数据达到最终一致后状态修改为最终状态。最终一致性指经过一段时间后所有节点的数据将会达到一致状态即软状态都变成了最终状态但是这个需要一定时间的延迟和等待。
What什么是分布式事务
一个操作由多个不同服务器的子操作组成分布式事务就是要保证这些子操作要不全部执行成功要不全部执行失败。从本质上讲分布式事务就是为了保证不同数据库的数据一致性。
Why为什么使用分布式事务 使用分布式事务的原因总结起来就一个 一个逻辑对于不同数据库的操作会造成数据不一致的情况可能一个数据库数据修改成功但是另一个数据库修改失败但是这个又不能在本地事务进行处理为了解决这个问题分布式事务应运而生。 有人可能会问微服务情况下调用使用OpenFeign、RestTemplate等其他服务方法时如果一个本地事务执行失败就返回异常其他服务已执行的操作回滚不就可以了吗 如果按照从上往下顺序分别调用【订单服务】、【库存服务】、【积分服务】这三个服务都要操作数据库如果前两个服务操作成功但是调用第三个服务时操作失败那该怎么办前两个服务的操作能回滚吗不能除非你保存了前两个服务执行的更新sql的所有undo操作所以在这种情况下只能用分布式事务来解决这种数据不一致问题。
How怎么使用分布式事务
到现在分布式事务已经有很多的解决方案了有2PC、3PC、TCC这一篇博客我们先来分别讲讲最早的2PC、3PC这两种解决方案的模型及理论基础以后再丰富其他的分布式事务解决方案。
2PCTwo Phase Commit
工作流程
2PC工作流程分两个阶段。
第一阶段 第一阶段执行事务操作事务询问。 协调者节点向所有参与者节点询问是否可以执行提交操作并开始等待各参与者节点的响应。 执行事务。 参与者节点执行询问发起的所有事务操作并将Undo信息和Redo信息写入数据库日志。若操作成功这里其实每个参与者已经执行了事务操作 各参与者向协调者反馈事务询问的响应。 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功则反馈一个“同意”消息如果执行失败则反馈一个“中止”消息。 第二阶段 第二阶段执行事务提交当所有参与者节点在第一阶段向协调者节点反馈的消息全都是“同意”时 发送事务提交请求协调者节点向所有参与者节点发出“正式提交(commit)”请求。事务正式提交参与者节点正式完成提交操作并释放在整个事务期间占用的资源。反馈事务提交结果参与者节点向协调者节点发送“完成”消息。完成事务协调者节点收到所有参与者节点反馈的“完成”消息后完成分布式事务。 当任一参与者节点在第一阶段反馈的响应为“中止”或者协调者在第一阶段接收反馈信息超时 发送事务回滚请求协调者节点向所有参与者节点发出“回滚操作(rollback)”请求。事务回滚各参与者节点收到请求利用之前写入的Undo信息执行本地事务回滚操作并释放在整个事务期间占用的资源。反馈事务回滚结果参与者节点向协调者节点发送“回滚完成”消息。中断事务协调者节点收到所有参与者节点反馈的“回滚完成”消息后取消事务。 3PCThree Phase Commit
3PC没有解决2PC所有问题只是降低了灾难的发生概率。
TCCTry Commit Cancel
这个模型有两个个阶段但是与2PC的三个阶段又有所不同。
第一阶段 第一阶段执行Try操作 事务发起。协调者节点向所有参与者节点发起执行业务逻辑包含数据操作的命令并开始等待各参与者节点的响应。执行数据操作。直接对数据库的数据执行操作。各参与者向协调者反馈执行操作的响应。各参与者节点响应协调者节点发起的数据操作。如果参与者节点的数据操作实际执行成功则反馈一个“同意”消息如果有一个参与者执行失败则反馈一个“中止”消息。 第二阶段 第二阶段执行Confirm/Cancel操作根据阶段一各事务参与者的响应如果所有事务参与者在阶段一执行成功那就执行Confirm操作有一个事务参与者在阶段一执行失败就执行Cancel操作进行数据库数据恢复。 Confirm 操作用于执行数据操作成功之后的业务逻辑。Cancel 操作用于恢复阶段一对数据的操作。 网络语录解析
【Confirm操作使用预留的资源执行业务操作】 就是在数据更新完这件事的基础上进行后续逻辑的执行。 【Cancel操作取消执行业务操作释放预留的资源】 就是恢复数据可以看做是一个搂底的操作。
总结
2PC、3PC、TCC区别
在2PC的第一阶段基础之上3PC新加了一个准备阶段(上图所示)用于询问所有参与者节点是否已经准备好要进行分布式事务操作了这一阶段没有对资源的占用只是测试数据库是否能获取锁即可只是保证所有参与者都有能力参与事务如果有网络或者其他问题就不用进行第二、三阶段了。在3PC的所有阶段都为所有参与者节点和协调者节点添加了超时机制防止因某一节点宕机造成的资源无法释放问题。2PC中所有阶段只对协调者节点添加了超时机制。TCC模型主要是在应用层做的一个分布式事务2PC和3PC则是在数据库层做的分布式事务。TCC模型可以用于不支持事务的数据库但是2PC和3PC要求数据库必须支持事务。
2PC存在问题
2PC只对协调者节点添加了超时机制如果协调者这一重要角色宕机所有参与者的资源就会一直得不到释放降低系统的可用性。2PC中当其中任一节点宕机情况出现时不能保证数据的最终一致性。
TCC存在问题
代码编写难度高 每个参与者的业务都要写try、confirm、cancel三个操作并且各个操作的业务都有所不同为满足一致性要满足try、canfirm、cancel三个操作的幂等。
TCC的优点
TCC的优点全是因为实现了应用层的分布式事务优点如下 可以降低数据库锁冲突提高吞吐量。可以通过应用控制数据库锁的粒度而不用像2PC和3PC使数据库阻塞等待。可以通过部署集群解决单点故障。
对比2PC3PC有什么优点
为所有参与者节点和协调者节点添加了超时机制 1如果协调者等待参与者反馈信息超时直接给所有参与者发送中断分布式事务请求。2如果在第三阶段任一参与者等待协调者提交事务信息超时那就默认提交事务 添加超时机制可以防止因某一节点宕机造成的资源无法释放问题以及资源占用时间过长问题。 在第一阶段不锁定资源就好像在Synchronized外面加了个if条件能降低分布式事务执行失败率。
