此次运用分布式事件框架历程当中了进修了一些分布式事件学问，所以本文我们就来聊聊分布式事件那些事。起首我们先回忆下什么是事件。
事件
什么是事件？这个作为后端开辟，一样平常开辟中只要与数据库有交互，一定就会运用过事件。如今摘抄一段wiki的诠释，诠释下什么是事件。
是数据库治理体系实行历程当中的一个逻辑单元，由一个有限的数据库操纵序列组成
数据库体系具有事件特征，这是其有别与文件体系重要特征。传统的文件体系，假如正在写文件，操纵体系倏忽崩溃，此时文件能够被损坏。数据库体系引入事件特征，能够保证数据库从一种状况转换为另一种状况。在提交事情时,能够确保要么一切修正都被保留，要么一切都不保留。
平常一个事件会有多个读写操纵组成。
事件具有四个基本特征，俗称ACID。
A(Atomicity):原子性。事件会被当作一个团体，要么一切语句都胜利，要么都失利，不能存在部份语句胜利，部份失利的状况。
C(Consistenc):一致性。数据库的状况从一种状况转变为别的一种状况，事件最先之前和是事件完毕今后，数据库完整性束缚稳定。什么叫数据库完整性束缚稳定？举个例子，若一个表姓名字段为唯一束缚，若在事件提交或回滚后，姓名字段变成非唯一了，这就损坏数据库的完整性束缚。
I(Isolation):断绝性。多个并发事件实行，互不影响。
D(Durability):持久性。事件提交今后，其对数据库相干修正能永远保留在数据库。所以该特征须要数据库体系能够在崩溃时须要恢复时也能提交的数据都不丧失。
因而初期我们的体系只在存在一个数据源状况下，这个时刻能够依托数据库体系事件来保证营业的正确性。
然则跟着营业的不停扩大，我们营业的一个单表能够就存在万万数据，在运用再运用一个数据库实例，就会能够存在性相干能题目。这个时刻我们就会斟酌分库分表。然则如许就有能够致使，单个运用衔接多个数据源的状况。以下图示例。
上图一次购买历程，商家余额表与用户余额表处于两个零丁的数据库实例中，如许零丁的事件能保证扣减商家余额或用户余额要么扣减胜利，要么扣减失利。然则我们却没法保证两个事件同时胜利或同时失利。
另有一种状况，跟着体系愈来愈巨大，我们会挑选将体系运用拆分多个微效劳，让单个运用只操纵一个数据源。这个时刻我们就会遇到，一次营业挪用，将会挪用多个运用，每一个运用零丁操纵数据源的状况，以下图。
这类状况下我们越发不能保证一切挪用都胜利。
由上面的例子下我们能够看出，跟着营业生长，传统的单机事件已没法满足我们的营业的需求，这个时刻我们就须要分布式事件来保证。
分布式事件
摘抄一段 wiki 上诠释。
A distributed transaction is a database transaction in which two or more network hosts are involved.
我们先来讲下完成分布式事件一些理论基本。
分布式事件手艺理论
CAP 定理。在一个分布式体系（指相互衔接并同享数据的节点的鸠合）中，当触及读写操纵时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，别的一个必需被捐躯。
摘录极客时候从0最先学架构第22章诠释
虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思索，我们会发明必需挑选 P（分区容忍）要素，因为收集自身没法做到 100% 牢靠，有能够出毛病，所以分区是一个必定的征象。假如我们挑选了 CA 而摒弃了 P，那末当发作分区征象时，为了保证 C，体系须要制止写入，当有写入请求时，体系返回 error（比方，当前体系不许可写入），这又和 A 争执了，因为 A 请求返回 no error 和 no timeout。因而，分布式体系理论上不能够挑选 CA 架构，只能挑选 CP 或许 AP 架构
BASE 理论，离别是以下三个单词的缩写。
Basically Available（基本可用）：分布式体系在涌现毛病时，许可丧失部份可用功用，保证中心功用可用。
Soft state（软状况）：许可体系中存在中间状况，这个状况不影响体系可用性，这里指的是CAP中的不一致。
Eventually consistent（终究一致性）：终究一致是指经由一段时候后，一切节点数据都将会到达一致。
BASE 是对CAP 中 AP 计划的一种补充。在 BASE 顶用软状况和终究一致，保证了耽误后的一致性。BASE 和 ACID 是相反的，ACID 是一种强一致性模子，而 BASE 倒是捐躯这类强一致性，许可数据短时候内不一致，终究一致性。
接下来我们看看分布式事件有哪几种完成计划。
分布式事件完成计划
基于数据库资本层面
2PC 两阶段提交协定
3PC 三阶段提交协定
基于营业层面
TCC
基于数据库资本层面完成计划，因为存在多个事件，我们须要存在一个角色治理各个事件的状况。我们将这个角色称为谐和者，事件参与者称为参与者。参与者与谐和者平常会基于某种特定协定，现在比较著名的为 XA 接口协定。基于谐和者与参与者的头脑设定，离别提出了 2PC 与 3PC 完成XA 分布式事件。
2PC 两阶段提交协定
如名字所知，这个历程重要分为两步。
第一阶段，谐和者(事件治理器)将触及到事件的举行预提交，这个时刻数据库资本最先被锁定。参与者将 undo 与 redo 写入事件日记。
第二阶段，参与者（资本治理器）行提交事件，或许应用 undo 日记回滚事件，开释资本。
悉数历程以下图。
分布式事件提交胜利场景：
分布式事件回滚场景：
该计划的长处为:完成比较简朴，主流数据库都支撑，强一致性。MySQL 5.5 今后基于 XA 协定完成.
相应当计划也存在瑕玷:
谐和者的单点题目。若谐和者在提交阶段宕机，参与者一向在守候,就一向锁定资本，一向壅塞。虽然能够从新推举谐和者，然则没法处理该题目。
同步壅塞时候太长，悉数实行历程事件是壅塞的，直到提交完成，开释资本，若在提交历程/回滚历程，因为收集延时，参与者一向未收到指令，则参与者一向被壅塞。
数据不一致。第二阶段，谐和者发出第一个提交信号后后宕机，则第一个参与者提交事件，第二个参与者因为未收到谐和者信号，没法举行事件提交。
因而针对 2PC 存在的瑕玷，提出革新计划，3PC。
3PC 三阶段提交协定
三阶段提交，在两阶段提交的基本下，革新两阶段。三阶段步骤以下。
CanCommit,谐和者讯问参与者是不是能够举行事件提交。
PreCommit ,若一切参与者能够举行事件提交，谐和者下达 PreCommit 敕令，参与者锁定资本，并守候终究敕令。
一切参与者返回确认信息，谐和者向各个事件下发事件实行关照，锁定资本，并将实行状况返回。
部份参与者返回否定信息或谐和者守候超时。这类状况，谐和者以为事件没法一般实行，下发中断指令，各个参与者退出准备状况
Do Commit，若第二阶段悉数回应 ack，则下达 Do Commit ，举行事件终究提交，不然下达中断事件敕令，一切参与者举行事件回滚。
一切参与者一般实行实行事件，谐和者下发终究提交指令，开释锁定资本。
部份参与者实行事件失利，谐和者守候超时，谐和者下发还滚指令，开释锁定资本。
细致见下图。
三阶段提交对照两阶段，引入超时机制削减事件壅塞，处理单点毛病。在第三阶段，一旦参与者没法接受到谐和者信号时，守候超时今后，参与者默许实行 commit，开释资本。
三阶段任然不能处理数据一致性题目。若谐和者发出回滚敕令，然则因为收集题目，参与者在守候时候内都没法接收到，这时候参与者默许提交事件，而其他事件举行了回滚，形成事件不一致。
TCC
TCC 事件
为了处理在事件运转历程当中大颗粒度资本锁定的题目，业界提出一种新的事件模子，它是基于营业层面的事件定义。锁粒度完整由营业本身掌握。它实质是一种赔偿的思绪。它把事件运转历程分红 Try、Confirm / Cancel 两个阶段。在每一个阶段的逻辑由营业代码掌握。如许就事件的锁粒度能够完整自在掌握。营业能够在捐躯断绝性的状况下，猎取更高的机能。
TCC 离别为 Trying，Confirm，Cancel 三个单词缩写。不同于 2PC 与 3PC 基于数据库层面，TCC 基于运用层面。
TCC 三个行动离别为：
Trying：
完成一切营业搜检(一致性)
预留必需营业资本(准断绝性)
Confirm:
真正实行营业
Confirm操纵要满足幂等性
Cancel:
开释Try阶段预留的营业资本
Cancel操纵要满足幂等性
上面说法，一听起来有点生涩难明，没紧要我们运用实际案例诠释。
下面我们模仿商城一次付出历程。用户下单运用组合付出，即余额加红包付出。一次一般流程为：
建立定单
下单
挪用余额体系，扣减余额
挪用红包体系，扣减红包余额
修正定单状况为已付出
完后付出。
实际历程以下图。
然则这么一个付出历程挪用多个子效劳，我们不能保证一切效劳都能胜利，比方我们在挪用红包体系扣减红包体系失利。这个时刻我们就遇到为难的场景，因为红包效劳失利，致使要领异常退出，这个时刻定单状况为初始状况，然则用户余额已扣减。这对用户体验异常不友好。所以此次付出历程，我们必需存在机制将此次历程当做一次团体的行动，必需保证这个中效劳挪用，要么都胜利，要么都失利，成为一个团体的事件。
这时候我们能够引入 TCC 事件，将悉数下单历程作为一个团体。引入后，因为余额体系扣减是失利，这个时刻我们回滚定单体系与红包体系。悉数历程以下图。
因为余额体系的失利，我们须要打消此次历程当中一切变动，所以我们向定单体系发送打消关照，向红包体系发出打消关照。
因而体系引入 TCC 事件后，我们须要革新我们的挪用历程。
体系怎样引入 TCC 事件
依据 TCC 事件三步，这个时刻我们必需将各个效劳改形成 Try Confirm Cancle 三步、
TCC TRY:
依据上面的营业，定单体系增添 try 要领将定单状况修正成 PAYING。余额体系增添一个 try 要领，先搜检用于余额是不是足够，然后先将余额扣减，然后将扣减的余额增添到凝结金额。红包体系同余额体系。从革新历程能够看出，TCC try 要领需搜检各营业资本，且这历程须要引入中间状况。我们依据下图来看悉数历程。
TCC Confirm:
TCC 第一步 TRY 假如一切子效劳挪用都胜利，这个时刻我们就须要确认各效劳。各个效劳增添 confirm 要领。如余额体系 confirm 要领用来将凝结金额置为0，红包体系如上。定单体系将定单状况修正为 SUCCESS。confirm 要领须要注重完成幂等。如定单体系更新前，一定要先推断该笔定单状况处于 PAYING，才更新定单。悉数历程以下图。
讲到这里，必需用到 TCC 事件框架推进各效劳。TCC 事件治理器感知到 TRY 要领完毕后，自动挪用各效劳供应的 confirm 要领，将各效劳状况修正为终态。
TCC Cancle：
如若 TCC Try 历程当中，凝结红包要领失利，这时候我们就须要将之前修正都打消，修正成其初始状况。cancle 要领也须要完成幂等如 confirm 要领 以下图：
看到这，我们我们能够看出 TCC Try 胜利，confirm 必定要胜利，try 失利，cancle 必定要胜利。因为 confirm 是体系更新为终态的症结。然则实际这么无情，生产体系 confirm 或 cancle 一定会有概率失利，这个时刻就须要 TCC 框架纪录挪用 confirm 效果。假如 confirm 挪用失利，TCC 框架须要纪录下来，然后距离一定时候再次去挪用。
总结与思索
看完整文，基本上对分布式事件又一定相识了吧。
我们基于此对此总结下。运用分布式事件，我们须要连系我们实际场景运用。
假如营业还处于最先阶段，我们实在能够挑选数据库事件来保证疾速上线迭代。
比及营业一定阶段，体系最先拆分，数据库也拆分，这时候假如营业须要保证一致性，这时候必需运用分布式事件。这时候刻运用分布式事件，我们须要基于营业斟酌运用哪一种。
运用 2PC 或 3PC 完成的分布式框架，营业运用层无需修改，接入较简朴。然则相对应能较低，数据资本锁定较长。不太合适互联网等高并发营业场景。
而运用基于 TCC 完成分布式框架，相对 2PC 机能较高，能够保证数据终究一致性。然则关于运用层来讲，一个要领必需改形成三个要领，且营业中需引入一些中间状况，相对而言运用革新水平较大。
以上就是分布式事件的图文详解的细致内容，更多请关注ki4网别的相干文章！
