核心关注点：

1 二阶段消息丢了

2 二阶段提交部分自己崩了

问：账户系统里，为什么要tcc

二阶段锁定资源，tcc预留资源

订单和资金，支付宝是mq最终一致性，具体怎么对账的？

悬挂和空会滚具体怎么做，try未执行cancel已触发的场景，弄张本地表记录状态，同时cover幂等

问：如果二阶段消息丢了，或二阶段confirm异常了怎么办？

指数退避重试，只针对网络和服务问题，不针对业务异常

confirm及cancel要幂等，具体怎么做

事务状态记录，怎么做？用个本地表一起提交？

恢复，应对崩溃或重启，对于未完成的事务或正在重试的，具体怎么做

协调者发confirm-》参与者，参与者搞定后-〉ack，协调者没有收到ack则继续发送confirm消息

协调者自身奔溃，弄张本地表记录状态和参与者状态，长时间pending的事务告警

重试/幂等/状态可观测/监控/要有人工介入通道

问：如果都重试了，还要tcc干嘛，直接调接口重试不行吗

资源锁定方式不同，重试直接操作资金所有权，立即生效，回滚可能受阻；乐观，先做了再说

其他都瞎扯

问：你用tcc第二阶段多次重试失败怎么办，不也是重试

定期扫描未完成的事务，无论是协调者还是参与者，都有个本地表记录状态

个性化重试，网络抖动/服务不可用       业务逻辑错误

事务超时，触发cancel（try阶段）标记为异常（confirm/cancel阶段）

人工干预接口，要快捷方便直观及时

tcc至少保证数据不错，如果confirm/cancel失败，也就是一直冻结罢了

修复成本

支付宝早期，直接调用+重试，每天需要很多人对账人工补偿

问：你说的这些，手动接口调用重试不也能解决

人工干预时，只需要关心抽象出来的事务状态，不需要关心复杂的个性的补偿逻辑；tcc confirm失败后，只需要回答一个问题，这个事务是确认还是取消；操作标准化

tcc的重试从“业务操作”抽象为“状态转换”

问：第一个问题，你用tcc一样不一致

业务逻辑不一致vs状态机不一致，后者显然成本低

追求可管理的不一致；不是消除不一致，而是标准化不一致处理流程

不一致是CAP必然结果

tcc有标准修复流程，甚至人工干预控制台，不需要定制干预

可审计/可监控/可解释/可快速标准化修复

tcc让不一致变得可见/可管/可直接无脑修

问：tcc为什么要冻结而不是直接扣款

至此，我们已经可以感受到tcc里的隔离思想，高异常代码在try，二阶段只留低异常代码（尽可能简单），尽量让二阶段只面对数据库断网抖动这种重试可覆盖的异常

语义与tcc的‘预留’相符合

冻结创造了安全区

提供给回滚更广阔的安全空间

现实世界丰满的冻结的例子，tcc在现实世界的映射

　　股票交易，下单-》冻结-〉成交-》扣款，撤单-〉解冻

　　电商，下单-》冻结库存-〉支付成功-》扣减库存，不想买了-〉释放冻结库存

冻结有容易有更丰富的记录，可观测性更强

用户知情，用户能看到冻结状态，而不是没了

问：解冻也有可能异常

重试➕人工

即使解冻失败，资金也没有丢失（消失），即使最坏的情况下，重试100遍失败，钱也没丢；丢失vs冻结悬挂，至少没丢

直接扣款异常更严重

资金所有权没有改变，知识被临时限制

从用户心理角度：钱还在，等会就能用了，可以接受 vs 钱没了，草

从运维心理角度：冻结中-》强制解冻，去点一下 vs 资金对不上了，麻烦了，修复难度高

从财务角度：可审计 vs 难以追踪

三个一定原则

　　网络一定不可靠

　　服务一定会当机

　　异常一定会发生

总结：tcc赋能最优的标准化的可控，可靠性本质上与普通重试无异

起先；然后

有点像zz书