RocketMQ简介

1 前言

本文档旨在描述 RocketMQ 的多个关键特性的实现原理，并对消息中间件遇到的各种问题进行总结，阐述
RocketMQ 如何解决这些问题。文中主要引用了 JMS 规范与 CORBA Notification 规范，规范为我们设计系统指明了
方向，但是仍有不少问题规范没有提及，对于消息中间件又至关重要。RocketMQ 并不遵循任何规范，但是参考了
各种规范与同类产品的设计思想。

2 产品发展历史

大约经历了三个主要版本迭代

一、Metaq（Metamorphosis） 1.x

由开源社区 killme2008 维护，开源社区非常活跃。
https://github.com/killme2008/Metamorphosis

二、Metaq 2.x

于 2012 年 10 月份上线，在淘宝内部被广泛使用。

三、RocketMQ 3.x

基于公司内部开源共建原则， RocketMQ 项目只维护核心功能，且去除了所有其他运行时依赖，核心功能最
简化。每个 BU 的个性化需求都在 RocketMQ 项目之上进行深度定制。RocketMQ 向其他 BU 提供的仅仅是
Jar 包，例如要定制一个 Broker，那么只需要依赖 rocketmq-broker 这个 jar 包即可，可通过 API 进行交互，
如果定制 client，则依赖 rocketmq-client 这个 jar 包，对其提供的 api 进行再封装。
开源社区地址：
https://github.com/alibaba/RocketMQ
在 RocketMQ 项目基础上衍生的项目如下
- com.taobao.metaq v3.0 = RocketMQ + 淘宝个性化需求
为淘宝应用提供消息服务
项目开源主页：https://github.com/alibaba/RocketMQ
- com.alipay.zpullmsg v1.0 = RocketMQ + 支付宝个性化需求
为支付宝应用提供消息服务
- com.alibaba.commonmq v1.0 = Notify + RocketMQ + B2B 个性化需求
为 B2B 应用提供消息服务

3 专业术语

• Producer

消息生产者，负责产生消息，一般由业务系统负责产生消息。

• Consumer

消息消费者，负责消费消息，一般是后台系统负责异步消费。

• Push Consumer

Consumer 的一种，应用通常向 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立
刻回调 Listener 接口方法。

• Pull Consumer

Consumer 的一种，应用通常主动调用 Consumer 的拉消息方法从 Broker 拉消息，主动权由应用控制。

• Producer Group

一类 Producer 的集合名称，这类 Producer 通常发送一类消息，且发送逻辑一致。

• Consumer Group

一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。

• Broker

消息中转角色，负责存储消息，转发消息，一般也称为 Server。在 JMS 规范中称为 Provider。

• 广播消费

一条消息被多个 Consumer 消费， 即使这些 Consumer 属于同一个 Consumer Group， 消息也会被 Consumer
Group 中的每个 Consumer 都消费一次， 广播消费中的 Consumer Group 概念可以认为在消息划分方面无意
义。
在 CORBA Notification 规范中，消费方式都属于广播消费。

• 集群消费
  一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个Consumer Group 有 3 个实例（可能是 3 个进程，或者 3 台机器） ，那么每个实例只消费其中的 3 条消息。
• 顺序消息

消费消息的顺序要同发送消息的顺序一致，在 RocketMQ 中，主要指的是局部顺序，即一类消息为满足顺序性，必须 Producer 单线程顺序发送，且发送到同一个队列，这样 Consumer 就可以按照 Producer 发送
的顺序去消费消息。

• 普通顺序消息

顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生通信异常，Broker 重启，由于队列总数发生变化，哈希取模后定位的队列会变化，产生短暂的消息顺序不一致。
如果业务能容忍在集群异常情况（如某个 Broker 宕机或者重启）下，消息短暂的乱序，使用普通顺序方式比较合适。

• 严格顺序消息

顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式 Failover 特性，即 Broker 集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。
如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用。 （依赖同步双写，主备自动切换，自动切换功能目前还未实现）
目前已知的应用只有数据库 binlog 同步强依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推荐使用普通的顺序消息。

• Message Queue

在 RocketMQ 中，所有消息队列都是持久化，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用 Offset 来访问，offset 为 java long 类型，64 位，理论上在 100年内不会溢出，所以认为是长度无限，另外队列中只保存最近几天的数据，之前的数据会按照过期时间来
删除。
也可以认为 Message Queue 是一个长度无限的数组，offset 就是下标。