应用大全网站,网站整站建设,wordpress 去掉顶部工具栏,海通建设集团有限公司网站摘要#xff1a; 近日#xff0c;Apache RocketMQ 社区正式发布4.3版本。此次发布不仅包括提升性能#xff0c;减少内存使用等原有特性增强#xff0c;还修复了部分社区提出的若干问题#xff0c;更重要的是该版本开源了社区最为关心的分布式事务消息#xff0c;而且实现…摘要 近日Apache RocketMQ 社区正式发布4.3版本。此次发布不仅包括提升性能减少内存使用等原有特性增强还修复了部分社区提出的若干问题更重要的是该版本开源了社区最为关心的分布式事务消息而且实现了对外部组件的零依赖。
近日Apache RocketMQ 社区正式发布4.3版本。此次发布不仅包括提升性能减少内存使用等原有特性增强还修复了部分社区提出的若干问题更重要的是该版本开源了社区最为关心的分布式事务消息而且实现了对外部组件的零依赖。接下来本文将详细探秘RocketMQ事务消息的设计原理以及实现机制。 一、需求缘起
在微服务架构中随着服务的逐步拆分数据库私有已经成为共识这也导致所面临的分布式事务问题成为微服务落地过程中一个非常难以逾越的障碍但是目前尚没有一个完整通用的解决方案。
其实不仅仅是在微服务架构中随着用户访问量的逐渐上涨数据库甚至是服务的分片、分区、水平拆分、垂直拆分已经逐渐成为较为常用的提升瓶颈的解决方案因此越来越多的原子操作变成了跨库甚至是跨服务的事务操作。最终结果是在对高性能、高扩展性高可用性的追求的道路上我们开始逐渐放松对一致性的追求但是在很多场景下尤其是账务电商等业务中不可避免的存在着一致性问题使得我们不得不去探寻一种机制用以在分布式环境中保证事务的一致性。
二、理论基石
微服务使得单体架构扩展为分布式架构在扩展的过程中逐渐丧失了单体架构中数据源单一可以直接依赖于数据库进行事务操作的能力而关系型数据库中提供了强大的事务处理能力可以满足ACIDAtomicityConsistencyIsolationDurability的特性这种特性保证了数据操作的强一致性这也是分布式环境中弱一致性以及最终一致性能够得以实现的基础。
数据一致性分为三个种类型强一致性弱一致性以及最终一致性正如上文所述数据库实现的就是强一致性能够保证在写入一份新的数据库立即使其可见。最终一致性是弱一致性的强化版系统保证在没有后续更新的前提下系统最终返回上一次更新操作的值。在没有故障发生的前提下不一致窗口的时间主要受通信延迟系统负载和复制副本的个数影响。
然而微服务作为分布式系统同样受CAP[1] 原理的制约在CAP理论中 CConsistency AAvailability PPartition tolerance 三者不可同时满足而服务化中更多的是提升A以及P在这个过程中不可避免的会降低对C的要求因此BASE理论随之而来。
BASE[2] 理论来源于ebay在2008年ACM中发表的论文BASE理论的基本原则有三个Basically AvailableSoft stateEventually consistent主要目的是为了提升分布式系统的可伸缩性论文同样阐述了如何对业务进行调整以及折中的手段BASE理论的提出为分布式事务的发展指出了一个方向。
在最终一致性的实现过程中最基本的操作就是保证事务参与者的幂等性所谓的幂等性就是业务方能够使用相关的手段保证单个事务多次提交依然能够保证达到同样的目的。
三、当前解决方案
1、2PC/3PC
谈到分布式事务首先要说的就是2PCtwo phase commit方案如下图所示[3]
2PC把事务的执行分为两个阶段第一个阶段即prepare阶段这个阶段实际上就是投票阶段协调者向参与者确认是否可以共同提交再得到全部参与者的所有回答后协调者向所有的参与者发布共同提交或者共同回滚的指令用以保证事务达到一致性。
但是分布式系统中的所有通信均存在着三种状态成功失败超时。其中超时状态的存在是我们在设计分布式系统时所面对的永远的痛2PC同样存在问题尤其是在发送完可以提交的指令后参与者在没有收到提交或者回滚的指令时面对已经上锁的资源面对已经写出去的undo或者redo日志参与者会一时陷入手足无措的状态为了解决这个问题3PC应运而生如下图所示[4] 3PC在commit之前增加了preCommit的过程使得在参与者在收不到确认时依然可以从容commit或者rollback避免资源锁定太久导致浪费。但是3PC同样存在着很多问题。实现起来非常复杂因为很难通过多次询问来解决系统间分歧问题尤其是存在超时状态互不信任的分布式网络中这也就是著名的拜占庭将军问题[5]。 总结一下2PC是几乎所有分布式事务算法的基础后续的分布式事务算法几乎都由此改进而来其优缺点非常明显 » 优点在于已经有较为成熟的实现方案比如XA。 » 缺点XA是一个阻塞协议。服务在投票后需要等待协调器的决定此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高 因此这种设计不能适应随着事务涉及的服务数量增加而扩展的需要很难用于并发较高以及子事务声明周期较长(long-running transactions)的分布式服务中。 2、SAGA
SAGA算法[6] 于1987年提出是一种异步的分布式事务解决方案其理论基础在于其假设所有事件按照顺序推进总能达到系统的最终一致性因此saga需要服务分别定义提交接口以及补偿接口当某个事务分支失败时调用其它的分支的补偿接口来进行回滚saga的具体实现分为两种Choreography以及Orchestration
1 Choreography如下图所示
这种模式下不存在协调器的概念每个节点均对自己的上下游负责在监听处理上游节点事件的同时对下游节点发布事件。
2Orchestration存在中心节点的模式如下图所示 该中心节点即协调器知道整个事务的分布状态相比于无中心节点方式该方式有着许多优点
能够避免事务之间的循环依赖关系参与者只需要执行命令/回复(其实回复消息也是一种事件消息)降低参与者的复杂性开发测试门槛低在添加新步骤时事务复杂性保持线性回滚更容易管理。因此大多数saga模型实现均采用了这种思路。总结一下SAGA模型的优点在于其降低了事务粒度使得事务扩展更加容易同时采用了异步化方式提升性能。但是其缺点在于很多时候很难定义补偿接口回滚代价高而且由于SAGA在执行过程中采用了先提交后补偿的思路进行操作所以单个子事务在并发提交时的隔离性很难保证。 3、TCC TCC(Try-Confirm-Concel)模型[7] 同样是一种补偿性事务主要分为Try检查、保留资源Confirm执行事务Concel释放资源三个阶段如下图所示
其中活动管理器记录了全局事务的推进状态以及各子事务的执行状态负责推进各个子事务共同进行提交或者回滚。同时负责在子事务处理超时后不停重试重试不成功后转手工处理用以保证事务的最终一致性。 总结一下相比于SAGA模型其优点在于尝试阶段仅仅只是对业务系统做检测并保留业务资源并没有真正提交所以后续SAGA需要针对提交的事务做补偿而TCC则仅仅需要释放保留资源降低了补偿成本并且由于在Try阶段对资源进行了保留锁定所以相比于SAGA模式TCC模式拥有更高的隔离性。 缺点相比于SAGA模式TCC模式多增加了一个状态导致在业务开发过程中复杂度上升而且协调器与子事务的通信过程增加状态轮转处理也更为复杂。 四、事物消息**
以购物场景为例张三购买物品账户扣款100元的同时需要保证在下游的会员服务中给该账户增加100积分。由于数据库私有所以导致在实际的操作过程中会出现很多问题比如先发送消息可能会因为扣款失败导致账户积分无故增加如果先执行扣款则有可能因服务宕机导致积分不能增加无论是先发消息还是先执行本地事务都有可能导致出现数据不一致的结果。
事务消息的本质就是为了解决此类问题解决本地事务执行与消息发送的原子性问题。目前事务消息在多种分布式消息中间件种均有实现但是其实现方式思路却各有不同。
1、传统事务消息实现
传统事务消息实现一种思路是依赖于AMQP协议用来确保消息发送成功AMQP模式下需要在发送在发送事务消息时进行两阶段提交首先进行tx_select开启事务然后再进行消息发送最后进行消息的commit或者是rollback。这个过程可以保证在消息发送成功的同时本地事务也一定成功执行但事务粒度不好控制而且会导致性能急剧下降同时依然无法解决本地事务执行与消息发送的原子性问题。
还有另外一种思路就是通过保证多条消息的同时可见性来保证事务一致性。但是此类消息事务实现机制更多的是用到consume-transform-produce场景中其本质还是用来保证消息自身事务并没有把外部事务包含进来。
2、RocketMQ事务消息
RocketMQ事务消息设计则主要是为了解决Producer端的消息发送与本地事务执行的原子性问题RocketMQ的设计中broker与producer端的双向通信能力使得broker天生可以作为一个事务协调者存在而RocketMQ本身提供的存储机制则为事务消息提供了持久化能力RocketMQ的高可用机制以及可靠消息设计则为事务消息在系统在发生异常时依然能够保证事务的最终一致性达成。
2.1 RocketMQ 事务消息设计
事务消息作为一种异步确保型事务 将两个事务分支通过MQ进行异步解耦RocketMQ事务消息的设计流程同样借鉴了两阶段提交理论整体交互流程如下图所示
事务发起方首先发送prepare消息到MQ。
在发送prepare消息成功后执行本地事务。
根据本地事务执行结果返回commit或者是rollback。
如果消息是rollbackMQ将删除该prepare消息不进行下发如果是commit消息MQ将会把这个消息发送给consumer端。
如果执行本地事务过程中执行端挂掉或者超时MQ将会不停的询问其同组的其它producer来获取状态。
Consumer端的消费成功机制有MQ保证。
2.2 RocketMQ事务消息实现
RocketMQ事务消息在实现上充分利用了RocketMQ本身机制在实现零依赖的基础上同样实现了高性能、可扩展、全异步等一系列特性。
在具体实现上RocketMQ通过使用Half Topic 以及Operation Topic 两个内部队列来存储事务消息推进状态如下图所示
其中Half Topic对应队列中存放着prepare消息Operation Topic对应的队列则存放了prepare message对应的commit/rollback消息消息体中则是prepare message对应的offset服务端通过比对两个队列的差值来找到尚未提交的超时事务进行回查。
在具体实现上事务消息作为普通消息的一个应用场景在实现过程中进行了分层抽象从而避免了对RocketMQ原有存储机制的修改如下图所示
从用户侧来说用户需要分别实现本地事务执行以及本地事务回查方法因此只需关注本地事务的执行状态即可而在service层则对事务消息的两阶段提交进行了抽象同时针对超时事务实现了回查逻辑通过不断扫描当前事务推进状态来不断反向请求Producer端获取超时事务的执行状态在避免事务挂起的同时也避免了Producer端的单点故障。而在存储层RocketMQ通过Bridge封装了与底层队列存储的相关操作用以操作两个对应的内部队列用户也可以依赖其它他存储介质实现自己的serviceRocketMQ会通过ServiceProvider加载进来。
从上述事务消息设计中可以看到RocketMQ事务消息较好的解决了事务的最终一致性问题事务发起方仅需要关注本地事务执行以及实现回查接口给出事务状态判定等实现而且在上游事务峰值高时可以通过消息队列避免对下游服务产生过大压力。
事务消息不仅适用于上游事务对下游事务无依赖的场景还可以与一些传统分布式事务架构相结合而MQ的服务端作为天生的具有高可用能力的协调者使得我们未来可以基于RocketMQ提供一站式轻量级分布式事务解决方案用以满足各种场景下的分布式事务需求。
作者介绍
冯嘉Apache RocketMQ联合创始人Linux OpenMessaging标准创始人。阿里巴巴高级技术专家带领团队、社区打造了中国分布式云计算领域第一个Apache顶级开源中间件项目创立分布式消息领域的国际标准OpenMessaging。
冯嘉作为阿里巴巴 RocketMQ技术负责人具有丰富的分布式软件架构、高并发网站设计、性能调优经验拥有国内外多项分布式、推荐领域的专利授权。目前专注于大规模分布式系统、分布式消息引擎、流计算领域关注 Hbase/Hadoop/Spark/Flink等大数据技术栈。
杜恒阿里巴巴技术专家Apache RocketMQ内核控拥有多年分布式系统研发经验对Microservice, MessagingStorage等领域有深刻理解拥有多年金融领域开发设计经验。目前专注RocketMQ内核优化以及Messaging生态建设。
原文链接
本文为云栖社区原创内容未经允许不得转载。
