消息队列之事务消息，RocketMQ 和 Kafka是如何做的？

傷城~ 2024-04-08 08:45 44阅读 0赞

今天我们来谈一谈消息队列的事务消息，一说起事务相信大家都不陌生，脑海里蹦出来的就是 ACID。

通常我们理解的事务就是为了一些更新操作要么都成功，要么都失败，不会有中间状态的产生，而 ACID 是一个严格的事务实现的定义，不过在单体系统时候一般都不会严格的遵循 ACID 的约束来实现事务，更别说分布式系统了。

分布式系统往往只能妥协到最终一致性，保证数据最终的完整性和一致性，主要原因就是实力不允许...因为可用性为王。

而且要保证完全版的事务实现代价很大，你想想要维护这么多系统的数据，不允许有中间状态数据可以被读取，所有的操作必须不可分割，这意味着一个事务的执行是阻塞的，资源是被长时间锁定的。

在高并发情况下资源被长时间的占用，就是致命的伤害，举一个有味道的例子，如厕高峰期，好了懂得都懂。

![46c0a7f3902f5a7e391e867f9a8ffb07.png][]

对了， ACID 是什么还不太清楚的同学，赶紧去查一查，这里我就不展开说了。

### 分布式事务 ###

那说到分布式事务，常见的有 2PC、TCC 和事务消息，这篇文章重点就是事务消息，不过 2PC 和 TCC 我稍微提一下。

### 2PC ###

2PC 就是二阶段提交，分别有协调者和参与者两个角色，二阶段分别是准备阶段和提交阶段。

准备阶段就是协调者向各参与者发送准备命令，这个阶段参与者除了事务的提交啥都做了，而提交阶段就是协调者看看各个参与者准备阶段都 o 不 ok，如果有 ok 那么就向各个参与者发送提交命令，如果有一个不 ok 那么就发送回滚命令。

这里的重点就是 2PC 只适用于数据库层面的事务，什么意思呢？就是你想在数据库里面写一条数据同时又要上传一张图片，这两个操作 2PC 无法保证两个操作满足事务的约束。

而且 2PC 是一种强一致性的分布式事务，它是同步阻塞的，即在接收到提交或回滚命令之前，所有参与者都是互相等待，特别是执行完准备阶段的时候，此时的资源都是锁定的状态，假如有一个参与者卡了很久，其他参与者都得等它，产生长时间资源锁定状态下的阻塞。

总体而言效率低，并且存在单点故障问题，协调者是就是那个单点，并且在极端条件下存在数据不一致的风险，例如某个参与者未收到提交命令，此时宕机了，恢复之后数据是回滚的，而其他参与者其实都已经执行了提交事务的命令了。

### TCC ###

TCC 能保证业务层面的事务，也就是说它不仅仅是数据库层面，上面的上传图片这种操作它也能做。

TCC 分为三个阶段 try - confirm - cancel，简单的说就是每个业务都需要有这三个方法，先都执行 try 方法，这一阶段不会做真正的业务操作，只是先占个坑，什么意思呢？比如打算加 10 个积分，那先在预添加字段加上这 10 积分，这个时候用户账上的积分其实是没有增加的。

然后如果都 try 成功了那么就执行 confirm 方法，大家都来做真正的业务操作，如果有一个 try 失败了那么大家都执行 cancel 操作，来撤回刚才的修改。

可以看到 TCC 其实对业务的耦合性很大，因为业务上需要做一定的改造才能完成这三个方法，这其实就是 TCC 的缺点，并且 confirm 和 cancel 操作要注意幂等࿰

[46c0a7f3902f5a7e391e867f9a8ffb07.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/782a740f7e654c4fbf297afc0a8c1960.png

还没有评论，来说两句吧...