怅然|消息队列之事务消息，RocketMQ 和 Kafka是如何做的？( 四 )
首先RocketMQ的设计就是顺序追加写入 ， 所以说不会更改已经入盘的消息 ， 那事务消息又需要更新反查的次数 ， 超过一定反查失败就判定事务回滚 。
因此每一次要反查的时候就将以前的半消息再入盘一次 ， 并且往前推进消费进度 。 而half_op又会记录每一次反查的结果 ， 不论是提交还是回滚都会记录 ， 因此下一次还循环到处理此半消息的时候 ， 可以从 half_op 得知此事务已经结束了 ， 因此就被过滤掉不需要处理了 。
如果得到的反查的结果是 UNKNOW ， 那 half_op 中也不会记录此结果 ， 因此还能再次反查 ， 并且更新反查次数 。
到现在整个流程已经清晰了 ， 我再画个图总结一下 Broker 的事务处理流程 。
Kafka 事务消息Kafka的事务消息和RocketMQ的事务消息又不一样了 ， RocketMQ解决的是本地事务的执行和发消息这两个动作满足事务的约束 。
而Kafka事务消息则是用在一次事务中需要发送多个消息的情况 ， 保证多个消息之间的事务约束 ， 即多条消息要么都发送成功 ， 要么都发送失败 ， 就像下面代码所演示的 。
Kafka 的事务基本上是配合其幂等机制来实现 Exactly Once 语义的 ， 所以说 Kafka 的事务消息不是我们想的那种事务消息 RocketMQ 的才是 。
讲到这我就想扯一下了 ， 说到这个Exactly Once 其实不太清楚的同学很容易会误解 。
我们知道消息可靠性有三种 ， 分别是最多一次、恰好一次、最少一次 ， 之前在消息队列连环问的文章我已经提到了基本上我们都是用最少一次然后配合消费者端的幂等来实现恰好一次 。
消息恰好被消费一次当然我们所有人追求的 ， 但是之前文章我已经从各方面已经分析过了 ， 基本上难以达到 。
而 Kafka 竟说它能实现 Exactly Once？这么牛啤吗？这其实是 Kafka 的一个噱头 ， 你要说他错 ， 他还真没错 ， 你要说他对但是他实现的 Exactly Once 不是你心中想的那个 Exactly Once 。
它的恰好一次只能存在一种场景 ， 就是从Kafka 作为消息源 ， 然后做了一番操作之后 ， 再写入 Kafka 中 。
那他是如何实现恰好一次的？就是通过幂等 ， 和我们在业务上实现的一样通过一个唯一 Id ，然后记录下来 ， 如果已经记录过了就不写入 ， 这样来保证恰好一次 。
所以说 Kafka 实现的是在特定场景下的恰好一次 ， 不是我们所想的利用 Kafka 来发送消息 ， 那么这条消息只会恰巧被消费一次 。
这其实和 Redis 说他实现事务了一样 ， 也不是我们心想的事务 。
所以开源软件说啥啥特性开发出来了 ， 我们一味的相信 ， 因此其往往都是残血的或者在特殊的场景下才能满足 ， 不要被误导了 ， 不能相信表面上的描述 ， 还得详细的看看文档或者源码 。
不过从另一个角度看也无可厚非 ， 作为一个开源软件肯定是想更多的人用 ， 我也没说谎呀 ， 我文档上写的很清楚的 ， 这标题也没骗人吧？
确实 ， 比如你点进震惊xxxx标题的文章 ， 人家也没骗你啥 ， 他自己确实震惊的呢 。
再回来谈 Kafka 的事务消息 ， 所以说这个事务消息不是我们想要的那个事务消息 ， 其实不是今天的主题了 ， 不过我还是简单的说一下 。
推荐阅读
- 湖人队|狂轰62+21+13！浓眉太无解，詹姆斯后仰杀死比赛，湖人却获坏消息！
- 智通财经|| 远洋服务向港交所递表 在管面积约4230万平方米，新股消息
- 第一财经|免税概念利好消息频出，机构看好板块未来强劲增长丨牛熊眼
- 第一财经|新力控股联席董事长陈凯传出离职消息
- 带你逛服贸 | 文化服务专题展 规模大、颜值高、创意多
- 山东鲁能|山东鲁能迎来好消息，“大鱼”正积极运作，李霄鹏乐坏了
- 财经|新力控股联席董事长陈凯传出离职消息
- 半年|新力控股联席董事长陈凯传出离职消息
- 中国军备|外媒大胆预测，今年下半年中国将迎来三个好消息，每个都举世瞩目
- 华光环能|好消息！华光环能：子公司中标污水处理总承包项目