tcc

在 关于分布式事务的理解 一文中，最后留了一个坑是关于TCC框架的。当时由于时间问题耽搁了，最近总算有时间把这个坑填上了。 本文会大致介绍下两阶段和三阶段提交，以及TCC模式。 分布式事务分为 两阶段型 补偿型 异步确保型 最大努力通知型几种 上文我们已近介绍了 异步确保型 和 最大努力通知 这两种服务模式的具体应用，接下来介绍下剩下两种。 两阶段提交（2PC）型 两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。 可以进一步将准备阶段分为以下三个步骤： 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。 （注意：若成功这里其实每个参与者已经执行了事务操作） 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功， 则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。 提交阶段 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚

从设计模式上来讲： 其主要区别是是否有预提交的操作，XA有一个预提交的过程，在两阶段提交的过程中，有一个协调者在中间起到很重要的作用，当所有的事务都执行成功，会把执行成功的状态通知协调者，这个阶段是第一阶段，协调者监听到所有的事务执行成功后，执行第二阶段的commit，也就是说XA的两阶段提交是在第二阶段才执行commit 而TCC的不同就在于其在第一阶段就commit了，没有预提交的过程， 从应用上来讲： XA更多应用在单体架构上，而 TCC更多应用在分布式架构上，所以性能上，当并发量不大的时候，XA的性能更高，因为其不需要远程的api调用，但是在高并发场景，TCC优势很大 来源： CSDN 作者： Maxiao1204 链接： https://blog.csdn.net/Maxiao1204/article/details/103618851

这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制: 在事务链中的任何一个正向操作, 都必须存在一个完全符合回滚规则的可逆操作, 这个操作通常叫做rollback或者cancel. CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 为什么CA不行呢? 因为没有P的话, 数据一致性会出现问题, 这是任何一个一致性系统不允许出现的情况. 幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指强一致性事务, 例如单机环境下遵循ACID的数据库事务, 或者分布式环境中的2PC等. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 异步确保型, 最大努力通知型. 最佳实践 先上结论, 再分别介绍分布式事务的各种实现方式. 如果业务场景需要强一致性,

2、TCC 解决分布式事务的方案 落地时 hmily框架。 2.1 TCC 代表了三个阶段 Try Confirm cancel Try 就是 一个方法，这里 是 业务的逻辑，几个逻辑都操纵数据库 比如完成 注册用户，调用 送积分的 远程逻辑 默认 try执行了 confirm一定执行。 Confirm 这里呢 可以理解成 确认提交。 Cancel 就是业务的 回滚，只要try里面有异常 就 走cancel。 2.2 TCC 注意的异常处理情况 1) 空回滚 ：就是 try没有执行 就执行cancel 方法。 2）幂等性 ：一个方法无论调多少次 结果都是一样的 这是幂等性。 3) 悬挂 ；confirm 或者 cancel已经执行了 又要执行 try方法 这是悬挂。 处理的方法是调用 数据库的 逻辑。 hmily需要的数据库表设计。 事务的发起方 try这里需要解决幂等性 和悬挂的问题。 try方法上要加本地事务的注解。 cancel这里需要解决 空回滚和幂等性的问题。 事务的另一方 try这里 啥也不用写逻辑 confirm 这里需要 写 送积分的逻辑。这里即使又异常整个事务也回滚不了 可以人工的处理 。 需要解决幂等性。方法上要加本地事务的注解。 cancel 这里 也啥也不用写。 ##feign 的使用注意事项 @FeignClient(value="tcc-demo

4. 分布式事务解决方案之TCC 4.1. 什么是TCC事务 TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作 ：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。 分支事务失败的情况 ： TCC分为三个阶段 ： Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。 Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即 ：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了

一、 柔性事务的模式：幂等操作、可补偿操作、可查询操作和TCC操作 1、 可查询操作 ：为了保证操作的可查询，需要对于每一个服务的每一次调用都有一个全局唯一的标识，可以是业务单据号（如订单号）、也可以是系统分配的操作流水号（如支付记录流水号）。除此之外，操作的时间信息也要有完整的记录。 2、 幂等操作 ：幂等性，其实是一个数学概念。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。也就是说，同一个方法，使用同样的参数，调用多次产生的业务结果与调用一次产生的业务结果相同。 　　幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。 3、 可补偿操作 ：比如，在调用积分服务给积分帐户增加积分操作执行之后，操作执行之后，经过分布式事务协调，最终决定回滚整个事务，那么就需要提供一个调用积分服务给积分帐户扣减积分的操作。 4、 TCC操作 ：Try-Confirm-Cancel 　　 Try: 尝试执行业务 　　　　完成所有业务检查(一致性) 预留必须业务资源(准隔离性) 　　 Confirm:确认执行业务 　　　　真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作要满足幂等性 　　 Cancel: 取消执行业务 　　　　释放Try阶段预留的业务资源，Cancel操作要满足幂等性

FROM： https://www.cnblogs.com/jajian/p/10014145.html 之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 1 | 0 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 2 | 0 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子

1、2PC协议 　　2PC 是二阶段提交（Two-phase Commit）的缩写，顾名思义，这个协议分两阶段完成。第一个阶段是准备阶段，第二个阶段是提交阶段，准备阶段和提交阶段都是由事务管理器（协调者）发起的，协调的对象是资源管理器（参与者）。二阶段提交协议的概念来自 X/Open 组织提出的分布式事务的规范 XA 协议，协议主要定义了（全局）事务管理器和（局部）资源管理器之间的接口。XA 接口是双向的系统接口，在事务管理器以及一个或多个资源管理器之间形成通信桥梁。Java 平台上的事务规范 JTA（Java Transaction API）提供了对 XA 事务的支持，它要求所有需要被分布式事务管理的资源（由不同厂商实现）都必须实现规定接口（XAResource 中的 prepare、commit 和 rollback 等）。 　　①准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，参与者会写 redo 和 undo 日志，然后锁定资源，执行操作，但是并不提交。 　　②提交阶段：如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者明确返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行 undo

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: I have a simple app running on ios simulator which will (at some point in the app), prompt the user to authorize the following: Location setting Address contact book Pictures/Albums Because I am doing automation testing on the iOS simulator (several thousand on virtual machines), is there a way to force iOS simulator to have these permissions already set to yes when the app is installed? I vaguely remember there was a way to manipulate this using a plist file associated with iOS simulator, but I'm not 100% sure if "its all in my head". I'm