[分布式事务-TCC] 6. TCC的优化方案之三:二阶段异步化
Posted dm_vincent
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[分布式事务-TCC] 6. TCC的优化方案之三:二阶段异步化相关的知识,希望对你有一定的参考价值。
二阶段异步化
采用TCC模型实现分布式事务之后,分布式事务所需的资源也是按照业务的维护进行切分,每笔分布式事务之间的资源都是独立预留和消费。
单说这些可能有点难理解举个栗子就很容易理解了,账户A同时参与了两笔分布式事务,一笔是转账50元到账户B;另一笔是转账100元到账户C。
那么每笔分布式事务都会各自预留所需的资源,它们感知不到彼此的存在,也不会互相干扰。这里顺便复习一下实现TCC模型的一个关键点:业务模型的重构。
对于转账这个场景而言,是通过将原账户的余额字段一拆为三来实现的:
- 可用余额
- 未达金额
- 未出金额(预留资源)
优化方案都是依托于系统的运行时和业务的实际需要。在转账这个业务场景下,数据不一致的时间是很短的,当我们转账的时候,我们也是希望这笔交易能够在很短的时间内完成,否则我们肯定会认为银行不靠谱,进而产生很大的不安全感。所以,业务上就决定了转账对RT的要求很高,一阶段执行完了二阶段马上就要执行。
但是天底下的业务场景何其多,不是所有业务都需要这么极端的RT保证。
一笔交易的链路其实是很长的,收单只是万里长征第一步,后面还涉及到计收费,结算等各个环节。收了买家的钱,需要将这笔钱打到卖家的账户上。但是在现实中,卖家一般都不会实时地就能够收到这笔钱,而是通过记账的方式记录下来这笔收入,保证可以准实时地看到这笔交易出现在账单中,然后根据和收单服务方约定的结算周期(比如周,半月,月等)完成结算。
所以对结算这个业务场景,TCC一阶段执行成功后,二阶段并不一定需要马上就执行。
再举个例子,在双十一这类短时间并发量井喷到极致的时候,即使对服务集群做了最大程度的扩容,也会将能够延迟执行的任务全部延迟,来保证主要核心功能和链路的稳定性和吞吐量。
因此,二阶段的异步化是有其存在之必要和用武之地的。
有了TCC模型对于数据最终一致性的保证,只要一阶段处理成功,那么二阶段是立即,还是几小时后,甚至一个月之后执行其实都没有本质的区别。因为资源已经在一阶段中被锁定和预留了,这个资源只有在对应的二阶段才能够继续被消费。
基于这个前提,就出现了实现最终一致性的各种异步化方案。比如所谓的事务性消息服务(也被成为可靠的消息服务),这里简单介绍一下:
它能够保证两件事情:
- 消息发送端的本地事务业务逻辑与真正的消息投递是一个原子操作。要么同时成功,要么同时失败。
- 消息投递一定会保证下游消费者能够收到并完成处理。
如何理解?
可以分三个阶段来看这件事:
- 消息发送方在本地事务中执行业务逻辑,发送消息到事务性消息服务,后者收到消息并持久化,但是不会马上投递将这条消息投递到消息队列中
- 站在消息服务的角度,根据发送方的本地事务执行结果:
- 本地事务提交成功,发送CONFIRM指令给事务性消息服务,后者更新之前收到的消息状态为有效,然后再将此消息投递到消息队列中
- 本地事务失败回滚,发送ROLLBACK指令给事务性消息服务,后者更新之前收到的消息状态为无效,然后删除此条消息
- 本地事务结果未知,事务性消息服务需要回查消息发送方咨询消息是可以发送,还是需要删除
- 消息确定可以发送到下游后添加消息到实际MQ,下游消费成功返回ACK,消息服务删除消息,否则等待下次重投,直到下游成功消费此条消息
对于时效性要求没那么高,但是又要保证最终数据一致性的业务场景,使用这种方案是非常理想的。它很好地实现了削峰填谷,让业务平稳运行的运维目标。
当然,事务性消息服务这里只是点到为止。它们本身也是很大的命题,值得花时间单独讨论。
以上是关于[分布式事务-TCC] 6. TCC的优化方案之三:二阶段异步化的主要内容,如果未能解决你的问题,请参考以下文章
[分布式事务-TCC] 6. TCC的优化方案之三:二阶段异步化
[分布式事务-TCC] 4. TCC的优化方案之一:最末参与者优化(LPO)
[分布式事务-TCC] 4. TCC的优化方案之一:最末参与者优化(LPO)
[分布式事务-TCC] 4. TCC的优化方案之一:最末参与者优化(LPO)