散布式事务分歧性应战！ 深度解析阿里巴巴对账系统

引言

大家好，我是小米！当天我们来聊一聊阿里巴巴面试题中的一个抢手话题：“散布式事务分歧性？”随着互联网技术的飞速开展，散布式系统曾经成为了各大互联网企业架构的基石之一。但是，在散布式系统中，如何确保事务的分歧性不时是一个备受关注的难题。当天，我将联合我的了解和阅历，为大家详细解析这个话题。

防止散布式事务，驳回轻量级方案

在当今互联网时代，散布式系统的运行曾经成为了各大企业的标配。但是，随之而来的散布式事务分歧性疑问却成为了困扰开发者的一大难题。面对这个疑问，我们的外围宗旨是：尽量防止经常使用散布式事务，而是驳回轻量级的方案来保证数据的分歧性。

为什么要防止散布式事务呢？首先，散布式事务的成功复杂度较高，不只须要思考各个节点之间的通讯和协调，还须要处置各种意外状况，这参与了系统的保养老本。其次，散布式事务会给系统带来额外的功能开支，对系统的吞吐量和照应期间都会发生不小的影响。最关键的是，一旦散布式事务出现疑问，往往会影响整个系统的稳固性，甚至造成系统的宕机。

那么，我们应该如何防止散布式事务呢？首先，关于单进程内的事务操作，我们可以经常使用数据库事务来保证原子性和分歧性。数据库事务的成功相对便捷，而且具有良好的功能体现，适宜于处置各种实时性要求不高的业务场景。其次，关于跨进程通讯的场景，我们可以思考经常使用信息队列来启动异步通讯。信息队列具有较高的牢靠性和稳固性，能够有效地解耦各个系统之间的依赖相关，从而降低系统之间的耦合度，提高系统的可保养性和裁减性。

干流成功散布式系统事务分歧性的方案

在散布式系统中，确保事务分歧性是至关关键的。为了应答这一应战，业界涌现出了多种干流方案，它们努力于保证散布式系统中各个节点的数据操作能够到达分歧的形态。

通常上可行但不介绍的方案

在处置散布式系统事务分歧性时，通常上存在一些可行但并不介绍的方案。这些方案无通常上可以保证数据的分歧性，但在实践运行中存在着各种疑问，使得它们不适宜互联网业界的实践场景。

首先，两阶段提交（2PC）是一种经典的散布式事务协定，它经过协调器和介入者之间的交互来保证事务的分歧性。但是，2PC存在着单点缺点和功能瓶颈的疑问，而且在网络分区和节点缺点等状况下会造成事务的阻塞，降低系统的可用性和牢靠性。

其次，三阶段提交（3PC）是对2PC的改良，经过引入超机遇制和形态同步机制来缩小事务阻塞的期间和减轻单点缺点的影响。但是，3PC的成功复杂度较高，而且在网络分区和节点缺点等状况下依然存在着事务阻塞的疑问，使得它并不适宜高并发、高可用性的互联网业务场景。

此外，补救事务（TCC）和长事务（SAGA）是一种基于补救机制的散布式事务方案，经过在事务口头前后引入补救操作来保证事务的分歧性。但是，TCC和SAGA的成功复杂度较高，而且对业务逻辑的要求较高，容易引入额外的危险和不确定性，因此并不适宜一切的业务场景。

本地数据事务原理

本地数据库事务原理触及多个关键组件，包含undo log、redo log、数据库锁和多版本并发控制（MVCC），它们独特单干以保证事务的原子性、分歧性、隔离性和耐久性。

首先，当一个事务开局口头时，数据库会将的数据形态记载在undo log中，这样即使事务口头环节中出现意外或许事务须要回滚，系统都可以依据undo log将数据库复原到事务开局口头前的形态。这就确保了事务的原子性，即事务要么齐全口头，要么齐全回滚，不会出现局部口头的状况。

其次，当事务口头成功后，数据库会将事务口头后的数据形态记载在redo log中，这样即使数据库出现意外宕机，系统也可以依据redo log将数据库复原到事务口头成功后的形态，保证了事务的耐久性，即事务的结果不会失落。

此外，数据库会经过数据库锁机制来保证事务的隔离性。当一个事务须要对数据库中的数据启动修正时，数据库会对相应的数据行或许数据表启动加锁，防止其余事务对其启动修正或许访问，从而防止了并发操作造成的数据不分歧疑问。

另外，多版本并发控制（MVCC）是一种罕用的事务隔离机制，它经过在数据库中保留多个数据版原本成功事务的隔离性。当一个事务开局口头时，数据库会为其创立一个快照，事务只能看到该快照中的数据，而不会遭到其余事务的影响。这样可以防止事务之间的搅扰，提高了数据库的并发功能。

散布式事务原理

散布式系统的事务处置是一个复杂而又关键的疑问，须要综合思考多个方面来保证事务的原子性、分歧性、隔离性和耐久性。在散布式系统中，成功事务的分歧性是一个十分具有应战性的义务，须要应用全局事务协调器、全局锁和本地数据库事务等多种机制来保证散布式系统的数据操作到达分歧的形态。

首先，全局事务协调器是散布式系统中保证事务分歧性的外围组件之一。它担任协调各个介入者节点之间的事务口头顺序，确保事务在整个系统中的口头顺序是分歧的。全局事务协调器经过向各个介入者节点发送指令，并搜集各个节点的口头结果来成功事务的分歧性。

其次，全局锁是保证散布式系统中事务的隔离性的关键手腕。全局锁可以防止多个事务同时对同一数据启动修正，防止了数据的读写抵触，保证了事务的隔离性。

此外，本地数据库事务也是保证散布式系统事务分歧性的关键组成局部。每个介入者节点在口头事务时都会经常使用本地数据库事务来保证数据的原子性、分歧性、隔离性和耐久性。本地数据库事务经过undo log、redo log、数据库锁和MVCC等机制来成功事务的分歧性，与全局事务协调器和全局锁独特单干，保证了散布式系统中事务的分歧性。

介绍：自研补救/MQ方案+人工介入

在我们公司，为了处置散布式系统中的事务分歧性疑问，我们驳回了一套综合的处置方案，旨在保证系统的稳固性、功能和可保养性。

首先，我们防止了适度依赖散布式事务，而是驳回了轻量级的方案来保证数据的分歧性。关于单进程内的事务操作，我们充沛应用了数据库事务来保证原子性和分歧性。经过本地数据库事务机制，我们可以确保在单个服务内的数据操作到达分歧的形态，防止了散布式事务所带来的额外开支和复杂性。

其次，关于跨进程通讯的场景，我们驳回了信息队列来启动异步通讯。经过信息队列，不同服务之间的数据传输变得愈加牢靠和高效，同时能够保证系统的可伸缩性和可保养性。信息队列的引入降低了系统之间的耦合度，提高了系统的全体功能和灵敏性。

在实践运行中，我们将这两种机制启动了有效的配合。关于触及到多个服务的业务操作，我们将其拆分红多个独立的原子操作，并经常使用信息队列将数据传输到相应的服务，从而成功了散布式事务的解耦和异步化。经过本地数据库事务机制和信息队列的配合，我们不只保证了系统的数据分歧性，还提高了系统的功能和可保养性，为用户提供了更好的服务体验。

此外，我们还驳回了自研补救/MQ方案加人工介入的形式来处置系统对账时的分歧性疑问。该方案在保证系统稳固性的同时，也最大水平地缩小了功能损失，提高了系统的可控性和可保养性。经过这种形式，我们可以灵敏应答不同业务场景下的散布式事务疑问，确保了系统的稳固运转。

不介绍：Seata AT形式

Seata AT形式是阿里巴巴开源的一种散布式事务处置方案，但是在实践运行中，经常使用Seata AT形式或许会面临功能损失的疑问。据统计，经常使用Seata AT形式平均功能降低35%以上，这是一个无法漠视的应战。

功能降低关键源于Seata AT形式驳回的2PC（两阶段提交）协定。在散布式事务中，2PC须要协调多个介入者节点的事务操作，其中包含预提交和最终提交两个阶段。这种协调机制会引入额外的网络通讯开支和期待期间，从而造成事务的口头效率降低。

另外，由于Seata AT形式须要在全局事务协调器和介入者节点之间启动频繁的通讯和同步，这也会参与系统的负载和照应期间。特意是在高并发、大数据量的场景下，这种功能损失愈加清楚，或许会造成系统的功能无法满足业务需求。

但是，值得一提的是，只管Seata AT形式存在功能降低的疑问，但在某些特定场景下依然是一种可行的选用。例如，关于对数据分歧性要求较高，但并发量不是特意大的业务场景，经常使用Seata AT形式能够保证事务的分歧性，而功能损失可以在必定水平上被接受。

不介绍：RocketMQ事务信息

RocketMQ事务信息是一种弱小的散布式信息处置方案，但在某些业务场景下或许不实用，特意是关于同步性强的处置链路。

关于同步性强的处置链路，例如须要保证信息的顺序性或许实时性十分高的业务场景，RocketMQ事务信息或许不太适宜。由于RocketMQ事务信息的处置机制中，须要期待本地事务口头成功后才会将信息发送到信息队列，这会造成信息发送的提前和不确定性。而关于同步性强的业务场景，提前和不确定性或许会对业务流程发生不利影响，甚至引发一系列的疑问。

另外，关于须要保证信息的顺序性的业务场景，RocketMQ事务信息也或许存在一些限度。只管RocketMQ事务信息可以经过本地事务和信息的发送顺序来保证信息的顺序性，但在实践运行中，由于网络提前和节点缺点等要素的影响，依然或许出现信息顺序凌乱的状况，从而造成业务逻辑的失误或许不分歧。

但是，关于一些异步性强、不强依赖信息顺序性的业务场景，RocketMQ事务信息依然是一种十分有效的选用。例如，关于须要保证数据的最终分歧性，但对信息发送的实时性和顺序性要求不高的业务场景，RocketMQ事务信息可以很好地满足需求，经过事务形态和回查机制来保证信息的牢靠传输，从而保证系统的稳固性和牢靠性。

下游MQ成功生产疑问

在信息队列系统中，确保信息被下游生产方成功生产是至关关键的。假设信息未能成功被生产，或许会造成数据失落、业务逻辑失误以及系统不分歧等重大结果。因此，我们强调要求下游MQ生产方必定能够成功生产信息。若信息生产失败或许出现意外状况，我们必定迅速介入处置，以保证系统的稳固运转和数据分歧性。

为了确保信息被成功生产，首先我们应该在信息发送方和信息接纳方之间建设良好的通讯机制和协定。信息发送方应该能够及时地将信息发送到信息队列中，并确保信息的牢靠性传输。而信息接纳方则须要具有高牢靠性和高并发处置才干，以确保能够及时、正确地生产信息。

在信息生产方，我们必定成功幂等性，即使信息重复活产也不会对系统发生负面影响。经过成功幂等性，我们可以有效地防止因信息重复活产而引发的数据失误和业务逻辑意外，保证系统的数据分歧性和稳固性。

另外，当信息生产失败或许出现意外时，我们须要立刻介入处置。一种经常出现的处置形式是将生产失败的信息转发到人工处置队列，由专业人员启动剖析和处置。经过人工介入处置，我们可以及时发现和处置信息生产失败的要素，从而保证系统的反常运转和数据分歧性。

成功幂等性

在信息队列系统中，成功幂等性是至关关键的。幂等性是指无论信息被生产多少次，都不会扭转系统的形态，保证了系统的数据分歧性和稳固性。因此，我们强调千万记得成功幂等性，以应答信息重复活产或许带来的危险和应战。

成功幂等性的关键在于设计生产方的业务逻辑。首先，我们须要确保生产方的处置逻辑是幂等的，即雷同的信息被生产屡次，系统的形态都坚持分歧。这通常须要在生产方的业务逻辑中参与惟一标识或许版本号等信息，以辨别不同的信息，并依据这些信息判别能否曾经处置过该信息。

其次，须要在生产方的业务逻辑中成功幂等性审核和保证机制。这包含对生产方的处置逻辑启动幂等性审核，以确珍重复活产不会发生影响；同时，须要在生产方的处置逻辑中参与幂等性保证措施，例如在数据库操作中经常使用惟一索引或许失望锁来防止反双数据拔出或降级。

另外，我们还可以借助信息的惟一标识或许信息ID等信息来成功信息的去重和幂等性。经过记载曾经处置过的信息ID，我们可以在生产方启动幂等性校验时，极速判别信息能否曾经被处置过，从而防止重复活产和重复处置。

总的来说，散布式事务是一个复杂而又关键的话题，我们须要依据实践业务场景选用适宜的处置方案。在选用方案时，要综合思考功能、可保养性和业务需求，才干做出最适宜的决策。