事务的acid属性是指_观点丨??基于异步通信的微服务分布式事务管理机制研究分析...

欢迎金融科技工作者积极投稿！各抒己见！投稿邮箱： newmedia@fcmag.com.cn ——金融电子化

文 / 中国人民银行清算总中心 葛洪慧

分布式系统

在计算机科学理论中CAP定理指出，分布式系统的一致性、可用性和分区容错性只能满足三项中的两项。架构师在分布式系统的应用设计中，面临一致性和可用性问题时，往往会选择可用性，因为它直接影响到用户体验和客户流失。因而分布式系统的一致性问题成为分布式系统领域探索的热门问题。
提到分布式系统的一致性问题，就会涉及事务。事务（Rransaction）是具有原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）等属性特征（ACID）的一组相关操作。
事务的ACID属性中的一致性和CAP定理的一致性是有区别的。事务的一致性是指事务不能破坏数据库的规则，比如数据库键值唯一。大量事务并发操作时，就像按某个顺序执行的结果一样，数据库的键值唯一性不被破坏。CAP定理的一致性，指分布式环境下所有节点得到的最新的数据副本是一样的。在分布式环境下各节点的事务并发操作时，就像按某个顺序执行的结果一样，任何节点得到的数据副本是一样的。所以事务的ACID属性里的一致性，在分布式环境下的事务有可能不一致，CAP 定理里面提到的一致性是在分布式下环境下的一致性，是ACID一致性的更严格的子集。
跨多个开放系统执行的事务称为分布式事务。X/Open分布式事务处理模型（X/Open XA）是分布式事务管理的事实标准，XA使用两阶段提交来确保事务中的所有参与者都提交或回滚，能够保证分布式事务的ACID属性。实现了CAP定理提到的一致性问题。
那么XA协议是否适合微服务技术架构呢？我们来看微服务架构的特征。

微服务架构

著名架构师Adrian Cockcroft把微服务架构定义为面向服务的架构，它们由松耦合和具有边界上下文的元素组成。这里的边界上下文可理解为可以用通用IDL（Interface Definition Language）定义的服务接口，服务、服务接口以及接口间通信构成微服务的体系架构。微服务架构以服务间松耦合、独立部署、技术独立演进、快速和可持续交付、良好的容错性和可重用性等等，近年来在分布式系统的应用技术架构选择中得到更多的关注。
由于微服务架构以服务间松耦合为显著特征，而两阶段提交的每次操作均需服务同时在线协商，服务间耦合性较大。因此，基于两阶段提交的XA协议的分布式事务管理机制并不适合微服务架构的事务管理。同时，由于XA协议的同步协商特征，使得系统整体可用性和系统性能降低。

实现原理

目前，Sagas是微服务体系架构中，管理多个服务数据操作，保持数据一致性，符合微服务架构特征的分布式事务管理的解决方案。它实际上是使用补偿性事务作为处理长交易的一种方法。把一个长交易分成多个子事务，每个事务Ti对应补偿事务 Ci。如果事务Tn+1失败，长交易的执行顺序为T1…Tn，Cn…C1，通过执行补偿事务来撤销每个已提交的子事务，从而中止长交易。当然，对数据库的读操作是不需要补偿事务的。
Sagas的每个子事务Ti是本地事务，具有ACID属性。由于Sagas可能会看到其他 Sagas的部分执行结果，因此Sagas缺少隔离性。Sagas作为一个长交易序列，整体是具有ACD属性的。
事务的隔离性分为不同级别，包括未提交读、提交读、可重复读和串行化。缺少隔离性会造成脏读等。由于Sagas缺少隔离性，那么需要通过增加相应的策略，比如可通过增加语义锁等对策，来保证缺少隔离性带来的一致性问题。
下面以一种简化的转账业务，对基于异步通信方式的Eventuate™ Sagas的开源架构分布式事务管理的实现方式和数据一致性保障机制进行分析。

分布式事务管理机制分析

简化的转账业务，服务A(TransReqService)为转账请求管理服务，服务B(TransDealService)为转账处理服务，两个微服务运行在不同的网络节点上，各自维护同一个数据库中不同的表（或本地数据库）。服务A接收到客户转账请求后，数据库中记录转账请求并通知服务B进行转账处理，根据收到的返回结果更新本地转账状态。服务B收到调用申请，完成转账业务处理，更新数据库账户信息，将处理结果返回服务A。
Eventuate™ Tram框架是通过Sagas方式解决微服务分布式系统的数据一致性管理问题的平台。提供了两种模式，一种是基于事件消息的事件编排模式，一种是基于命令消息，有核心协调器的命令协调模式。两种模式均支持基于异步消息的通信方式，可以采用消息代理，也可以不用。这里以消息代理方式分析。1.事件编排模式。事件编排，顾名思义把分布式事务通过编排好的Sagas序列进行管理。事件编排模式支持事件消息。以简化的转账业务为例，事件编排实现过程如下。
（1）服务A接收转账请求，记录数据库表，并将其设置为pengding状态或加语义锁，同时发布事件记录插入消息表。
（2）数据库日志记录了插入消息表的相应操作，CDC服务读取和消息插入记录有关的数据库日志，并将事件消息记录发送给消息代理。
（3）服务B获取消息，进行资金结算并发布成功或失败的事件消息记录插入消息表。
（4）CDC服务读取和插入事件消息记录有关的数据库日志，并将消息记录发送给消息代理。
（5）服务A读取事件消息并更新转账pending状态为成功 / 失败。从而保证了数据的一致性。
这里数据库更新操作和事件发布作为一个事务，具有ACID事务属性，这由Eventuate Tram框架保证。这个过程是一个利用Sagas补偿事务来进行数据一致性管理的过程，第（5）步是对第（1）步转账请求的补偿。可以看出，Saga的补偿交易不像数据库回滚交易那样，好像什么都没发生，补偿交易是对之前的操作做了一次类似冲正的处理。由于Sagas缺乏隔离性，通过设置pengding状态，当有其他Sagas需要读取转账请求数据时，知道它处于一个中间状态。2.命令协调器模式。命令协调器模式支持命令消息，有一个核心协调器进行分布式事务的集中管理。
下面介绍Eventuate Tram Sagas协调器的工作原理。微服务定义Saga序列，通过调用SagaManager的接口SimpleSaga创建Saga定义，即 Sagadefinition，实际上相当于实例化了一个Saga协调器。实例化内容包括设置交易Pengding状态、唤醒服务B、发布命令、读取回执并根据回执设置交易结果等保障服务有效的逻辑内容。这里的Eventuate Tram框架是保障对于数据库操作处理和命令消息发布处理作为一个事务处理机制。
以简化的转账业务为例，命令协调器的实现过程如下。
（1）服务A接受转账请求，记录转账请求并设置为pending状态。
（2）服务A实例化Saga来协调转账。
（3）Saga协调器发送转账命令给服务B。
（4）服务B接收到命令进行转账操作，并将转账结果以命令回复。
（5）Saga协调器接收到回复命令，并发送处理成功或失败命令给服务A。
（6）服务A接收命令进行更新转账状态。
上述实现步骤中，服务A实例化Saga协调器、设置转账状态，以及服务A和服务B发送和接收转账命令均是通过Eventuate Tram Sagas完 成。利用Eventuate Tram框架，CDC服务读取和消息插入记录有关的数据库日志，并将命令消息记录发送给消息代理，保证数据库操作和命令消息在一个本地事务中处理。
通过上述两种实现方式看，基于Sagas的分布式事务管理机制的正确性不取决于是否预先序列化或补偿事务处理，而是取决于事务序列化和补偿之后，对数据库状态的最终影响是否等效。经过补偿后，数据库最终是否会在与子事务从未执行过的相同的地方有相同的结果，最终影响主要是指系统整体外部效果。这里注意区分 Eventuate Tram Sagas和Eventuate Tram框架。事件编排模式利用了消息代理和 Eventuate Tram 框架。命令协调模式利用了消息代理、Eventuate Tram框架和 Eventuate Tram Sagas框架。

总 结

由于微服务架构间服务松耦合的特征，XA协议并不适合微服务架构，基于异步方式的Sagas架构更贴合微服务技术架构发展方向。架构师可根据自身技术储备选择基于同步的实现方式还是异步的实现方式。同步调用简单但会降低系统整体可用性，异步方式需要一些消息或消息代理知识，但系统整体可用性高。同时，建议正确对待单体架构和微服务架构。软件工程从来就没有银弹，架构总是在特定需求和组织框架下取舍。如果利用微服务架构的技术，采用单体架构的设计思想失去了微服务架构的技术意义，不仅增加了系统的架构复杂度，又没有享用到微服务架构带来的便利。关于仿冒我刊收费的声明
我刊自创刊以来，从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为，均属于对投稿人的欺诈行为。
我刊官网地址为 http://www.fcmag.com.cn。
我刊投稿邮箱为 fcmag@fcmag.com.cn。
对于仿冒我刊网站、网页的违法行为，我社将追究其侵权责任，以维护我社和投稿人的合法权益。仿冒网站、网页举报电话：010-88232443
《金融电子化》新媒体部：主任 / 邝源 编辑 / 潘婧 傅甜甜