架构解密从漫衍式到微服务：带大家重新认识漫衍式事务

重新认识漫衍式事务要明白漫衍式事务，就需要先明确什么是事务（Transaction)，在大多数情况下，我们所说的事务都指数据库事务（Database Transaction)，厥后的种种非数据库的事务也都借鉴和参考了对数据库事务的界说:事务是数据库运行中的一个逻辑事情单元，事情单元中的一系列SQL下令都具有原子性操作的特点，这些下令要么完全乐成执行，要么完全打消或不执行，如果是后者，则体现为数据库内的最终数据没有发生任何改变。事务通常由数据库中的事务治理子系统卖力处置惩罚。

数据库单机事务的实现原理数据库事务要满足如下四个要求。原子性(Atomic):事务必须是原子事情单元，对其举行数据修改，要么全都执行，要么全都不执行。一致性(Consistent):事务在完成时，必须使所有的数据都保持一致状态，在事务竣事时，所有的内部数据结构（如B树索引或双向链表）都必须是正确的。隔离性(Isolation):由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。

持久性(Duration):在事务完成之后，对系统的影响是永久性的。其中原子性(需要记载操作历程和对应的效果，以便回退)、隔离性(发生锁)这两个要求，导致数据库事务的执行价格要远高于非事务性的操作。一般而言，隔离性是通过锁机制来实现的，而原子性、一致性和持久性等三个特性是通过数据库里的相关事务日志文件来实现的，在这个历程中涉及大量的IO操作。

在 MySQL里，事务相关的日志文件为redo和 undo文件，简朴来说，redo log记载事务修改后的数据，undo log记载事务修改前的原始数据。由于事务随时可能需要回滚,所以在 MySQL执行事务的历程中,这两个文件都市被写入数据。下面是 MySQL里一个事务执行时的简化流程。

(1）先记载undo/redo log，确保日志被刷到磁盘上持久存储。(2）更新数据记载，缓存操作并异步写入磁盘。

(3）提交事务，在redo log中写入commit记载。其中第3步为commit事务的操作，在这个历程中主要做以下事情。

(1）清理undo 段信息。(2）释放锁资源。

(3）刷新redo日志，确保将redo日志写入磁盘，纵然修改的数据页没有更新到磁盘，只要日志完成了，就能保证数据库的完整性和一致性。(4)清理savepoint列表。

我们看到，在事务执行的历程中，大量的费时操作都是在commit 指令之前完成的，包罗写相关的事务日志，以备回滚事务或者提交，而commit 指令所做的事情基本上是可以“瞬间”完成的,在整个事务处置惩罚的历程中所占的时间比例都很是少,这是事务处置惩罚的一个很重要的特点，后面要提到的XA二阶段事务模型也是基于这个特点而设计的。此外，如果在 MySQL执行事务的历程中因故障中断（好比意外断电）导致数据没有实时持久化到磁盘中，则可以在后面通过redo log重做事务或通过undo log回滚，确保数据的一致性。经典的X/OpenDTP事务模型如果一个事务内的SQL要划分操作几个独立的数据库服务器上的数据，那么这种事务就酿成漫衍式事务了。

由于漫衍式系统的编程难度大，而事务又是一个很是重要的功效，所以在编程方面不能有半点偏差，否则可能导致灾难性的结果，于是就有一些技术达人来研究并制定了业界首个漫衍式事务尺度规范——X/OpenDTP，此规范提出的二阶段提交模型（2PC)与TCP三次握手一样，成为经典。今后J2EE也遵循X/OpenDTP规范，设计、实现了Java里的漫衍式事务编程接口规范——JTA。

X/OpenDTP已经存在10年多了(于1994年公布)，最早是由银行业很有名的Tuxedo中间件实现的一个内部尺度，厥后交给X/Open组织举行尺度化。X/OpenDTP设计了一个模型来形貌到场漫衍式事务的各个角色及交互规范，如下图所示。

在X/OpenDTP模型中，到场事务的角色分为以下三种。(1)AP:用户法式，大部门是CRUD代码的这种应用（我们特别擅长)。(2）RM:数据库或者很少被使用的消息中间件等。

(3)）TM:事务治理器、事务协调者，卖力吸收用户法式（AP）提倡的XA事务指令，而且调理和协调到场事务的所有RM（数据库)，确保事务正确完成(或者回滚)。对这个模型中的几个关键点说明如下。AP卖力触发漫衍式事务，在这个历程中接纳了特殊的事务指令(XA指令)，而非普通的事务指令，这些执行由TM接受并发给所有相关的RM去执行。

RM卖力执行XA指令，每个RM只卖力执行自己的指令。TM卖力整个事务历程中的协调事情，检查和验证每个RM的事务执行情况。下面说说X/OpenDTP模型中知名的二阶段提交协议。在X/OpenDTP模型中，当一个漫衍式事务所涉及的SQL逻辑都执行完成，并到了最后提交事务的关键阶段时，为了制止漫衍式系统所固有的不行靠性导致提交事务意外失败，TM会坚决决议实施两步走的方案。

(1）先提倡投票表决，通知所有RM先完成事务提交历程所涉及的种种庞大的准备事情，好比写redo、undo日志，只管把提交历程中所有消耗时间的操作和准备都提前完成，确保后面100%乐成提交事务。如果准备事情失败，则赶快告诉PM。(2）真正提交。在该阶段，TM将基于前一阶段的投票效果举行决议，即提交或取消事务。

当且仅当所有到场的RM都同意提交时，TM才通知所有RM正式提交事务，否则TM将通知所有到场的RM取消事务。RM在吸收到TM发来的指令后将执行相应的操作。下图给出了二阶段提交协议的通信历程（以两个RM为例)。

二阶段提交的精妙之处在于，它充实思量到了漫衍式系统的不行靠因素，而且接纳了很是简朴的方式(两阶段完成）就把由于系统不行靠导致事务提交失败的概率降到最小!下面给出了一个形象的解释历程，来说明二阶段提交是如何做到这一点的。如果一个事务的提交历程总共需要30秒的操作，其中Prepare 阶段要28秒（主要是确保事务日志写入磁盘等种种耗时的I/O操作)，真正的Commit阶段只需要2秒，那么Commit阶段发生错误的概率与Prepare阶段相比，只是它的2/28 (<10%)，也就是说，如果Prepare阶段乐成了，则Commit 阶段由于时间很是短，失败的概率很小，会大大增加漫衍式事务乐成的概率!不得不说，二阶段提交的精妙设计洞穿了漫衍式系统的本质。

但为什么我们在现实中很少会用到二阶段提交的XA事务呢?主要原因有以下几点。·互联网电商应用兴起，对事务和数据的绝对一致性要求并没有传统企业应用那么高。XA事务的介入增加了TM中间件，使得系统庞大化，而且通常支持TM的中间件都是收费的，也增加了软件成本。

互联网开发中的许多人都并不很懂XA相关的技术。XA事务的性能不高，因为TM要等候RM回应，所以为了确保事务只管乐成提交，TM等候超时的时间通常比力长,例如30秒甚至5分钟,如果RM泛起故障或者响应迟缓，则整个事务的性能严重下降。

互联网中的漫衍式事务解决方案现在在互联网领域里有几种盛行的漫衍式解决方案，但都没有像之前所说的XA事务一样，形成X/OpenDTP那样的尺度工业规范，而是仅仅在某些详细的行业里获得较多的认可。下面就对这些解决方案举行先容。第1种解决方案:业务接整合，制止漫衍式事务此方案是将一个业务流程中需要在一个事务里执行的多个相关业务接口包装整合到一个事务中，这属于“就详细问题详细分析”的做法。

就问题场景来说，可以将服务A、B、C整合为一个服务D来实现单一事务的业务流程服务。如果在项目一开始就思量到漫衍式事务的庞大问题，则接纳这里的方案，经心计划和设计系统，制止漫衍式事务;对于实在不能制止的，则接纳其他措施去解决，这应该是最好的做法。第⒉种解决方案:最终一致性方案之eBay模式这是eBay于2008年宣布的关于BASE 准则的论文中提到的一个漫衍式事务解决方案，在业界影响比力大。

eBay的方案其实是一个最终一致性方案，主要接纳了消息行列来辅助实现事务控制流程，其焦点是将需要漫衍式处置惩罚的任务通过消息行列的方式来异步执行。如果事务失败，则可以提倡人工重试的纠正流程。人工重试被更多地应用于支付场景中，通过对账系统对事后的问题举行处置惩罚。

在该论文中形貌了一个很常见的支付生意业务场景:如果某个用户(user)发生了一笔生意业务，则需要在生意业务表(transaction)中增加记载，同时修改用户表的金额（余额)，由于这两个表属于差别的远程服务，所以涉及漫衍式事务与数据一致性的问题。下面是用户表与生意业务表的表结构:user(id, name, amt_sold, amt_bought)transaction(xid, seller_id,buyer id, amount)其中user表记载用户生意业务的汇总信息，transaction表记载每个生意业务的详细信息。在举行一笔生意业务时需要对数据库举行以下操作:INSERT INTO transaction VALUES (xid, $seller_id,$buyer_id, $amount);UPDATE user SET amt_sold = amt_sold + $amount WHERE id = $seller_id;UPDATE user sET amt bought = amt_bought + $amount WHERE id = $buyer_id;这里不用XA事务模型,而是接纳消息行列来分散事务。

先启动一个事务,在更新transaction表后，并不直接更新user表，而是将要对user表举行的更新行动作为消息插入消息行列中，如下所示:begin;工NSERT INTO transaction VALUES (xid, $seller_id, $buyer_id, $amount);put_to_queue "update user("seller", $seller_id, amount);put_to_queue "update user ("buyer",$buyer_id, amount) ;commit;注意，消息行列与对transaction 的操作使用了同一套存储资源，因此这里的事务不涉及漫衍式操作。另外，开启独立历程，从消息行列中获取上述消息，举行接下来的处置惩罚历程：for each message in queuebegin;if message.type = "seller" thenUPDATE user SET amt_sold = amt_sold + message.amount WHERE id = message.user_id;elseUPDATEuser SET amt bought = amt bought + message.amount WHERE id =message.user_id;dequeue message;endcommit;end初看这个方案并没有什么问题，但实际上还没有解决漫衍式问题。为了使第1个事务不涉及漫衍式操作，消息行列必须与transaction表使用同一套存储资源。

但为了使第﹖个事务也是当地的，消息行列存储又必须与user表在一起。这两者是不行能同时满足的，我们假设消息行列与transaction表使用同一套存储资源，则后面从消息行列消费消息的逻辑来看可能会发生纷歧致的错误:数据库已经更新了user的余额信息,但接下来从消息行列中删除消息时发生异常，好比历程死机或者消息服务突发故障，则此消息还在系统中，下次又会被投递，发生了消息被重复投递的问题。除非此消息的处置惩罚逻辑具有幂等性，可以重复触发，否则重复投递消息就会引发事故。

那么,如何解决这个问题呢? eBay给出了一个简朴思路:增加一个message_applied( msg_id)表来记载被乐成消费过的消息，过滤重复投递的消息。于是，第2段逻辑被改为下面这种方式:for each message in queuebegin;SELECT count (*) as cnt FROM message_applied WHERE msg_id = message.id;if cnt 0thenif message.type - "seller" thenUPDATE user SET amt_sold = amt_sold + message.amount WHERE id = message.user_id;elseUPDATE user SET amt_bought = amt_bought + message.amount WHERE id =message.user_id;endINSERT INTO message_applied VALUES(message.id);endcommit;if上述事务乐成dequeue messageDELETE FROM message_applied WHERE msg_id = message.id;endend上述模型中的消息中间件纷歧定是一个尺度的通用的消息中间件，也可以是一个基于数据库存储的简朴实现的消息服务，这个消息服务的实现只需保证下面两点即可。消息要与第1个事务中涉及的数据在同一个存储资源系统中，从而使用当地事务模式，保证事务的原则性效果。

消息的服务性能要好。留一个思考题，如果上述生意业务流程涉及3个或更多的环节，那么这里的消息中间件与数据表之间的当地事务又需要怎样设计?eBay 的这个漫衍式事务模型之所以成为一个经典案例，是因为它的思路直观，而且代码和方案简朴有效，因此，厥后许多人都参考借鉴了它的这一模型，其中，网上公然的蘑菇街的生意业务订单流程就比力特别，如下图所示。

在生意业务建立流程中，首先建立一个不行见订单，然后在同步伐用锁券和扣减库存时，针对换用异常（失败或者超时）发出废单消息到消息中间件。如果消息发送失败，则当地会做时间门路式的异步重试;优惠券系统和库存系统在收到消息后，会判断是否需要做业务回滚，这样就实时保证了多个当地事务的最终一致性。

第3种方案: XIOpenDTP模型的支付宝的DTS框架DTS(Distributed Transaction Service)框架是由支付宝在X/OpenDTP模型的基础上革新(模拟）的一个设计，界说了类似于2PC的尺度两阶段接口，业务系统只需要实现对应的接口就可以使用DTS的事务功效。DTS 从架构上分为xts-client和 xts-server两部门，前者是一个嵌入客户端应用的JAR文件，主要卖力事务数据的写入和处置惩罚;后者是一个独立的系统，主要卖力异常事务的恢复。

DTS最大的特点是放宽了数据库的强一致约束，保证了数据的最终一致性(Eventually Consistent）。本文给大家解说的内容是架构解密从漫衍式到微服务：带大家重新认识漫衍式事务下篇文章给大家解说的是架构解密从漫衍式到微服务：聊聊RPC，从IPC通信说起；以为文章不错的朋侪可以转发此文关注小编；谢谢大家的支持！。

本文来源：亚博AG娱乐-www.shxuanying.com