本文为 RocketMQ 开发指导系列的第一篇，主要从整体上介绍 RocketMQ 的相关知识。
说明：本文的部分内容参考了 https://www.jianshu.com/p/3afd610a8f7d 文章，并对其内容进行了一些修改。
1 概述
首先，给出 GitHub 上 RocketMQ 项目的描述，如下：
Apache RocketMQ is a distributed messaging and streaming platform with low latency, high performance and reliability, trillion-level capacity and flexible scalability.
It offers a variety of features:
- Pub/Sub messaging model
- Scheduled message delivery
- Message retroactivity by time or offset
- Log hub for streaming
- Big data integration
- Reliable FIFO and strict ordered messaging in the same queue
- Efficient pull&push consumption model
- Million-level message accumulation capacity in a single queue
- Multiple messaging protocols like JMS and OpenMessaging
- Flexible distributed scale-out deployment architecture
- Lightning-fast batch message exchange system
- Various message filter mechanics such as SQL and Tag
- Docker images for isolated testing and cloud isolated clusters
- Feature-rich administrative dashboard for configuration, metrics and monitoring
RocketMQ 作为一款分布式的消息中间件，经历了 Metaq1.x、Metaq2.x 的发展和淘宝双十一的洗礼，证明其在功能和性能上远超 ActiveMQ。GitHub 上关于 RocketMQ 诞生的原因中，也说明了随着交易量的大幅度增长，ActiveMQ 到达了性能瓶颈，而其他流行的消息解决方案（如Kafka）都不能满足其需求的情况下，才诞生了 RocketMQ。
RocketMQ 的优点如下：
- RocketMQ 原生就是支持分布式的，而 ActiveMQ 原生为单点性；
- RocketMQ 可以保证严格的消息顺序，而 ActiveMQ 无法保证；
- RocketMQ 提供亿级消息的堆积能力，这不是重点，重点是堆积了亿级的消息后，依然保持写入低延迟；
- 丰富的消息拉取模式（Push or Pull）。Push 模式好理解，比如在消费者端设置 Listener 回调；而 Pull 模式，控制权在于消费者，即消费者需要主动地调用拉消息方法从 Broker 获取消息，这里面就存在一个消费位置记录的问题（如果不记录，会导致消息重复消费）；
- 在 Metaq1.x/2.x 的版本中，分布式协调采用的是 Zookeeper，而 RocketMQ 自己实现了一个 NameServer，这使得 RocketMQ 的分布式架构更加轻量级，性能更好；
- 消息失败重试机制、高效的订阅者水平扩展能力、强大的API、事务机制
2 Producer/Consumer Group
ActiveMQ 中并没有 Group 这个概念，而在 RocketMQ 中存在 Group 的机制，理解该机制对于深入理解 RocketMQ 很重要。
RocketMQ 通过 Group 机制，天然地支持了消息负载均衡。例如，某个 Topic 有9条消息，其中一个 Consumer Group 有3个实例（3个进程/3台机器），那么每个实例将均摊3条消息，由此实现了负载均衡。（注意 RocketMQ 只有一种模式，即发布订阅模式）
3 集群模式
RocketMQ 有多种 Broker 集群部署模式，常见的包括：单 Master 模式、多 Master 模式、多 Master 多 Slave 模式（异步复制）、多 Master 多 Slave 模式（同步双写）等。这里需要强调明一下：RocketMQ 的 Slave 只能被消费者读取，不可以被生产者写入，类似于 MySQL 的主从机制。下面分别介绍这几种 Broker 集群部署模式。
3.1 单Master模式
很显然，单 Master 模式部署风险较大，一旦这个 Broker 重启或宕机，会导致整个服务不可用，通常线上环境都不会使用此模式。
3.2 多Master模式
集群中全是 Master，没有 Slave，例如2个 Master 或3个 Master。此时，如果某一个 Broker 重启或宕机，对应用是无影响的。此模式的缺点在于，当某个 Master 宕机时，该 Master 上未被消费的消息在 Master 恢复之前是不可以订阅的，消息的实时性会受到影响。
3.3 多Master多Slave模式（异步复制）
此模式下，有多个 Master，每个 Master 会配置一个或多个 Slave，由此实现了系统的高可用性。同时，Master 与 Slave 之间的消息同步，采用异步复制的方式，主备之间会短暂的消息延迟，这种延迟是 MS 级别的。如果 Master 宕机，消费者可以从 Slave 上进行消息消费，不影响消息实时性，但是由于 Master 的宕机，会导致丢失掉极少量（尚未同步到 Slave 上）的消息。
3.4 多Master多Slave模式（同步双写）
此模式下，有多个 Master，每个 Master 会配置一个或多个 Slave，由此实现了系统的高可用性。同时，Master 与 Slave 之间的消息同步，采用同步双写的方式，也就是在 Master 和 Slave 都写成功的前提下，才会向应用（生产者）返回成功。显然，此种模式下，无论是数据还是服务都不是单点的，所以服务与数据的可用性都非常高。此模式的缺点在于，性能会比异步复制稍低。
多Master多Slave模式的部署架构图，如下所示：
4 RocketMQ vs ActiveMQ vs Kafka
下面给出一张 RocketMQ、ActiveMQ 和 Kafka 的技术和特性的对比图，如下：
| Messaging Product | Client SDK | Protocol and Specification | Ordered Message | Scheduled Message | Batched Message | BroadCast Message | Message Filter | Server Triggered Redelivery | Message Storage | Message Retroactive | Message Priority | High Availability and Failover | Message Track | Configuration | Management and Operation Tools |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ActiveMQ | Java, .NET, C++ etc. | Push model, support OpenWire, STOMP, AMQP, MQTT, JMS | Exclusive Consumer or Exclusive Queues can ensure ordering | Supported | Not Supported | Supported | Supported | Not Supported | Supports very fast persistence using JDBC along with a high performance journal，such as levelDB, kahaDB | Supported | Supported | Supported, depending on storage,if using kahadb it requires a ZooKeeper server | Not Supported | The default configuration is low level, user need to optimize the configuration parameters | Supported |
| Kafka | Java, Scala etc. | Pull model, support TCP | Ensure ordering of messages within a partition | Not Supported | Supported, with async producer | Not Supported | Supported, you can use Kafka Streams to filter messages | Not Supported | High performance file storage | Supported offset indicate | Not Supported | Supported, requires a ZooKeeper server | Not Supported | Kafka uses key-value pairs format for configuration. These values can be supplied either from a file or programmatically. | Supported, use terminal command to expose core metrics |
| RocketMQ | Java, C++, Go | Pull model, support TCP, JMS, OpenMessaging | Ensure strict ordering of messages,and can scale out gracefully | Supported | Supported, with sync mode to avoid message loss | Supported | Supported, property filter expressions based on SQL92 | Supported | High performance and low latency file storage | Supported timestamp and offset two indicates | Not Supported | Supported, Master-Slave model, without another kit | Supported | Work out of box,user only need to pay attention to a few configurations | Supported, rich web and terminal command to expose core metrics |