认识达内从这里开始

随着微服务架构开发技术的普及，数据库事务也发生了很大的变化，今天我们就通过案例分析来了解一下，分布式事务的概念与应用。

熟悉2PC的您应该大概知道其工作原理，简单来说就是每一个事务参与者在执行完事务后并不提交，死等着事务管理器下令才能做提交操作，在此期间资源只能进行锁定。这种机制放在高并发的系统中其性能之低您都不用看什么数据报告，用脚指头都能想出来。TCC的概念其很简单，我们不进行资源的锁定。现在的问题不就是当某个事务出现问题后无法把其它已经完成的事务进行回滚吗?那我们就在业务代码的层次让每一个事务参与者都实现一些接口。

Try：让事务参与者尝试执行业务，一般使用数据库的事务，执行完成后就提交不做任何等待与锁定。不过由于整个业务并没有完成，所以在“Try”的阶段一般会把数据变成一种中间状态。比如在电商购物的业务中，常见的操作是下单后对库存进行扣减。在使用了TCC后，库存服务的“Try”操作就把库存数减1，冻结的库存数加1，使用“冻结”作为中间态而不是直接对库存进行扣减。“Confirm”：让事务参与者执行业务确认，上例中就是把冻结的库存-1。“Cancel”：当某个事务参与者的“Try”失败后执行回滚操作，上例中就是库存数加1，冻结的库数减1。当然了，原理是这样的，实际在使用TCC的时候有很多的限制，比如“Confirm”操作不能失败，必须支持幂等操作等。

通过对于TCC的解释，相信您能想像得到这个机制其实真的挺麻烦的，各种的协调不说对业务的入侵也比较强(我认为是分布式事务中入侵性强的)。所以您好别自己写代码开搞，这里面需要考虑很多的事情，起码三个场景的来回调度就够您喝一壶了更别提什么比“空回滚”、“悬挂”等问题。这个时代要求快速加载需求就不能总是从头造轮子了。

再说了，这么有名的模式一定有现成的框架可用比如Seata，大厂出品质量还是可以的，但在系统的架构上你需要额外部署一两套Seata服务才能成事;写代码的时候你只需要找个地方把业务进行统一的组织就行了，所有的调度以及上述提及的各类问题都有Seata这个碎催来解决。以上面的案例来说，您只要在比如订单服务的某个方法中对“订单下单的T”和“库存减一的T”进行调用而不用操心另外两个“C”的执行，完全是自动的。这里的“某个方法”有个名称：全局事务发起方法。

既然谈到了Seata框架，里面还有一种AT模式，具体原理您自行网上查找。这东西用起来其实也非常的简单，不过他的事务回滚是基于数据库的，通过拦截SQL生成UndoLog和RedoLog，如果某事务参与者用的是NoSQL，那这种方式就不适合了。而TCC是基于用户逻辑进行事务的提交与回滚，就相对要灵活很多，完全可以针对非关系型数据库做支撑。

还是那句话，强大也是有代价的，TCC对业务的入侵比较重，你得仔细考虑TCC中的每个方法，代码写得多测试也麻烦，不像AT模式加个注解就可以放飞自我了。DDD落地的时候使用AT或TCC其实都行，前提是您已经知道了两种模式在技术上的主要区别。另外，请务必注意在使用DDD的时候把这些框架的应该点放在应用服务层，包括“TCC”各方法的实现。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。