大家好，今天小编来为大家解答交易平台一致性这个问题，保证分布式系统数据一致性的6种方案很多人还不知道，现在让我们一起来看看吧！

本文目录

1. 保证分布式系统数据一致性的6种方案
2. 国际交易所上市品种的合作模式
3. 如何保证分布式系统的消息最终一致性

一、保证分布式系统数据一致性的6种方案

编者按：本文由「高可用架构后花园」群讨论整理而成。

在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？

具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C可能是多个不同部门开发、部署在不同服务器上的远程服务。

在分布式系统来说，如果不想牺牲一致性，CAP理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。

在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL主从同步）又有一定区别，群友的讨论分成以下 6种解决方案。

业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C整合为一个服务 D给业务，这个服务 D再通过转换为本地事务的方式，比如服务 D包含本地服务和服务 E，而服务 E是本地服务 A~ C的整合。

优点：解决（规避）了分布式事务。

缺点：显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。

由于这个方法存在明显缺点，通常不建议使用。

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

消息日志方案的核心是保证服务接口的幂等性。

考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。

此方案是 eBay的架构师 Dan Pritchett在 2008年发表给 ACM的文章，是一篇解释 BASE原则，或者说最终一致性的经典文章。文中讨论了 BASE与 ACID原则在保证数据一致性的基本差异。

如果 ACID为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是

BASE(basically available, soft state, eventually consistent)

BASE的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5个数据库服务器上，BASE设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20%的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。

文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。

文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied来记录已经处理过的消息。

基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction表及消息队列。

在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied来检测相关记录是否被执行，未被执行的记录会修改 user表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。

通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay的方案可以参考文末链接。

随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。

最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。

但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去操作库。这就涉及一个『分布式事务』的问题。

上文已经说过，使用异步消息 Consumer端需要实现幂等。

幂等有两种方式，一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。

另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。对于 producer端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。

2.有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。

比如 A同步调用 B，C。A本地事务成功的时候更新本地事务记录状态，B和 C同样。如果有一次 A调用 B失败了，这个失败可能是 B真的失败了，也可能是调用超时，实际 B成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A成功，B失败，C成功。那么最终决定有两种方式，根据具体场景：

对 b场景做一个特殊说明：比如 B是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A和 C了。

那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？

实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA在公司所有 MySQL实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。

总结起来，其实两种方式的根本原理是类似的，也就是将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性。

我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。

每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？

服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10个服务，9个都执行成功了，最后一个执行失败了，那么是不是前面 9个都要回滚掉？这个成本还是非常高的。

所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。

消息通知往往不能保证 100%成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。

所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。

要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。

我们在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。

业界常用的还有支付宝的一种 xts方案，由支付宝在 2PC的基础上改进而来。主要思路如下，大部分信息引用自官方网站。

分布式事务服务(Distributed Transaction Service, DTS)是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS从架构上分为 xts-client和 xts-server两部分，前者是一个嵌入客户端应用的 JAR包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。

传统关系型数据库的事务模型必须遵守 ACID原则。在单数据库模式下，ACID模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE规范中使用 2PC(2 Phase Commit,两阶段提交)来处理跨 DB环境下的事务问题，但是 2PC是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE的思想实现了一套类似 2PC的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致(Eventually consistent)。

公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo的 RPC服务。

对于业务部门来说，电商部门的订单支付，需要调用

从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。

我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。

具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch方法调用积分平台的回撤方法，将本次处理的积分订单回撤。

分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。

In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.

英文版：

中文版：

感谢李玉福、余昭辉、蘑菇街七公提供方案，其他多位群成员对本文内容亦有贡献。

本文编辑李玉福、Tim Yang，转载请注明来自@高可用架构

二、国际交易所上市品种的合作模式

1、随着国际衍生品市场的发展，交易所之间的合作越来越紧密，合作模式亦趋于多样化。目前，品种合作模式主要有结算价授权模式、交叉投资模式、相互冲销模式以及其他新型模式。

2、结算价授权是指本市场上市其他市场的品种，通过签订结算价授权协议将其他市场的结算价作为本市场该品种的结算价。目前，CME集团与马来西亚以及南非等地交易所的合作便采取此种方式。

3、结算价授权模式相对简单，以CME集团与马来西亚交易所合作为例，假设客户A在CME结算会员处设有期货账户，具体交易结算过程为：客户A向其CME经纪商下一个交易指令；CME经纪商将交易单传递到CME撮合；马来西亚每日授权CME该品种结算价；CME使用该结算价为客户B进行现金结算。

4、合约可存在差异。交易所仅引入另一市场同一品种合约的结算价作为本交易所该品种的结算价，在合约的设计方面可以根据自身市场的特点进行一定的修改，不需要与另一市场保持一致。

5、交易所行情相互独立。结算价授权模式中，被授权交易所仅在结算时才引入授权交易所结算价作为本交易所该品种结算价，其合约行情走势基本独立于授权交易所。

6、结算独立进行。结算价授权模式下，交易所上市的品种仅属于该交易所本身，交易所与另一市场并不存在结算连接，即该品种的结算与另一交易所是完全独立的。

7、合作简单。仅需两个交易所签订结算价授权协议便可完成该模式的合作，在合约、交易以及结算等各个方面均没有任何特殊的要求。

8、不需现货市场支持。所有商品期货的上市都需要依托现货市场，如果交易所缺乏现货市场便可以使用结算价授权模式，将有现货依托市场的期货价格引入本市场，避免价格的随意波动。

9、合作方式较为浅层。通过结算价授权模式在本交易所上市其他市场的品种，本交易所与其他交易所没有太多联系，合作层次较浅。

10、存在汇率风险。结算价授权常面临两地计价货币不同的情况，合约设计上均会对价格转换进行一系列的规定，汇率风险便是交易被授权结算价市场合约的重大风险。

11、交叉挂牌是指本交易所与其他交易所通过签订交叉挂牌协议，将本交易所的上市品种在对方交易所交易平台上进行挂牌，从而方便对方市场投资者参与本交易所品种交易，以扩大本交易所的市场影响力。目前，CME集团与马来西亚、印度以及巴西等地交易所的合作均采取此种方式。

12、以印度国家证券交易所（NSE）为例，假设客户A在CME结算会员处设有期货账户，客户B在NSE结算会员处设有期货账户，则具体交易结算过程为：若客户A计划交易NSE在CME的挂牌品种，首先需要在客户B处开立账户；客户A通过CMEGlobex进行下单交易，CMEGlobex将下单信息传递至NSE，由NSE进行统一撮合；NSE将撮合结果反馈至CMEGlobex及客户B，最后由CMEGlobex传递至客户A处；客户A每日的结算及到期日交割均由客户B完成。

13、合约的一致性。本交易所借用对方交易所的交易平台，将本交易所品种进行挂牌交易，本质上说是同一个合约在两地的分别挂牌，因此合约是保持一致的。

14、合约行情统一撮合。品种虽在两地交易所进行挂牌，但是行情由一个交易所集中撮合产生，因此一个合约只有一个行情价格。

15、结算独立进行。交叉挂牌模式下，交易所通过对方交易平台进行挂牌，在交易上借用对方通道进行，而结算则由各自的结算所进行，是完全独立的。

16、合作依然较为简单。仅需两个交易所签订交叉挂牌协议便可完成该模式的合作，在结算制度及法律环境等各个方面均没有任何特殊的要求。

17、增强本交易所品种的市场影响力。如果一个市场不够活跃，那么这一市场上市的品种及其市场价格的影响力就十分有限，若将该品种挂牌到交易活跃的市场，不仅能够吸引其他市场的交易者参与交易，更直接提高了本交易所上市品种的市场地位。

18、结算安排复杂。本地交易所投资者若想进行对方交易所品种的交易，必须在对方交易所结算会员处开立结算账户，所有的结算均由对方交易所结算会员进行，结算过程难免繁复。

19、交易系统对接困难。品种互挂需要建立在两家交易所交易系统能够较好对接的基础上，否则交易与结算信息便无法进行传递，品种互挂更无从谈起。因此，交叉挂牌模式对技术有一定的要求。

20、相互冲销系统模式(简称MOS模式)是指在对合约内容、合约设计、交易规则、保证金制度、交易时间等方面进行统一的前提下，外地交易所引进本地交易所合约，并通过两个交易所结算机构的连接，实现异地对冲引进合约头寸的一种联网交易模式，MOS是CME与SGX在1984年签订的跨市场挂牌与对冲的机制。

21、假设客户A在CME和SGX的结算会员处都分别设有期货账户，在CME开盘时段（SGX收盘时段）在CME下单交易Eurodollar期货，并声明是MOS交易单，申请将成交后的头寸转移到SGX某结算公司的账户，具体步骤为：客户A向其CME经纪商下一个MOS交易单；CME经纪商将交易单传送到CME撮合；CME撮合完成后汇报成交资料给经纪商；CME的MOS系统将成交后的资料传送给SGX的MOS系统资料库，等待新加坡方面的经纪商核准与转移头寸；SGX的会员经纪商通过MOS系统接收头寸转移资料并核准；SGX会员经纪商将转来的头寸记入该客户在新加坡的账户；SGX会员经纪商在MOS系统确认头寸已转移成功；SGX的MOS系统回报头寸转移成功给CME端的MOS系统；CME会员经纪商自MOS系统收取回报资料；CME经纪商冲销客户A已被转移的头寸。

22、两地市场环境保持一致性。由于涉及到交易头寸的转移及两地结算所的跨市场结算，因此相互冲销模式无论在合约设计还是市场规则（包括法律环境和交易规则）等方面都要求两个市场保持高度一致性。

23、行情分段进行撮合。相互冲销模式中，由于两地交易所交易时间并不一致，同一合约在不同交易时间段内分别由不同交易所进行集中撮合，再通过MOS系统相互进行信息传递，因此行情是分段进行的。

24、结算所合作程度高。在MOS系统中，两家结算所各自作为对方的特殊结算会员，面对对方的风险。因而，在这一合作模式中，对结算所的风险管理要求较高。结算所如果要进行这方面的合作，必须满意对方结算所的风险管理与保护系统。

25、延长交易时间。随着信息化的发展，现货交易市场及参与人遍及全球，且风险暴露也不因单一交易所休息而暂停，因此需要一个24小时交易的期货市场，应对24小时存在的风险。跨市场挂牌就是延长交易时间的解决方案，由于没有收盘后无法交易的限制，24小时交易可以为投资人提供在任何时候对重大信息的即时反应及任何时刻的避险、投机与套利的机会。

26、跨市场结算便利。MOS模式下，跨市场结算由两地交易所完成，增加了跨市场结算的便利性。除此之外，MOS模式将转移交易功能的机制进行改进，一方面将原本限于国内期货商间的转移交易协定延伸为跨国期货会员间的协定，另一方面将单方的转移交易协定扩展为双向转移交易。

27、对两个市场一致性要求太高。要实现两个市场的连通，两家交易所所处环境的法律和交易规则要基本一致，这样才能使两个市场的连通不存在规则上的障碍。在合约交易制度方面，跨市场挂牌后，应遵循原合约规格设定的原则，新挂牌的市场就需要修改系统以适应原合约规格。因此相互冲销模式在合约的设计、交易的规则以及保证金制度的安排等方面保持了高度一致，同时也要求法律环境保持一致，实施的难度非常大。

28、两地市场可能形成竞争关系。在跨市场挂牌中，两地的交易人都可以选择在国内或国外交易，双方合作的关系中因而隐含着竞争的成分。理想的状态是，跨市场挂牌双方的显性交易成本（包括手续费、结算费、税负等）应尽量相当，以避免处于成本劣势的市场无法开展或发生交易量转移的现象。

29、除了CME采用的品种合作的模式外，泛欧交易所（EUREX）与韩国交易所（KRX）的合作同样是值得借鉴的一种品种合作新型模式，本文称其为泛欧交易所新型模式。泛欧交易所灵活运用一日期货的概念，将KOSPI200期权合约作为标的物，推出一日KOSPI200期权期货合约（DailyFuturesonKOSPI200Options）。

30、假设客户A在EUREX和KRX的结算会员处都分别开有期货账户，在EUREX开盘时段在EUREX下单交易DailyFuturesonKOSPI200Options，待交易结束后，该头寸将会直接进行交割，投资者获得期权合约并将合约转移至KRX进行下一步交易，具体步骤为：客户A向其EUREX经纪商下单，交易单传送到EUREX撮合；EUREX撮合后将成交资料传递给经纪商，再反馈给客户A；EUREX收市后，客户A未平仓期货合约进入交割流程，客户A获得KOSPI200期权合约，EUREX经纪商对客户A进行资金结算；客户A期权合约头寸由EUREX转移至KRX,KRX经纪商按照合约份额扣划客户A保证金；客户A通过KRX经纪商进行期权合约平仓操作。

31、新合约的引入。泛欧交易所与韩国交易所合作并不是简单的两个相同合约的平行上市，而是引入了以韩国交易所期权合约为标的的一日期货合约，激发了投资者的参与热情。

32、日内行情相对独立，交割价取决于KRX。泛欧交易所KOSPI产品的日交割价取决于KRX期权合约前一日的结算价，虽然结算价是固定的，但是投资者对赌的是期权合约次日的走势，日内行情保持相对独立，因此其流动性依然不错。

33、结算所头寸单向转移。泛欧交易所新型模式下，泛欧交易所的结算所仅对当日的期货进行交割，交割之后的头寸转移到韩国交易所结算所下，因此头寸仅进行一次性的单向转移。

34、变相延长交易时间。虽然泛欧交易所交易的是以KOSPI200期权为标的的期货，但是通过交易最终都会变为期权，变相延长了韩国交易所的交易时间，且在很大程度上增加了韩国交易所期权的成交量，而泛欧交易所则主要通过收取期货交易及交割费用获利。

35、对于结算所一致性的要求并不高。泛欧交易所新型模式下，泛欧交易所上市的其实是一个独立的新品种，只是其标的为KOSPI200期权，而在交割后期权头寸直接被划入韩国交易所，因此只要结算所之间存在信息传递途径即可，不需要对两地结算所制度、法律环境等方面的一致性做出特别要求。

36、增加市场投机性。泛欧交易所上市的KOSPI200期权期货合约交易时间仅为一天，若投资者不希望进行交割，便只能进行日内操作，对韩国夜间消息进行炒作，因此增强了市场整体的投机氛围。

37、合约内容过于复杂。期权合约本身就十分复杂，泛欧交易所的期货合约则以期权合约为标的，其复杂程度并非一般普通投资者能够轻易接受，对投资者的专业性要求较高。

38、总的来说，目前国际之间的合作越来越深入且形式亦趋于多样化，各种模式均有自身优越之处，也存在一定的限制与不足，因此因此国内交易所在选择国际业务合作模式时应该更多考虑合作目的以及技术基础。

三、如何保证分布式系统的消息最终一致性

下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！

如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：

1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；

2、支付平台中创建支付订单（选银行卡支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；

3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；

4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；

5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；

如上图，支付平台收到银行扣款结果后的内部处理流程：

1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；

2、支付订单服务根据银行扣款结果更改支付订单状态；

3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；

4、调用积分服务给用户积分账户增加积分；

5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；

6、调用通知服务将支付处理结果通知电商平台；

如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：

@Transactional(rollbackFor= Exception.class)

orderDao.update();//订单服务本地更新订单状态

accountService.update();//调用资金账户服务给资金帐户加款

pointService.update();//调用积分服务给积分帐户增加积分

accountingService.insert();//调用会计服务向会计系统写入会计原始凭证

merchantNotifyService.notify();//调用商户通知服务向商户发送支付结果通知

以上分布式事务问题，需要多种分布式事务解决方案来进行处理。

资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。

会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）

商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）

参考博文：

关于交易平台一致性的内容到此结束，希望对大家有所帮助。