面试官：RocketMQ 分布式事务消息的缺点？

事情是这样的。

我正躺在床上看《说唱听我的2》，突然微信发来一个消息，我一看是艿艿。

艿艿突然发来这一段，没有上下文，我懵了一下，发生什么事了？

但是，我没有惊慌，以我沉着稳重的人设，淡定地回了个：啊？去哪儿的那个？

但是，艿艿没有理我，紧接着来了一拨输出：

当时，我的脑子里就只有rap：“不是吧不是吧，难道单押也算押，无视他无视他，蓝调专家也算家。”

现在来看这个问题，肯定是 mysql 重要。

因为艿艿强调的是成功，我当时没注意到成功二字，认为事务如果涉及 mysql 和 mq 这两者，那肯定是要重点关注 mq ，因为 mysql 对事务是有保障的，对于已经稳了的东西，不需要花费太多心思在上面。

所以，在这个错误的认知前提下，下面的讨论就没啥意义，所以就不贴了。

到后面，我也搞懂了艿艿发问的起因，因为艿艿最近做了次 mq 的分享，然后回想起我之前写的那篇文章，他比较推荐 qmq 的事务消息方案，而不是 RocketMQ 的。

因为他之前用过类似的方案，然后当时线上 mq 集群网络故障，导致发消息失败，当时 mysql 虽然还是活着的，但是无法进行事务。

这其实就回到前面抛出的问题了：一个事务涉及 mysql 和 mq，到底哪个写入成功重要？

我翻译一下，其实这个问题讲的是：mysql 和 mq 之间的写入顺序。

在 RocketMQ 中，事务消息的实现方案是先发半消息（半消息对消费者不可见），待半消息发送成功之后，才能执行本地事务，等本地事务执行成功之后，再向 Brok