Hmily

引言 在上篇文章 《老生常谈——利用消息队列处理分布式事务》 一文中留了一个坑，今天来填坑。如下图所示 如果服务A和服务B之间是同步调用，比如服务C需要按流程调服务A和服务B，服务A和服务B要么一起成功，要么一起失败。 针对这种情况，目前业内普遍推荐使用TCC事务来解决的！ 正文 ok,老规矩，我们先套一个业务场景进去，如下图所示 那页面点了支付按钮，调用支付服务，那我们后台要实现下面三个步骤 [1] 订单服务-修改订单状态 [2] 账户服务-扣减金钱 [3] 库存服务-扣减库存 达到事务的效果，要么一起成功，要么一起失败！就要采取TCC分布式事务方案！ 概念 TCC的全称是（Try-Confirm-Cancel）。如下图所示 <font color="blue">ps:TCC又可以被称为两阶段补偿事务，第一阶段try只是预留资源，第二阶段要明确的告诉服务提供者，这个资源你到底要不要，对应第二阶段的confirm/cancel，用来清除第一阶段的影响，所以叫补偿型事务。</font> 再打个比方，说TCC太高大上是吧，讲RM中的prepare、commit、rollback接口，总知道吧。可以类比的这么理解 那差别在哪呢? rollback、commit、prepare，站在开发者层面是感知不到的，数据库帮你做了资源的操作! 而try、confirm、cancel

TCC介绍 TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出，在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。 正式以Try-Confirm-Cancel作为名称的是Atomikos公司。 认识TCC TCC区别于 XA事务 ，是一种用于分布式系统中跨服务的事务管理模型；此模型通过管理服务，而不是资源管理器实现。 TCC是一种补偿型事务，也是一种柔性事务（存在中间态），该模型要求应用服务提供 try、confirm、cancel 三个接口，分别对应资源预留、操作确认、操作取消业务逻辑。 在TCC模型中，如果事务可以提交，则完成对预留资源的确认（调用confirm），如果事务要回滚，则释放预留的资源（调用cancel）。 TCC中try、confirm、cancel接口需要考虑幂等。 TCC区别于XA模型以及JAVA中的JTA接口，主要依赖业务代码实现；不用考虑框架、资源管理器、通信协议的支持和规范。 TCC与XA对比 TCC中对资源的锁是基于业务代码实现（这里的锁意思就是try接口中的预留动作），而XA基于数据库的序列化隔离级别实现。 TCC可以解决XA中单点以及并发的问题

微服务越来越火。很多互联网公司，甚至一些传统行业的系统都采用了微服务架构。体会到微服务带来好处的同时，很多公司也明显感受到微服务化带来的一系列让人头疼的问题。本文是笔者对自己多年微服务化经历的总结。 如果你正准备做微服务转型，或者在微服务化过程中遇到了困难，此文很可能会帮到你！ 写在前面 正文开始前，为了让各位读友更好的理解本文内容，先花两分钟了解一下微服务的优缺点。 微服务的好处 聊起微服务，很多朋友都了解微服务带来的好处，罗列几点： 模块化，降低耦合 将单体应用按业务模块拆分成多个服务，如果某个功能需要改动，大多数情况，我们只需要弄清楚并改动对应的服务即可。只改动一小部分就能满足要求，降低了其他业务模块受影响的可能性。从而降低了业务模块间的耦合性。 屏蔽与自身业务无关技术细节 例如，很多业务需要查询用户信息，在单体应用的情况下，所有业务场景都通过 DAO 去查询用户信息，随着业务发展，并发量增加，用户信息需要加缓存，这样所有业务场景都需要关注缓存，微服务化之后，缓存由各自服务维护，其他服务调用相关服务即可，不需要关注类似的缓存问题。 数据隔离，避免不同业务模块间的数据耦合 不同的服务对应不同数据库表，服务之间通过服务调用的方式来获取数据。 业务边界清晰，代码边界清晰 单体架构中不同的业务，代码耦合严重，随着业务量增长，业务复杂后，一个小功能点的修改就可能影响到其他业务点

分布式事务模型 TCC 模型：TCC-Transaction、Hmily XA 模型：Sharding Sphere、MyCAT 2PC 模型：raincat、lcn MQ 模型：RocketMQ BED 模型：Sharding Sphere Saga 模型：ServiceComb Saga TCC TCC事务解决方案本质上是一种补偿的思路，它把事务运行过程分成try、confirm/cancel 两个阶段，每个阶段都由业务代码来控制。需要注意的是，TCC事务和2pc的思想类似，但与2pc实现不同，TCC不再是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑。 实现过程： try：完成所有业务检查（一致性），预留业务资源。 confirm：确认执行业务操作，只使用try阶段预留的业务资源。 cancel：取消try阶段预留的业务资源。 XA模型（规范） xa是个规范，根据这个思想衍生二阶段提交协议和三阶段提交协议。 XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。 资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。 事务管理器