文章目录
分布式事务解决方案
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):即本地事务执行者
总共处理步骤有两个:
- 投票阶段(voting phase):协调者将通知事务参与者准备提交或取消事务,然后进入表决过程。参与者将告知协调者自己的决策:同意(事务参与者本地事务执行成功,但未提交)或取消(本地事务执行故障);
- 提交阶段(commit phase):收到参与者的通知后,协调者再向参与者发出通知,根据反馈情况决定各参与者是否要提交还是回滚;
3.2 案例 --2PC Message Queue(RocketMQ集群)
- 生产者发送perpared消息;
- MQ确认并回调本地事务;
- 生产者执行本地事务;
- 生产者发送确认消息(成功消息)
- **--------------以上如果任一流程失败,都无影响,MQ不需要管。**只需要考虑,如果本地事务执行成功,但是发送确认失败。这种情况下,生产者端可以弄一个服务定期扫本地事务执行结果表,看其中有没有执行成功但是未处理的数据(根据消息队列的rsp判断。如果网络瞬时抖动,导致重复发消息,所以消费者要做幂等处理),而后重新发送确认消息。
- 消费者端接收消息;
- 幂等执行本地事务;
- 本地事务执行成功发送确认消息确认成功。
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,这就导致了悬挂。
**解决方案:**如果二阶段执行完成,那一阶段就不能再执行,可以在执行一阶段事务时判断在该全局事务下,“分支事务记录”表中已经有了二阶段事务记录。