αre是什么意思的中文

tcc是什么意思（TCC的中文含义）

TCC事务的学习和理解前段时间学习了一些TCC事务的原理和应用，下面说说自己的理解。TCC是实现分布式事务的一种方式，可以分为三个阶段:尝试-确认-取消。

基本概念

首先，TCC是英文Try-Confirm-Cancel的缩写。是解决分布式交易的机制，也是支付宝解决灵活交易的解决方案。我第一次看到灵活性这个术语，所以我又看了一下这个概念，大致整理如下:

刚性交易

ACID:原子性、一致性、隔离性、持久性CAP: C(一致性)一致性是指数据的原子性，在经典数据库中由事务来保证。当事务完成时，无论成功或回滚，数据都将处于一致状态。在分布式环境中，一致性是指多个节点的数据是否一致；a(可用性)服务总是可用的。当用户提出请求时，服务可以在一定时间内返回结果；p(分区容忍度)在分布式应用中，系统可能会因为一些分布式的原因而无法工作。良好的分区容忍度使应用程序看起来是一个整体，虽然它是一个分布式系统，但可以正常工作；(数据库事务是刚性事务，严格遵守ACID原则，要求事务一致性强)柔性事务。

BASEBA:基本可用性基本业务可用性；s:软态柔性态；e:最终一致性最终一致性；可以看出，与刚性事务相比，柔性事务不需要很强的一致性，在业务上允许一定程度的延迟和阻塞，但最终是一致的。支付宝在技术上对灵活交易的描述是:

两阶段型-->:参考分布式系统的几个要点，如事务补偿型、异步保证型、尽力通知型，再看事务补偿型TCC事务。

什么是TCC？

与传统的事务机制相比，TCC不依赖于传统的资源管理，而是通过调度业务来实现分布式事务。因此，如果一个业务逻辑想要实现TCC事务控制，它必须实现这三个业务逻辑:

Try:资源预留/锁定 *** 作，是事务发起方调用服务提供方的try方法锁定业务需要的所有资源。确认:确认业务逻辑 *** 作的执行。这里使用的资源必须是Try阶段预留的业务资源。在TCC事务机制中，考虑到如果在try阶段可以正常预留资源，那么确认和取消阶段就可以完整正确地提交。确认阶段也可以看作是尝试阶段的补充，尝试+确认共同构成了一个完整的业务逻辑。我在一篇文章里看到过这样的说法，我觉得很对:TCC机制把传统交易机制中的业务逻辑分成两部分，拆分后保留的部分是前期 *** 作(try)；分离的部分是确认 *** 作，它被延迟到事务提交阶段。取消:取消业务逻辑的执行。但是，这与普通的补偿性事务不同，取消阶段并不真正回滚业务(因为尝试阶段并不真正执行业务)，而是释放以前锁定的资源。我认为这比传统的回滚成本更低。你可以参考之前一篇网上文章中的股票交易的例子:商业交易的实际案例，web服务的补偿和尝试取消/确认(TCC)方法。

网上看了很多案例解释TCC。我根据自己的理解，结合我前段时间做的新项目的交易场景，分析了TCC的可行性。

在汽车新零售项目中，客户通过二级经销商的销售人员，在下车单辆奥迪Q5的过程中，会产生B2C交易订单、B2B采购订单、创建合同、锁定库存等动作，涉及多个服务的调用。

在这个场景中，新零售交易的后台需要调用三个服务:订单服务、合同服务和库存服务。

要学习和理解TCC事务，首先在Try阶段预留资源:调用order服务创建B2C和B2B订单(由于它们在同一个数据库中 *** 作，两个订单的创建在一个数据库事务中实现)，此时的订单处于中间状态(例如，待创建)；调用契约服务来创建B2B和B2C契约。与订单服务一样，创建的合同处于中间状态。库存需要预留车辆，即锁定一个库存。需要注意的是，这里的服务都是分布式的服务调用，所以要特别注意接口的幂等和并发 *** 作。如果成功执行了Try阶段，即成功预留了所有资源，则可以进入确认阶段。服务更新订单状态，并将中间状态更新为已创建待支付(这是一种业务状态)；类似地，服务将合同从中间状态更新为已签署状态；该服务实际上减去了锁定的库存。如果在Try阶段资源预留失败，TCC事务管理器认为全局事务无法正确提交，就会逐个执行预备 *** 作(Try)中指定的取消 *** 作，撤销预备 *** 作(Try)中已经完成的所有项。在实际项目中，我们可能会延迟取消:在尝试阶段预留资源失败后，我们不会立即修改订单、合同和库存状态，而是通过扫描异常订单或调度任务加班处理来达到最终的一致性。例如，在尝试阶段，订单和合同创建成功，达到带创建状态，但库存锁定失败；这意味着你不必马上做cacel *** 作。可以在业务中规定，订单30分钟不进入正常状态，视为 *** 作失败。系统可以通过运行定时任务来扫描这些异常订单，并做出相应的处理(定时补偿机制)。

想

在某种意义上，TCC非常类似于两阶段(2PC)提交。Try类似于prepare，confirm等同于commit，cancel等同于rollback，只不过TCC的两阶段提交是在业务层面(开发者需要根据各自业务的特点实现try-confirm-cancel)，而2PC更多的是用于数据库事务处理，往往与具体业务无关。

最后考虑一个问题，TCC是否适用于所有的业务场景？答案一定是否定的，没有什么解决方案是万能的。

首先，TCC事务机制需要Try confirm cancel3三个接口，因此需要额外的开发资源。其次，由于TCC的关键在于Try阶段的资源预留，当业务复杂度较高时，会产生很多中间状态，预留资源的成本较高，会成倍增加业务复杂度，影响性能。所以在处理分布式事务时，还是要具体情况具体分析。可以根据业务场景选择不同的事务处理机制，也可以混合使用多种机制(2PC、TCC、事务性消息队列、事务补偿等。).毕竟适合自己的才是最好的。

郑重声明:本文版权归原作者所有。转载文章只是为了传播更多的信息。如作者信息标注有误，请第一时间联系我们修改或删除。谢谢你。

转载:感谢您对网站平台的认可，以及对我们原创作品和文章的青睐。非常欢迎大家分享到个人站长或朋友圈，但转载请注明文章来源“蝶芒网”。