RocketMQ的基本介绍

概述

阿里开源（emmmmmmmm）。号称是站在kafka巨人的肩膀(抄的kafka)上更适合互联网公司的架构。目前阿里内部的消息的主要的消息引擎内核。阿里将其广泛用于交易系统，购物车请求，红包等。其公有云版aliware已经进行公开售卖。
但是kafka存在一定问题，就是在主题特别多的情况下。性能下降很快。这是因为kafka每个主题对应自己的文件，这样，如果文件特别多，实际上也就没有了磁盘顺序读取的优势了。而rocketMQ改成了所有主题写一个文件，同时开辟一个异步线程对这个文件生成一个索引（开始位置 + 长度）。
在互联网企业，kafka一般用于存储日志。因为日志主题往往有限。

基本架构如下

对比kafka，架构中增加了slave broker。
逻辑架构如下，

比kafka多了Producer Group的设定。这是支持事务的必要。
3.2.6版本及以上版本，删除了回查机制，回查机制要自己实现。
通过加入插件，可以实现pull和push的模式。

架构设计

事务

MQ的

在1后，事务消息是prepare状态，然后RMQ会将其持久化到MySQL当中。然后如果收到确认消息，就删除掉这条prepare消息（确认的话放到pepared消息列表里供consumer进行读取），如果迟迟收不到确认消息，那么RMQ会定时的扫描prepare消息，发送给produce group进行【回查】确认。
3.2.6版本及以上，上述回查机制被取消了（完全不知道原因）。也就是说，如果我们完成4后，没有成功进行5，将回导致这个事务只完成了producer一端的事务。事务被破坏。

没办法啊，我们需要自己实现回查机制。

实现回查机制的本质策略都是对比使用另外的线程对比producer认为自己成功发送的和consumer成功接收的消息。可以采用的方案之一是分别把producer发送消息和consumer成功处理消息分别存储于redis的空间，然后定时检查回滚。

另外一种思路则是consumer定时把自己的处理完的消息通过某种方式发送给producer，供producer决定回滚那些事务。
当然，有人又会问，回查机制也失败了怎么办？比如说consuemr在发送回查给producer前崩溃了？同