分布式事物 TCC模式见解

       随着互联网浪潮不断向前推进，企业不得不面对大规模的互联网请求，在当今的互联网发展中，新兴起的微服务架构的模式不断被创新和应用，而在微服务基础当中，事物问题尤为突出，不能解决事物的问题，那么整个微服务都是虚谈，根本无从说起，本篇文章主要讲解个人对于微服务中分布式事物TCC的见解。

       首先，所谓的TCC， Try Confirm Cancel，分别对应着确认一个事物完成的简单三个过程，尝试做某件事、确认做某件事、补充的取消做某件事，因为在分布式的事物当中，可能完成一件事情的过程由多个应用一起来完成，那么传统的单机性质的数据库事物已经不能支持多个应用，或者说完成这件事情所涉及的表由多个数据库组成，那么为了保证一致性、原子性，需要将这件事情进行分解，然后再组合起来的方式来共同完成。那么跟TCC相对于的一些其他的解决性方案还有：可靠事件模式(事件的发送和接收保障高可靠性来实现事物一致性)、补偿模式(如果确认失败，全部逆向取消)。

   TCC，仔细观察，其由三部曲组成，回想一下数据库的三部曲：DML、Commit、rollback.这之间是有异曲同工之妙的，try的操作能够必须要能够保证后面的commit以及rollback没有问题，也就是try必须执行成功才能执行后续操作，字面意思即是要使得相对应的资源必须可用，并且锁住，然后才有后续的comfirm，comfirm的操作需要有其他的事件来通知，执行confirm操作，相对应的，假如confirm失败，就需要rollback操作，操作的内容与try相反，但是实际的业务的时候，可能会有稍微区别，只要是释放资源以及做其他的相关通知等。

   TCC操作事情：

   1、Try：尝试执行业务。

• 完成所有业务检查(一致性)
• 预留必须业务资源(准隔离性)

    2、Confirm：确认执行业务。

• 真正执行业务
• 不做任何业务检查
• 只使用Try阶段预留的业务资源

   3、Cancel：取消执行业务

• 释放Try阶段预留的业务资源
• 其他事件消息等通知

   TCC操作举例：

   一般系统中执行的积分扣除功能，因为积分扣除这项操作的发起可能是第三方的应用，与积分管理这个服务不在在应用内，为了使得事物一致性，可以使用TCC模式处理。

     1、Try：尝试扣除用户积分，扣除前必须对各项相关数据等做校验，发现不合法的则直接退出，不执行后续操作。这步骤必须保证用户有足够的积分并且可以先扣除，假如后面取消执行业务，可以补回来，但是更多情况是往正常扣除的方向走的。这一点确定了积分扣除记录可以写了。

     2.确认执行业务。在收到另外应用通知，发起扣除的应用业务已经执行完毕，比如积分抽奖或者兑换，收到消息确认没有问题，可以正常扣除积分，因为在try操作上已经真实扣除了积分，这个时候就不用再处理了，只是处理一些事务遗留的一些其他的处理，比如这个事物中一些状态的确认等。

    3.取消执行业务。假如收到第三方应用通知，取消执行业务，那么则需要执行针对try步骤中的事情做回滚，这里不建议删除try的操作，而是执行新增补充的记录来弥补，这个操作需要根据实际的业务来分析，这里只是简单说一下，因为不同业务的回滚操作和性质不一样。在处理完成try步骤的回滚后，后续其他消息的通知也是在这个步骤，比如告知用户操作失败等。

   4.在执行完成上面三个步骤后，其他还是有一定漏洞的，漏洞的引起是因为一些不确定或者系统的性能等引起的，为了保障TCC能够完整无缺，需要做一些其他弥补操作；首先是消息的通知，第三方应用与积分扣除进行了业务隔离，通过消息机制的话，消息有可能丢失，或者网络等原因通知不到位，会导致各种情况，这就要求TCC操作的完整性要好，而一些其他因素会破坏完整性，因此必须做一些弥补确认性的事情，使得完成性出现问题的时候，能够系统自动处理或者人为及时处理。这一步的操作根据不同企业的系统框架使用不一样的处理模式，而且与业务有关系，这里就不再描述。