某企业网站建设论文,网站的内容与功能设计,西安网站建设报价方案,家装公司加盟这一篇主要介绍分布式事务的基础知识#xff0c;一些基础的算法、定理、简单应用等。下篇文章介绍互联网业界的具体实践方案。
1、CAP定理
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的#xff0c;其核心思想是任何基于网络的数据共享#xff0c;系统最多只能满…这一篇主要介绍分布式事务的基础知识一些基础的算法、定理、简单应用等。下篇文章介绍互联网业界的具体实践方案。
1、CAP定理
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的其核心思想是任何基于网络的数据共享系统最多只能满足数据一致性(Consistency)、可用性(Availability)和网络分区容忍(Partition Tolerance)三个特性中的两个三个特性的定义如下
一致性(Consistency) 等同于所有节点拥有数据的最新版本对于关系型数据库要求更新过的数据能被后续的访问都能看到可用性(Availability) 数据具备高可用性分区容错性(Partition tolerance) 容忍网络出现分区分区之间网络不可达
具体地讲在分布式系统中在任何数据库设计中一个Web应用至多只能同时支持上面的两个属性。显然任何横向扩展策略都要依赖于数据分区。因此设计人员必须在一致性与可用性之间做出选择。
1.1 CAP的应用实例 CA(一致性可用性without P容错性 单机的Mysql和Oracle 分布式集群中不存在这种情况因为多个节点必定考虑主备同步也就是网络。 CP(一致性容错性without A可用性 分布式的数据库如RedisHBaseZookeeper 任何时刻对ZooKeeper请求能得到一致的数据结果:当master节点网络故障会进行选举机制选举时集群不可用。但是它不能保证每次服务请求的可用性ZooKeeper可能会丢弃一些请求消费者程序需要重新请求才能获得结果。 AP(可用性容错性without C一致性 12306买票 购买的时候提示你是有票的但是可能实际已经没票了但是过了一会系统提示你下单失败余票不足。其实舍弃的只是强一致性。退而求其次保证了最终一致性。 Eureka 各个节点平等有节点挂掉会立刻换至其他节点保证服务可用只不过查到的信息可能不是最新的。在网络稳定后当前实例新的注册信息会被同步到其他节点中。 一旦网络问题发生节点之间可能会失去联系。为了保证高可用需要在用户访问时可以马上得到返回导致全局数据的不一致性。
2、 BASE理论
在分布式系统中我们往往追求的是可用性它的重要程序比一致性要高那么如何实现高可用性呢 前人已经给我们提出来了另外一个理论就是BASE理论它是用来对CAP定理进行进一步扩充的。BASE理论指的是
Basically Available基本可用Soft state软状态Eventually consistent最终一致性
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果理论的核心思想就是我们无法做到强一致但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性Eventual consistency。
3、 Paxos协议
Paxos协议由Leslie Lamport最早在1990年提出由于Paxos在云计算领域的广泛应用Leslie Lamport因此获得了2013年度图灵奖。
Paxos协议提出只要系统中2f1个节点中的f1个节点可用那么系统整体就可用并且能保证数据的强一致性它对于可用性的提升是极大的仍然假设单节点的可用性是P那么2f1个节点中任意组合的f1以上个节点正常的可用性P(total),又假设P0.99f2P(total)0.9999901494可用性将从单节点的2个9提升到了5个9这意味着系统每年的宕机时间从87.6小时降到0.086小时这已经可以满足地球上99.99999999%的应用需求。
Leslie写的两篇论文《The Part-Time Parliament》和《Paxos Made Simple》比较完整的阐述了Paxos的工作流程和证明过程Paxos协议把每个数据写请求比喻成一次提案proposal每个提案都有一个独立的编号提案会转发到提交者Proposer来提交提案必须经过2f1个节点中的f1个节点接受才会生效2f1个节点叫做这次提案的投票委员会(Quorum)投票委员会中的节点叫做AcceptorPaxos协议流程还需要满足两个约束条件 aAcceptor必须接受它收到的第一个提案b如果一个提案的v值被大多数Acceptor接受过那后续的所有被接受的提案中也必须包含v值v值可以理解为提案的内容提案由一个或多个v和提案编号组成。
Paxos协议流程划分为两个阶段第一阶段是Proposer学习提案最新状态的准备阶段第二阶段是根据学习到的状态组成正确提案提交的阶段完整的协议过程如下
阶段 1 Proposer选择一个提案编号n 然后向半数以上的Acceptors发送编号为 n 的prepare请求。 如果一个Acceptor收到一个编号为n 的prepare请求且 n 大于它已经响应的所有prepare请求的编号那么它就会保证不会再通过(accept)任何编号小于 n 的提案同时将它已经通过的最大编号的提案(如果存在的话)作为响应。
阶段 2 如果Proposer收到来自半数以上的Acceptor对于它的prepare请求(编号为n )的响应那么它就会发送一个针对编号为 n value值为 v 的提案的accept请求给Acceptors在这里 v 是收到的响应中编号最大的提案的值如果响应中不包含提案那么它就是任意值。 如果Acceptor收到一个针对编号n 的提案的accept请求只要它还未对编号大于 n 的prepare请求作出响应它就可以通过这个提案。
用时序图来描述Paxos协议如图3所示 上述Paxos协议流程看起来比较复杂是因为要保证很多边界条件下的协议完备性譬如初试值为空、两个Proposer同时提交提案等情况但Paxos协议的核心可以简单描述为Proposer先从大多数Acceptor那里学习提案的最新内容然后根据学习到的编号最大的提案内容组成新的提案提交如果提案获得大多数Acceptor的投票通过就意味着提案被通过。由于学习提案和通过提案的Acceptor集合都超过了半数所以一定能学到最新通过的提案值两次提案通过的Acceptor集合中也一定存在一个公共的Acceptor在满足约束条件b时这个公共的Acceptor时保证了数据的一致性于是Paxos协议又被称为多数派协议。
Paxos协议的真正伟大之处在于它的简洁性Paxos协议流程中任何消息都是可以丢失的一致性保证并不依赖某个特殊消息传递的成功这极大的简化了分布式系统的设计极其匹配分布式环境下网络可能分区的特点相比较在Paxos协议之前的“两阶段提交2PC”也能保证数据强一致性但复杂度相当高且依赖单个协调者的可用性。
那既然Paxos如此强大那为什么还会出现ZAB协议
4、 ZAB 协议
Paxos协议虽然是完备的但要把它应用到实际的分布式系统中还有些问题要解决 在多个Proposer的场景下Paxos不保证先提交的提案先被接受实际应用中要保证多提案被接受的先后顺序怎么办 Paxos允许多个Proposer提交提案那有可能出现活锁问题出现场景是这样的提案n在第二阶段还没有完成时新的提案n1的第一阶段prepare请求到达Acceptor按协议规定Acceptor将响应新提案的prepare请求并保证不会接受小于n1的任何请求这可能导致提案n将不会被通过同样在n1提案未完成第二阶段时假如提案n的提交者又提交了n2提案这可能导致n1提案也无法通过。 Paxos协议规定提案的值v只要被大多数Acceptor接受过后续的所有提案不能修改值v那现实情况下我还要修改v值怎么办
ZooKeeper的核心算法ZAB通过一个简单的约束解决了前2个问题所有提案都转发到唯一的Leader通过Leader选举算法从Acceptor中选出来的来提交由Leader来保证多个提案之间的先后顺序同时也避免了多Proposer引发的活锁问题。
ZAB协议的过程用时序图描述如图4所示相比Paxos协议省略了Prepare阶段因为Leader本身就有提案的最新状态不需要有提案内容学习的过程,图中的Follower对应Paxos协议中的AcceptorObserver对应Paxos中的Learner。 ZAB引入Leader后也会带来一个新问题 Leader宕机了怎么办其解决方案是选举出一个新的Leader选举Leader的过程也是一个Paxos提案决议过程这里不展开讨论。
那如何做到提案的值v可以修改呢这不是ZAB协议的范畴研究ZooKeeper源码后发现它是这么做的ZooKeeper提供了一个znode的概念znode可以被修改ZooKeeper对每个znode都记录了一个自增且连续的版本号对znode的任何修改操作create/set/setAcl都会促发一次Paxos多数派投票过程投票通过后znode版本号加1这相当于用znode不同版本的多次Paxos协议来破除单次Paxos协议无法修改提案值的限制。
从保证一致性的算法核心角度看ZAB确实是借鉴了Paxos的多数派思想但它提供的全局时序保证以及ZooKeeper提供给用户可修改的znode才让Paxos在开源界大放异彩所以ZAB的价值不仅仅是提供了Paxos算法的优化实现也难怪ZAB的作者一直强调ZAB和Paxos是不一样的算法。
CAP理论告诉我们在分布式环境下网络分区无法避免需要去权衡选择数据的一致性和可用性Paxos协议提出了一种极其简单的算法在保障数据一致性时最大限度的优化了可用性ZooKeeper的ZAB协议把Paxos更加简化并提供全局时序保证使得Paxos能够广泛应用到工业场景。
5、两阶段提交协议2PC
两阶段提交协议Two-phase Commit Protocol简称 2PC是分布式事务的核心协议。在此协议中一个事务管理器Transaction Manager简称 TM协调 1 个或多个资源管理器Resource Manager简称 RM的活动所有资源管理器向事务管理器汇报自身活动状态由事务管理器根据各资源管理器汇报的状态完成准备或准备失败来决定各资源管理器是“提交”事务还是进行“回滚”操作。
二阶段提交的具体流程如下
应用程序向事务管理器提交请求发起分布式事务在第一阶段事务管理器联络所有资源管理器通知它们准备提交事务各资源管理器返回完成准备或准备失败的消息给事务管理器响应超时算作失败在第二阶段 1. 如果所有资源管理器均完成准备如图 1则事务管理器会通知所有资源管理器执行事务提交 2. 如果任一资源管理器准备失败如图 2 中的资源管理器 B则事务管理器会通知所有资源管理器进行事务回滚。 6、TCC模型
Try-Confirm-CancelTCC是初步操作Try、确认操作Confirm和取消操作Cancel三种操作的缩写这三种操作的业务含义如下
Try 阶段对业务系统做检测及资源预留Confirm 阶段对业务系统做确认提交。默认 Confirm 阶段是不会出错的只要 Try 成功Confirm 一定成功Cancel 阶段当业务执行出现错误需要回滚的状态下执行业务取消释放预留资源。
TCC 是二阶段提交协议Two-phase Commit Protocol简称 2PC的扩展Try 操作对应 2PC 中一阶段的准备提交事务PrepareConfirm 对应 2PC 中二阶段事务提交CommitCancel 对应 2PC 中二阶段事务回滚Rollback。
与 2PC 不同的是TCC 是一种编程模型是应用层的 2PCTCC 的 3 个操作均由编码实现通过编码实现了 2PC 资源管理器的功能。
TCC 自编码的特性决定 TCC 资源管理器可以跨数据库、跨应用实现资源管理将对不同的数据库访问、不同的业务操作通过编码方式转换一个原子操作解决了复杂业务场景下的事务问题。同时 TCC 的每一个操作对于数据库来讲都是一个本地数据库事务操作结束则本地数据库事务结束数据库的资源也就被释放这就规避了数据库层面的 2PC 对资源占用导致的性能低下问题。
7、柔性事务
7.1 柔性事务的定义
刚性事务如单数据库完全遵循 ACID 规范即数据库事务正确执行的四个基本要素
原子性Atomicity一致性Consistency隔离性Isolation持久性Durability
柔性事务如分布式事务为了满足可用性、性能与降级服务的需要降低一致性Consistency与隔离性Isolation的要求遵循 BASE 理论
基本业务可用性Basic Availability柔性状态Soft state最终一致性Eventual consistency
同样的柔性事务也部分遵循 ACID 规范
原子性严格遵循一致性事务完成后的一致性严格遵循事务中的一致性可适当放宽隔离性并行事务间不可影响事务中间结果可见性允许安全放宽持久性严格遵循
7.2 柔性事务的分类
柔性事务分为两阶段型、补偿型、异步确保型、最大努力通知型。 两阶段型 分布式事务二阶段提交对应技术上的 XA、JTA/JTS这是分布式环境下事务处理的典型模式。 补偿型 TCC 型事务Try-Confirm-Cancel可以归为补偿型。在 Try 成功的情况下如果事务要回滚Cancel 将作为一个补偿机制回滚 Try 操作TCC 各操作事务本地化且尽早提交没有两阶段约束当全局事务要求回滚时通过另一个本地事务实现“补偿”行为。 TCC 是将资源层的二阶段提交协议转换到业务层成为业务模型中的一部分。 异步确保型 将一些有同步冲突的事务操作变为异步操作避免对数据库事务的争用如消息事务机制。 最大努力通知型 通过通知服务器消息通知进行允许失败有补充机制。
