认识 MetaQ 消息中间件

您目前处于：后端 2019-10-26

中间件

本文转载自：

免责声明：本文内容来源于网络或其他公开渠道，版权归原作者所有。我们尊重原作者的知识产权，并尽力标注来源。如涉及版权问题或有任何侵权行为，请及时与我们联系，我们将尽快处理。转载此文仅用于信息分享和交流学习之用，不代表本平台观点。

系列文章：

MetaQ

MetaQ 是一款分布式、队列模型的消息中间件。分为 Topic 与 Queue 两种模式，Push 和 Pull 两种方式消费，支持严格的消息顺序，亿级别的堆积能力，支持消息回溯和多个维度的消息查询。

MetaQ发展历史

2007年，淘宝实施了“五彩石”项目，将交易系统由单机交易升级到了分布式，这个过程中产生了 Notify。
2010年，阿里巴巴 B2B 部门基于 ActiveMQ 的 5.1 版本也开发了自己的一款消息引擎，称为 Napoli。
2011年，Linkin 推出 Kafka 消息引擎，阿里巴巴在研究了 Kafka 的整体机制和架构设计之后，基于 Kafka 的设计使用 Java 进行了完全重写并推出了 MetaQ 1.0 版本，主要是用于解决顺序消息和海量堆积的问题，由开源社区 killme 2008 维护。
2012年，阿里巴巴对于 MetaQ 进行了架构重组升级，开发出了 MetaQ 2.0，这时就发现 MetaQ 原本基于 Kafka 的架构在阿里巴巴如此庞大的体系下很难进行水平扩展，所以在 2012 年的时候就开发了 RocketMQ 3.0。
2015年，又基于 RocketMQ 开发了阿里云上的 Aliware MQ 和 Notify 3.0。
2016年，阿里巴巴将 RocketMQ 的内核引擎捐赠给了 Apache 基金会。

MetaQ 和 RocketMQ 区别：两者等价，在阿里内部称为 MetaQ 3.0，对外称为 RocketMQ 3.0。

以上就是 RocketMQ 的整体发展历史，其实在阿里巴巴内部围绕着 RocketMQ 内核打造了三款产品，分别是 MetaQ、Notify 和 Aliware MQ。这三者分别采用了不同的模型：

MetaQ 物理机群部署架构

NameServer 集群：MetaQ 1.x 和 MetaQ 2.x 是依赖 ZooKeeper 的，由于 ZooKeeper 功能过重，RocketMQ（即 MetaQ 3.x）去掉了对 ZooKeeper 依赖，采用自己的 NameServer。
Broker：消息中转角色，负责存储消息，转发消息。
Consumer：Push Consumer / Pull Consumer。前者向 Consumer 对象注册一个 Listener 接口，收到消息后回调 Listener 接口方法，采用 long-polling 长轮询实现 push；后者主动由 Consumer 主动拉取信息，同 kafka。
Producer：消息生产者。

MetaQ 事务消息

1、发送方向 MQ 服务端发送消息。
2、MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。
3、发送方开始执行本地事务逻辑。
4、发送方根据本地事务执行结果向 MQ Server 提交二次确认（Commit 或是 Rollback），MQ Server 收到 Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 Rollback 状态则删除半消息，订阅方将不会接受该消息。
5、在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达 MQ Server，经过固定时间后 MQ Server 将对该消息发起消息回查。
6、发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
7、发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server 仍按照步骤4对半消息进行操作。

事务消息发送对应步骤1、2、3、4，事务消息回查对应步骤5、6、7。