分布式事务学习笔记「一」｜周末学习

文章正文第一句：「本文已参与 周末学习计划，点击查看详情 」

本文是在学习毛老师，分布式事务中所做的笔记。

单体下，单个服务通过操作本地数据库，将多个数据库表的操作封在一个事务里面：

begin transaction;

update a set...;
update b set...;

end transaction
复制代码

单个数据库，通过数据库本身的 ACID 保证事务。

微服务架构下，每个微服务独占一个数据库，一个操作跨越了多个服务，而且同时调用多个系统的服务很难保证成功，这就是跨服务分布式事务的问题。

通过事务消息解决分布式事务问题。「牺牲了一致性，提高了并发量」

如何可靠地保存消息凭证？

• Transactional outbox
• Polling publisher
• Transaction log tailing【binlog】
• 2PC Message Queue【异构系统】

Transactional outbox

A 完成扣款的同时，记录消息数据。消息数据和业务数据保存在同一个数据库实例里面：

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;
复制代码

在一个事务里面能保证只要支付宝账户里面扣钱，消息就一定可以保存下来。

剩下的事情就是：B 一定要将此消息消费到，然后回复成功消息（回调），紧接着将消息数据删除掉（is_delete=1）。

Polling publisher

Polling publisher，我们定时的轮训 msg 表，把 status = 1 的消息统统拿出来消费，可以按照自增 id 排序，保证顺序消费。

在这里我们独立了一个 pay_task 服务，把拖出来的消息 publish 给我们消息队列，balance 服务自己来消费队列，或者直接 rpc 发送给 balance 服务。

未完待续。。。下篇文章讲讲其他几种处理方式。。。