分布式事务解决方案

分布式事务解决方案

1.背景

比如微信零钱要向零钱通转1w，要怎么做？微信零钱扣1w，微信零钱通加1k，如何保证数据一致性？在单个数据库的情况下，我们可以保证ACID使用数据库本地事务解决。

但是这很明显是两个服务，每个微服务独占一个数据库实例。我们需要跨多个服务保证数据一致性。

2. 解决方案

当微信零钱扣除1w后，我们只需要生成一个凭证（消息），这个凭证上写着“让零钱通账户增加1w”，只要这个凭证（消息）能可靠保存，我们最终是可以拿着这个凭证（消息）让零钱通账户增加1万的，即我们能依靠这个凭证（消息）完成最终一致性。

2.1 前提–尽最大努力交付

之前想过，比如购物时，使用微信支付，购物服务怎么知道微信支付成功了？其实也挺简单的，我们一般会在微信支付的回调页面和接口里，解密参数，调用系统中更新交易状态相关的服务，将订单更新为付款成功。那假如用户在支付后立马关闭app或者网页，导致回调信息收不到怎么办？其实微信支付那边也有个订单状态，已支付已完成，已支付未完成。当是未完成状态，它会过一段时间重试，直到购物服务返回成功。

2.2 本地消息表(交易流水表)

微信在完成扣款的同时，同时记录消息数据(交易流水表)，这个消息数据与业务数据保存在同一数据库实例中。这样能通过本地事务保证只要扣了钱消息一定能保存下来。

BEGIN TRANSACTION
    UPDATE A SET amount = amount - 10000 WHERE user_id = 1;
    INSERT INTO msg(user_id, amount, status) VALUES(1, 10000, 1);
END TRANSACTION
COMMIT;

事务提交后，我们则想办法将此消息通知微信零钱通，零钱通处理成功后会回复成功消息，微信零钱收到回复后就删除该条消息数据。可以用一个轮询服务来定期轮询消息表中未完成的订单（pull拉的模型），然后调零钱通接口也可以丢消息队列，零钱通自行拿出消费，执行本地事务。

这里有个问题就是如果pull得太猛了，对DB有一定的压力，pull频次低了，延迟又会比较高。而且这使得消息数据和业务数据耦合在一起，从架构上来看不够优雅，也容易引起其他问题。有些业务场景可以直接使用主表，或者是自带这类
message 表，比如订单或者交易流水，可以直接使用这类流水表作为 message 表使用。用canal订阅，就是实时流式消费数据。在消费者balance或者balance-job必须努力送达到。

2.3 幂等问题

假如有个订单消息被发送到kafka中，微信零钱通已经消费，并且本地事务提交了，kafka消息还未ack，kafka就挂掉了，那kafka重启之后必然会造成重复消费，而如果微信零钱通取到消息就ack掉，那又可能会造成消息丢失，因为拿到消息后进程挂掉，本地事务提交失败了。也有可能零钱通消费完，也ack了，然而给微信零钱回包的过程中，微信零钱挂了，那本地消息表的数据就没被删除了，又重新发了这条消息。这样都会必然导致零钱通重复消费。所以零钱通这里可以做一个全局唯一ID去重表，也就是一个账本记录消费情况。每次在执行本地事务之前，先去查去重表中是否存在这个订单ID，存在就说明之前消费过，不执行。不存在就执行，同时插入去重表中。

for each msg in queue
	Begin transaction
		select count(*) as cnt from message_apply where msg_id = msg.msg_id;
		if cnt == 0 then
			update B set amount = amount+10000 where userId = 1;
			insert into message_apply (msg_id) values (msg.msg_id);
	End transaction
	commit;

3. 分布式事务–2PC

以上提供的分布式事务解决方案是不是过于繁琐了，那么有没有方案能简化上述的过程？让我们来了解一下2PC。

3.1 理论

两阶段提交协议涉及到两种角色：

• 一个事务协调者（coordinator）：负责协调多个参与者进行事务投票及提交(回滚)
• 多个事务参与者（participants）：即本地事务执行者

总共处理步骤有两个：

1. 投票阶段（voting phase）：协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。参与者将告知协调者自己的决策：同意（事务参与者本地事务执行成功，但未提交）或取消（本地事务执行故障）；
2. 提交阶段（commit phase）：收到参与者的通知后，协调者再向参与者发出通知，根据反馈情况决定各参与者是否要提交还是回滚；

3.2 案例 --2PC Message Queue(RocketMQ集群)

1. 生产者发送perpared消息；
2. MQ确认并回调本地事务；
3. 生产者执行本地事务；
4. 生产者发送确认消息(成功消息)
5. **--------------以上如果任一流程失败，都无影响，MQ不需要管。**只需要考虑，如果本地事务执行成功，但是发送确认失败。这种情况下，生产者端可以弄一个服务定期扫本地事务执行结果表，看其中有没有执行成功但是未处理的数据(根据消息队列的rsp判断。如果网络瞬时抖动，导致重复发消息，所以消费者要做幂等处理)，而后重新发送确认消息。
6. 消费者端接收消息；
7. 幂等执行本地事务；
8. 本地事务执行成功发送确认消息确认成功。

4. 分布式事务-- 面向应用层的TCC

4.1 理论

TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。TCC的整个过程由两类角色参与，一类是事务管理器，只能有一个。另一类是事务参与者，也就是具体的业务服务，可以是多个，而每个服务都得提供Try、Confirm、Cancel 三个操作。

4.2 TCC执行过程

比如小明的银行卡在北京的网点开户，而小红的银行卡是在上海出差时办理的，所以两人的账户分别在单元 A 和单元 B 上。现在小明的账户余额是 4,900 元，要给小红转账 2,000元，一个正常流程是这样的：

但是很不幸，小红账户是无法接收转账的非法账户，处理过程就变成下面的样子：

4.3 TCC需要注意的问题

• 空回滚
  事务管理器在没有调用Try方法的情况下，调用了二阶段的Cancel方法，Cancel方法需要识别出这是一个空回滚，然后直接返回成功。
  **原因：**当一个分支事务所在服务器宕机或者网络异常，分支事务调用记录为失败，这时其实是没有执行Try阶段的。当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
  **解决方案：**增加一张分支事务记录表，其中有全局事务ID和分支事务ID，第一阶段Try方法里插入一条记录，表示一阶段执行了。Cancel接口里读取该记录，如果存在，则正常回滚。如果不存在，则是空回滚。
• 幂等
  为了保证TCC二阶段提交重试机制不会引发数据不一致，要求TCC的二阶段提交Try、Confirm和Cancel接口保证幂等。
• 悬挂
  悬挂就是对于一个分布式事务，其二阶段提交Cancel接口比Try接口先执行。
  **原因：**事务管理器调用分支事务的Try方法，此时网络顺时抖动导致超时，那么事务管理器就会让分支事务执行回滚。可能回滚完成了，Try才到达了分支事务所处的服务器。而这一个Try方法预留的业务资源，只有该分布式事务才能使用，而不会再有第二阶段的Confirm和Cancel，这就导致了悬挂。
  **解决方案：**如果二阶段执行完成，那一阶段就不能再执行，可以在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中已经有了二阶段事务记录。