认识MetaQ 消息中间件

2023-05-30 00:00:00 消息 阿里巴巴 发送 事务 架构

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。

相关文章