RocketMQ（一）——简介

上一篇博客主要是介绍了MQ，从这篇开始，步入正题，也就是RocketMQ。阿里巴巴有2大核心的分布式技术，一个是OceanBase，另一个就是RocketMQ。之前项目用过ActiveMQ，不论成熟度还是广泛度，ActiveMQ绝对是彪悍致极。而最近的项目，用的是RocketMQ，有种非一般的体验。

What is RocketMQ?

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

---

Where is RocketMQ from?

RocketMQ的是如何发而来的，也就是三个主要版本迭代：

1. Metaq(Metamorphosis) 1.x

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

2. Metaq 2.x

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

3. RocketMQ 3.x

Metaq 3.0发布时，产品名称改为RocketMQ。基于公司内部开源共建原则，RocketMQ项目只维护核心功能，且去除了所有其他运行时的依赖，核心功能最简化。每个BU的个性化需求都在RocketMQ项目之上进行深度定制。RocketMQ向其他BU提供的仅仅是jar包，例如要定制一个Broker，那么只需要依赖rocketmq-broker这个jar包即可，可通过API进行交互，如果定制client,则依赖rocketmq-client这个jar包，对其提供的api进行再封装。

---

How is RocketMQ?

下面简单列举一下RocketMQ的几大特性：

• 原生分布式

要知道RocketMQ原生就是支持分布式的，而ActiveMQ原生存在单点性。

• 严格消息顺序

RocketMQ可以保证严格的消息顺序，而ActiveMQ无法保证！

• 亿级消息堆积

RocketMQ提供亿级消息的堆积能力，这不是重点，重点是堆积了亿级的消息后，依然保持写入低延迟！

• 两种消息拉取

两种的消息拉取模式（Push or Pull）。
Push好理解，比如在消费者端设置Listener回调；而Pull，控制权在于应用，即应用需要主动的调用拉消息方法从Broker获取消息，这里面存在一个消费位置记录的问题（如果不记录，会导致消息重复消费）。

• 特有的分布式协调器

在Metaq1.x/2.x的版本中，分布式协调采用的是Zookeeper，而RocketMQ自己实现了一个NameServer，更加轻量级，性能更好！

• 组（Group）

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

• 其他

消息失败重试机制、高效的订阅者水平扩展能力、强大的API、事务机制等等（后续详细介绍）

---

这里只作简述，具体的可参考《RocketMQ 开发指南》这份文档资料。