微办事进阶场景实战：终究统一性与实时统一性解决计划如何设计？

尼采的太阳

数据统一性
后面总结了微办事的9个痛点，有些痛点没有好的解决计划，而有些痛点是有对策的，从本章开始，就来说解某些痛点对应的解决计划。
这一章先解决数据统一性的问题，先来看一个实际的业务场景。
业务场景：上游办事失败后下游办事如何独善其身
后面讲过，使用微办事时，得多时分需求跨多个办事去更新多个数据库的数据，架构如图13-1所示。


? 图13-1 微办事上上游示用意
如图13-1所示，假如业务正常运行，3个办事的数据应该分别变成a2、b2、c2，此时数据才统一。然而假如泛起网络颤动、办事超负荷或者数据库超负荷等状况，全部处置链条有可能在步骤2失败，这时候数据就会变为a2、b1、c1；固然也有可能在步骤3失败，终究数据就会变为a2、b2、c1。这样数据就犯错了，即数据纷歧致。
在本章所探讨的名目开始以前，由于以前的革新名目时间很紧，所以开发人员彻底没有精神处置零碎数据统一性的问题，终究业务零碎泛起了得多过错数据，业务部门发工单告诉IT部门数据有问题，通过一番反省后，IT部门发现是由于散布式更新的缘故致使了数据纷歧致。
此时，IT部门不能不抽出时间针对数据统一性问题给出一个牢靠的解决计划。经过探讨，IT部门把数据统一性的问题归类为下列两种状况。
1.实时数据纷歧致能够承受，但要包管数据的终究统一性
由于一些办事泛起过错，致使图13-1中的步骤3失败，此时处置完申请后，数据就变为了a2、b2、c1，不外不妨事，只需包管终究数据是a2、b2、c2便可。
在以往的一个名目中，业务场景是这样的（示例有所简化）：批发下单时，个别需求完成在商品办事中扣除商品的库存、在定单办事中生成一个定单、在买卖办事中生成一个买卖单这3个步骤。假定买卖单生成失败，就会泛起库存扣除、定单生成，但买卖单没有生成的状况，此时只需包管终究买卖单胜利生成便可，这就是终究统一性。
2.必需包管实时统一性
假如图13-1中的步骤2和步骤3胜利了，数据就会变为b2、c2，然而假如步骤3失败，那末步骤1和步骤2会当即回滚，包管数据变回a1、b1。
在以往的一个名目中，业务场景相似这样：用户使用积分兑换折扣券时，需求完成扣除用户积分、生成一张折扣券给用户这两个步骤。假如仍是使用终究统一性计划的话，有可能泛起用户积分扣除而折扣券还未生成的状况，此时用户进入账户发现积分没有了，也没有折扣券，就会马上投诉。
那怎么办呢？间接将后面的步骤回滚，并告诉用户处置失败请持续重试便可，这就是实时统一性。
针对以上两种状况，详细解决计划是甚么呢？上面一同来看看。
终究统一性计划
关于数据要求终究统一性的场景，完成思绪是这样的。
1）每个步骤实现后，出产一条动静给MQ，告诉下一步处置接上去的数据。
2）消费者收到这条动静，将数据处置实现后，与步骤1）同样触发下一步。
3）消费者收到这条动静后，假如数据处置失败，这条动静应该保存，直到消费者下次重试。
将3个办事的全部调用流程走上去，逻辑仍是对比繁杂的，总体流程如图13-2所示。


? 图13-2 办事调用流程
具体的完成逻辑如下。
1）调用端调用Service A。
2）Service A将数据库中的a1改成a2。
3）Service A生成一条步骤2（暂且命名为Step2）的动静给MQ。
4）Service A前往胜利信息给调用端。
5）Service B监听Step2的动静，获取一条动静。
6）Service B将数据库中的b1改成b2。
7）Service B生成一条步骤3（暂且命名为Step3）的动静给MQ。
8）Service B将Step2的动静设置为已消费。
9）Service C监听Step3的动静，获取一条动静。
10）Service C将数据库中的c1改成c2。
十一）Service C将Step3的动静设置为已消费。
接上去要斟酌，假如每个步骤失败了该怎么办？
1）调用端调用Service A。
解决计划：间接前往失败信息给用户，用户数据不受影响。
2）Service A将数据库中的a1改成a2。
解决计划：假如这一步失败，就利用当地事务数据间接回滚，用户数据不受影响。
3）Service A生成一条步骤2）（Step2）的动静给MQ。
解决计划：假如这一步失败，就利用当地事务数据将步骤2）间接回滚，用户数据不受影响。
4）Service A前往胜利信息给调用端。
解决计划：不必处置。
5）Service B监听Step2的动静，获取一条动静。
解决计划：假如这一步失败，MQ有对应机制，无须耽心。
6）Service B将数据库中的b1改成b2。
解决计划：假如这一步失败，则利用当地事务间接将数据回滚，再利用动静重试的特性从新回到步骤5）。
7）Service B生成一条步骤3）（Step3）的动静给MQ。
解决计划：假如这一步失败，MQ有出产动静失败重试机制。若泛起极端状况，办事器会间接解体，由于Step2的动静尚无消费，MQ会有重试机制，而后找另外一个消费者从新从步骤5）履行。
8）Service B将Step2的动静设置为已消费。
解决计划：假如这一步失败，MQ会有重试机制，找另外一个消费者从新从步骤5）履行。
9）Service C监听Step3的动静，获取一条动静。
解决计划：参考步骤5）的解决计划。
10）Service C将数据库中的c1改成c2。
解决计划：参考步骤6）的解决计划。
十一）Service C将Step3的动静设置为已消费。
解决计划：参考步骤8）的解决计划。
以上就是终究统一性的解决计划，这个计划还有两个问题。
1）由于利用了MQ的重试机制，所以有可能泛起步骤6）和步骤10）反复履行的状况，此时该怎么办？好比，下面流程中的步骤8）假如失败了，就会从步骤5）从新履行，这时候就会泛起步骤6）履行两遍的状况。为此，在上游（步骤6）和步骤10））更新数据时，需求包管业务代码的幂等性（对于幂等性，在第1章提过）。
2）假如每个业务流程都需求这样处置，岂不是需求额定写得多代码？那是不是能够将相似流程的反复代码抽掏出来？谜底是能够，这里使用的MQ相干逻辑在其余业务流程中也通用，这个名目终究就是将这些代码抽掏出来并进行了封装。由于反复代码抽取的办法对比简略，这里就不展开了。
实时统一性计划
实时统一性其实就是常说的散布式事务。
MySQL其实有一个两阶段提交的散布式事务计划MySQL XA，然而该计划存在重大的机能问题。好比，一个数据库的事务与多个数据库间的XA事务机能可能相差10倍。此外，XA的事务处置进程会长时间占用锁资源，所以名目组一开始就没有斟酌这个计划。
而过后对比盛行的计划是使用TCC模式，上面简略引见一下。
TCC模式
在TCC模式中，会把原来的一个接口分为Try接口、Confirm接口、Cancel接口。
1）Try接口：用来反省数据、预留业务资源。
2）Confirm接口：用来确认实际业务操作、更新业务资源。
3）Cancel接口：是指释放Try接口中预留的资源。
好比在积分兑换折扣券的例子中，需求调用账户办事减积分（步骤1）、营销办事加折扣券（步骤2）这两个办事，那末针对账户办事减积分这个接口，需求写3个办法，代码如下所示。


一样，针对营销办事加折扣券这个接口，也需求写3个办法，然后调用的大体步骤如图13-3所示。


? 图13-3 账户和营销办事TCC处置流程
图13-3中，除Cancel步骤之外的步骤，代表胜利的调用门路，假如两头犯错，则去调用相干办事的回退（Rollback）办法进行手工回退。该计划原来只需求在每个办事中写一段业务代码，而当初需求分红3段来写，并且还波及一些留意事项。
1）需求包管每个办事的Try办法履行胜利后，Confirm办法在业务逻辑上可以履行胜利。
2）可能会泛起Try办法履行失败而Cancel被触发的状况，此时需求包管正确回滚。
3）可能由于网络拥挤而泛起Try办法调用被梗塞的状况，此时势务管制器判别Try失败并触发了Cancel办法，之后Try办法的调用申请到了办事这里，应该回绝Try申请逻辑。
4）一切的Try、Confirm、Cancel都需求确保幂等性。
5）全部事务期间的数据库数据处于一个暂时的形态，其余申请需求拜候这些数据时，需求斟酌如何正确被其余申请使用，而这类使用包罗读取和并发的修正。
所以，TCC模式是一个实行起来很费事的计划，除了每个业务代码的任务量乘3以外，还需求经过相应逻辑应答下面的留意事项，这样犯错的几率就过高了。
起初，笔者在一篇引见Seata的文章中理解到AT模式也能解决这个问题。
Seata中AT模式的自动回滚
自动回滚关于使用Seata的人来讲操作对比简略，只需求在触发全部事务的业务发动方的办法中参加@GlobalTransactional标注，而且使用普通的@Transactional包装好散布式事务中相干办事的相干办法便可。
关于Seata的外在机制，AT模式的自动回滚往往需求履行下列步骤（分为3个阶段）。
阶段1
1）解析每个办事办法履行的SQL，记载SQL的类型（Update、Insert或Delete），修正表并更新SQL前提等信息。
2）按照后面的前提信息生成查问语句，并记载修正前的数据镜像。
3）履行业务的SQL。4）记载修正后的数据镜像。
5）拔出曾经回滚日志：把先后镜像数据及业务SQL相干的信息组成一条回滚日志记载，拔出曾经UNDOLOG表中。
6）提交前，向TC注册分支，并请求相干修正数据行的全局锁。
7）当地事务提交：业务数据的更新与后面步骤生成的UNDOLOG一并提交。
8）将当地事务提交的后果上报给事务管制器。
阶段2
收到事务管制器的分支回滚申请后，开启一个当地事务，履行如下操作。
1）查找相应的UNDOLOG记载。
2）数据校验：将UNDOLOG中的后镜像数据与以后数据进行比较，假如存在不同，阐明数据被以后全局事务以外的举措做了修正，此时需求按照配置战略进行处置。
3）按照UNDOLOG中的前镜像数据和业务SQL的相干信息生成回滚语句并履行。
4）提交当地事务，并把当地事务的履行后果（即分支事务回滚的后果）上报事务管制器。
阶段3
1）收到事务管制器的分支提交申请后，将申请放入一个异步工作队列
中，并马上前往提交胜利的后果给事务管制器。
2）异步工作阶段的分支提交申请将异步、批量地删除相应的UNDOLOG记载。
以上就是Seata AT模式的简略引见。
尝试Seata
过后，虽然Seata尚无更新到1.0，且民间也不保举线上使用，然而名目组终究仍是使用了它，缘故如下。
1）由于实时统一性的场景很少，并且产生频率低，所以其实不会大范围使用，影响面在可控规模内。假如实时统一性的场景产生频率高，并发量就高，业务人员对机能的要求也高，此时就会与业务沟通，采取终究统一性的计划。
2）Seata AT模式与TCC模式比拟，只要减少一个@GlobalTransactional的任务量，因此二者的任务量相差得多，也就是说，对名目组来讲，投入产出比更高，值得冒险。这可能也是Seata开展很快的缘故之一。
虽然Seata AT模式有些小缺点，然而白璧微瑕。
小结
终究统一性与实时统一性的解决计划设计实现后，不只没有给业务开发人员带来额定任务量，也没有影响业务名目进度的日常推动，还大大增加了数据纷歧致的泛起几率，因此数据纷歧致的痛点失掉了较大减缓。
接上去讲另外一个痛点：某个办事需求依赖其余办事的数据，所以需求额定编写得多业务逻辑，这类问题该如何解决？
本文给大家讲授的内容是微办事进阶场景实战：数据统一性
下篇文章给大家讲授的内容是微办事进阶场景实战：数据同步感觉文章不错的敌人能够转发此文关注小编；感激大家的反对！