RocketMQ 设计原理与实践

RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。同时，广泛应用于多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。

RocketMQ 前身叫做MetaQ，在MetaQ发布3.0版本的时候改名为 RocketMQ

RocketMQ本质上的设计思路和Kafka类似，但是和Kafka不同的是其使用Java进行开发，由于在国内的Java受众群体远远多于Scala、Erlang，所以RocketMQ是很多以Java语言为主的公司的首选。同样的RocketMQ和Kafka都是Apache基金会中的顶级项目，他们社区的活跃度都非常高，项目更新迭代也非常快。

RocketMQ是阿里review kafka的java版，如果消息性能要求高，用 RocketMQ 与 Kafka 可以更优

消息队列在实际应用中常用的使用场景，包含应用解耦、异步处理、流量削锋、消息通讯、日志处理等。

RocketMQ 官网：http://rocketmq.apache.org

RocketMQ Github：https://github.com/apache/rocketmq

Kafka 官网：http://kafka.apache.org

ActiveMQ 官网：http://activemq.apache.org

RabbitMQ 官网：https://www.rabbitmq.com

ZeroMQ 官网：https://zeromq.org

MetaMQ RocketMQ的前世今生

某公司一直用的消息中间件是MetaMQ现在，网上相关的资料也不是很多，今天去想淘宝为什会把MetaMQ给替换成了RocketMQ。就网上搜索了一下，这两个居然是爷孙关系。

阿里巴巴消息中间件起源于2001年的五彩石项目，Notify在这期间应运而生，用于交易核心消息的流转。

至2010年，B2B开始大规模使用ActiveMQ作为消息内核，随着阿里业务的快速发展，急需一款支持顺序消息，拥有海量消息堆积能力的消息中间件，MetaQ 1.0在2011年诞生。

到2012年，MetaQ已经发展到了MetaQ 3.0，并抽象出了通用的消息引擎RocketMQ。

随后，将RocketMQ进行了开源，阿里的消息中间件正式走入了公众的视野。

到2015年，RocketMQ已经经历了多年双十一的洗礼，在可用性、可靠性以及稳定性等方面都有出色的表现。与此同时，云计算大行其道，阿里消息中间件基于RocketMQ推出了Aliware MQ 1.0，开始为阿里云上成千上万家企业提供消息服务。

到今年，MetaQ在2016年双十一承载了万亿级消息的流转，跨越了一个新的里程碑，同时RocketMQ进入Apache 孵化。

RocketMQ 产品发展历史

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

1）Metaq 1.x（Metamorphosis）

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

2）Metaq 2.x

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

3）RocketMQ 3.x

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

在RocketMQ项目基础上衍生的项目如下

• com.taobao.metaq v3.0 = RocketMQ + 淘宝个性化需求，为淘宝应用提供消息服务。
• com.alipay.zpullmsg v1.0 = RocketMQ + 支付宝个性化需求，为支付宝应用提供消息服务。
• com.alibaba.commonmq v1.0 = Notify + RocketMQ + B2B个性化需求，为B2B应用提供消息服务。

一、 MQ背景&选型

消息队列作为分布式、高并发系统的核心组件之一，能够帮助业务系统解构，提升开发效率和系统稳定性。

MQ 主要具有以下优势：

1）削峰填谷：主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题

2）系统解耦：解决不同重要程度、不同能力级别系统之间依赖导致一死全死

3）提升性能：当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统

4）蓄流压测：线上有些链路不好压测，可以通过堆积一定量消息再放开来压测

目前主流的MQ主要是RocketMQ、kafka、RabbitMQ等

RocketMQ相比于RabbitMQ、kafka具有主要优势特性有：

1）支持事务型消息（消息发送和DB操作保持两方的最终一致性，rabbitmq和kafka不支持）

2）支持结合rocketmq的多个系统之间数据最终一致性（多方事务，二方事务是前提）

3）支持18个级别的延迟消息（rabbitmq和kafka不支持）

4）支持指定次数和时间间隔的失败消息重发（kafka不支持，rabbitmq需要手动确认）

5）支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持）

6）支持重复消费（rabbitmq不支持，kafka支持）

Rocketmq、kafka、Rabbitmq的详细对比，请参照下表格：

二、RocketMQ集群概述

1. RocketMQ集群部署结构

1) Name Server

Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

2) Broker

Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的Broker Name，不同的Broker Id来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

每个Broker与Name Server集群中的所有节点建立长连接，定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。

3) Producer

Producer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。

Producer每隔30s（由ClientConfig的pollNameServerInterval）从Name server获取所有topic队列的最新情况，这意味着如果Broker不可用，Producer最多30s能够感知，在此期间内发往Broker的所有消息都会失败。

Producer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s中扫描所有存活的连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。

4) Consumer

Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

Consumer每隔30s从Name server获取topic的最新队列情况，这意味着Broker不可用时，Consumer最多最需要30s才能感知。

Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；