阿里巴巴有 2 大核心的分布式技术，一个是 OceanBase，另一个就是RocketMQ。在实际项目中已经领教过RocketMQ的强大，本人计划写一个RocketMQ实战系列，将涵盖RocketMQ的简介，环境搭建，初步使用、API 详解、架构分析、管理员集群操作等知识。

What is RocketMQ?

RocketMQ作为一款分布式的消息中间件（阿里的说法是不遵循任何规范的，所以不能完全用 JMS 的那一套东西来看它），经历了 Metaq1.x、Metaq2.x 的发展和淘宝双十一的洗礼，在功能和性能上远超 ActiveMQ。

1.要知道RocketMQ原生就是支持分布式的，而 ActiveMQ 原生存在单点性。
2.RocketMQ 可以保证严格的消息顺序，而 ActiveMQ 无法保证！
3.RocketMQ 提供亿级消息的堆积能力，这不是重点，重点是堆积了亿级的消息后，依然保持写入低延迟！
4.丰富的消息拉取模式（Push or Pull）
Push 好理解，比如在消费者端设置 Listener 回调；而 Pull，控制权在于应用，即应用需要主动的调用拉消息方法从 Broker 获取消息，这里面存在一个消费位置记录的问题（如果不记录，会导致消息重复消费）。
5.在 Metaq1.x/2.x 的版本中，分布式协调采用的是 Zookeeper，而 RocketMQ 自己实现了一个 NameServer，更加轻量级，性能更好！
6.消息失败重试机制、高效的订阅者水平扩展能力、强大的 API、事务机制等等（后续详细介绍）

初步理解 Producer/Consumer Group

ActiveMQ 中并没有 Group 这个概念，而在 RocketMQ 中理解 Group 的机制很重要。

Group 机制

想过没有，通过 Group 机制，让 RocketMQ 天然的支持消息负载均衡！
比如某个 Topic 有 9 条消息，其中一个 Consumer Group 有 3 个实例（3 个进程 OR 3 台机器），那么每个实例将均摊 3 条消息！（注意 RocketMQ 只有一种模式，即发布订阅模式。）

install RocketMQ

RocketMQ 的 Broker 集群部署模式还挺多的，比如单 Master 模式、多 Master 模式、多 Master 多 Slave 模式（异步复制）、多 Master 多 Slave 模式（同步双写）等。明确个概念，RocketMQ Slave 不可以写，可以读，类似于 MySQL 的主从机制。
单 Master 模式：
无需多言，一旦单个 broker 重启或宕机，一切都结束了！很显然，线上不可以使用。
多 Master 模式：
全是 Master，没有 Slave。当然，一个 broker 宕机了，应用是无影响的，缺点在于宕机的 Master 上未被消费的消息在 Master 没有恢复之前不可以订阅。
多 Master 多 Slave 模式（异步复制）：
多对 Master-Slave，高可用！采用异步复制的方式，主备之间短暂延迟，MS 级别。Master 宕机，消费者可以从 Slave 上进行消费，不受影响，但是 Master 的宕机，会导致丢失掉极少量的消息。
多 Master 多 Slave 模式（同步双写）：
和上面的区别点在于采用的是同步方式，也就是在 Master/Slave 都写成功的前提下，向应用返回成功，可见不论是数据，还是服务都没有单点，都非常可靠！缺点在于同步的性能比异步稍低。

这里我将采用 2 个 Master 的方式进行搭建演示，会了双 Master，其他的将很简单。（多 Master 在实际中也是非常常用的，如果并发非常大，考虑多 Master 多 Slave 模式）