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 主要使用了拉模型,解决了顺序消息和海量堆积问题。
- 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。