详解分布式事务XA实现数据一致性的协议与原理--2PC与3PC
|
副标题[/!--empirenews.page--]
概述 大型业务系统有着用户多、并发高的特点，而在这方面，集中式数据库(单机数据库)的性能很难支持，因此主流的互联网公司往往采用分布式(架构)数据库，物理上利用更多的低端设备，逻辑上对大表水平拆分支撑业务的需要。
虽然分布式数据库能解决性能难题，但事务一致性(Consistency)的问题，却很难在分布式数据库上得到解决。 数据一致性? 一致性问题，“万恶之源”是数据冗余和分布并通过网络交互+网络异常是常态。 1、数据一致性的情形 主库、从库和缓存数据一致性，相同数据冗余，关系数据库，为保证关据库的高可用和高性能，一般会采用主从(备)架构并引入缓存。其中数据不一致性存在于数据冗余的时间窗口内。常用的解决方案见数据库之互联网常用架构方案。 多副本数据之间的数据一致性，相同数据副本，大数据领域，一份数据会有多个副本并存储到不同的节点上。客户端可以访问任何一个节点进行读写操作。常用的解决方案是基于Paxos、ZAB、Raft、Quorum、Gossip等的开源实现。 分布式服务之间的数据一致性，相关数据分布，分布式服务，不同的服务操作不同的库(表)，而且库(表)间要保持一致。常用的解决方案是分布式事务一致性解决方案。 2、数据一致性的概念 强一致性 弱一致性 最终一致性 3、数据一致性的原理 ACID CAP BASE 4、数据一致性的协议
分布式事务XA实现数据一致性 所谓分布式服务，就是把之前通过本地接口交互的模块，拆分成单独的应用独立部署，并通过RPC和MQ交互。拿物流中的订单和库存举例(新增一条订单记录，库存就要-1)，集中式架构中，要想保证订单表和库存表的一致性，只要一个本地事务(ACID)就能保证两者的强一致性;而分布式架构中，订单表由订单服务操作，库存表由库存服务操作。要想保证订单表和库存表的一致性，那么就必须保证订单服务对订单表的操作和库存服务对库存表的操作同时成功。之前的一个本地事务就变成了一个分布式事务。由于服务之间通过网络交互+网络异常是常态，就会产生服务间数据不一致的情况。这就涉及一个分布式事务一致性的问题。 如何来保证分布式事务的ACID，业界也有比较成熟的方案，一般是2段提交2PC协议或者改进版也就是3段提交3PC协议，下面来分别简单介绍下。 2PC协议也成为2段提交，1prepare阶段，2commit阶段。 所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段(执行阶段)。  准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。 可以进一步将准备阶段分为以下三个步骤： 1)协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。 2)参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。(注意：若成功这里其实每个参与者已经执行了事务操作) 3)各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息;如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。 提交阶段 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息;否则，发送提交(Commit)消息;参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源) 接下来分两种情况分别讨论提交阶段的过程。 当协调者节点从所有参与者节点获得的相应消息都为”同意”时:  1)协调者节点向所有参与者节点发出”正式提交(commit)”的请求。 2)参与者节点正式完成操作，并释放在整个事务期间内占用的资源。 3)参与者节点向协调者节点发送”完成”消息。 4)协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。 如果任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：  1)协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。 2)参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。 3)参与者节点向协调者节点发送”回滚完成”消息。 4)协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。 不管最后结果如何，第二阶段都会结束当前事务。 二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的： 1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。 2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。(如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题) （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
