精讲高并发异步解耦利器RocketMQ技术架构，及运行原理，及分析RocketMQ究竟强在哪里?RocketMQ集群是如何做数据分区的？如何做数据分区的？

前言 

RabbitMQ，其功能也是挺强大的，那么，为啥又要搞一个RocketMQ出来呢？是重复造轮子吗？本文我们就带大家来详细探讨RocketMQ究竟好在哪里。

RocketMQ是一个分布式消息中间件，具有低延迟、高性能和可靠性、万亿级别的容量和灵活的可扩展性。它是阿里巴巴于2012年开源的第三代分布式消息中间件。

随着阿里巴巴的电商业务不断发展，需要一款更高性能的消息中间件，RocketMQ就是这个业务背景的产物。RocketMQ是一个分布式消息中间件，具有低延迟、高性能和可靠性、万亿级别的容量和灵活的可扩展性，它是阿里巴巴于2012年开源的第三代分布式消息中间件。RocketMQ经历了多年双十一的洗礼，在可用性、可靠性以及稳定性等方面都有出色的表现。值得一提的是，RocketMQ最初就是借鉴了Kafka进行改造开发而来的，所以熟悉Kafka的朋友，会发现RocketMQ的原理和Kafka有很多相似之处。

RocketMQ前身叫做MetaQ，在MeataQ发布3.0版本的时候改名为RocketMQ，其本质上的设计思路和Kafka类似，因为最初就是基于Kafka改造而来，经过不断的迭代与版本升级，2016年11月21日，阿里巴巴向Apache软件基金会捐赠了RocketMQ 。

滴滴跟进跟进新增RocketMQ的目的？

滴滴为了支持多语言环境、解决一些迁移和某些业务的特殊需求，也跟进新增RocketMQ作为消息引擎，业务端只跟代理层Proxy交互。中间的消息引擎，负责消息的核心存储。后续主要围绕三个方向做深度开发：

1. 消息队列统一，其他队列迁移到统一消息队列平台上。
2. 功能迭代和成本性能上的优化。
3. 服务化，业务直接通过管理平台来申请资源，申请审批成功后就可以使用。

滴滴为什么选择MQ架构，作为消息队列系统架构？

1. 支持7种语言客户端。
2. 其他服务逐步统一迁移到存储引擎RocketMQ上。
3. 支持多协议，例如HTTP协议RESTful。
4. 利用groovy脚本功能可以转存消息到Redis、Hbase和HDFS上。
5. 与实时计算平台对接，例如Flink，Spark，Storm。
6. 使用topic要申请审批通过才可使用，填写信息为：Topic，填写各种信息，包括身份信息，消息的峰值流量，消息大小，消息格式等等。
7. 运维控制台，主要负责我们集群的管理，自动化部署，流量调度，状态显示之类的功能。最后所有运维和用户操作会影响线上的配置，都会通过ZooKeeper进行同步。

为什么很多公司都选择RocketMQ？

通过Kafka与RocketMQ进行性能测试比较，结果如下：

1. Kafka吞吐受Topic数量的影响特别明显，单机器partitions数量超过2000，超过了越多性能越低。RocketMQ吞吐量比Kafka低30~40%，但不受单机partitions分片数量影响，吞吐性能基本保持稳定不变。
2. 延迟性比较，同步刷盘方面Kafka延时比RocketMQ高。

RocketMQ技术架构

RocketMQ的架构主要分为四部分，如下图所示：

•  Producer：消息生产者，支持集群方式部署；
• Consumer：消息消费者，支持集群方式部署，支持pull，push模式获取消息进行消费，支持集群和广播方式消费；
• NameServer：Topic路由注册中心，类似于Dubbo中的zookeeper，支持Broker的动态注册与发现；

1. 提供心跳检测机制，检查Broker是否存活；
2. 接收Broker集群的注册信息，作为路由信息的基本数据；
3. NameServier各个实例不相互进行通信，每个NameServer都保存了一份完整的路由信息，这与zookeeper有所区别，不用作复杂的节点数据同步与选主过程；

• BrokerServer：主要负责消息的存储、投递和查询，以及服务高可用保证。BrokerServer包含以下几个重要的子模块：

1. Remoting Module：整个Broker的实体，负责处理来自clients端的请求；
2. Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息；
3. StoreService：提供方便简单的API接口处理消息存储到物理硬盘和查询功能；
4. HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能；
5. Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。

 RocketMQ执行原理

RocketMQ执行原理如下图所示：

1. 首先，启动每个NameServer节点，共同构成一个NameServer Cluster。NameServer启动后，监听端口，等待Broker、Producer、Consumer的连接；
2. 然后启动Broker的主从节点，这个时候Broker会,与所有的NameServer建立并保持长连接，定时发送心跳包，把自己的信息(IP+端口号)以及存储的所有Topic信息注册到每个NameServer中。这样NameServer集群中就有Topic和Broker的映射关系了；
3. 收发消息前，先创建Topic，创建Topic时，需要指定该Topic要存储在哪些Broker上，也可以在发送消息时，自动创建Topic，每个Topic默认会分配4个Queue；
4. 启动生产者，这个时候生产者，会把信息，注册到NameServer中，并且从NameServer获取Broker服务器，Queue等信息；
5. 启动消费者，这个时候消费者，会把信息注册到NameServer中，并且从NameServer获取Broker服务器，Queue等信息；
6. 生产者发送消息，到Broker集群中的时候，会从所有的Master节点的对应Topic中，选择一个Queue，然后与Queue所在的Broker，建立长连接，从而向Broker投递消息。消息实际上是存储在了CommitLog文件中，而Queue文件里面，存储的实际是，消息在CommitLog中的存储位置信息；
7. 消费者从Broker集群中，消费消息的时候，会通过特定的负载均衡算法，绑定一个消息队列进行消费；
8. 消费者会定时（或者kill阶段）把Queue的消费进度offset提交到Broker的consumerOffset.json文件中记录起来；
9. 主节点和从节点之间可以是同步或者异步的进行数据复制，相关配置参数：

• brokerRole，可选值：

• ASYNC_MASTER：异步复制方式(异步双写)，生产者写入消息到Master之后，无需等到消息复制到Slave即可返回，消息的复制由旁路线程进行异步复制；
• SYNC_MASTER：同步复制方式(同步双写)，生产者写入消息到Master之后，需要等到Slave复制成功，才可以返回。如果有多个Slave，只需要有一个Slave复制成功，并成功应答，就算复制成功了。这里是否持久化到磁盘依赖于另一个参数：flushDiskType；
• SLAVE：从节点

RocketMQ集群

本节我们来看看一个双主双从的RocketMQ是如何搭建的?

集群配置参数说明：

在讨论集群前，我们需要了解两个关键的集群配置参数：brokerRole，flushDiskType。brokerRole在前一节已经介绍了，而flushDiskType则是刷盘方式的配置，主要有：

• ASYNC_FLUSH: 异步刷盘
• SYNC_FLUSH: 同步刷盘

如何保证消息存储的可靠性？

brokerRole确定了主从同步是异步的还是同步的，flushDiskType确定了数据刷盘的方式是同步的还是异步的。

如果业务场景对消息丢失容忍度很低，可以采用SYNC_MASTER + ASYNC_FLUSH的方式，这样只有master和slave在刷盘前同时挂掉，消息才会丢失，也就是说，即使有一台机器出故障，仍然能保证数据不丢；

如果业务场景，对消息丢失容忍度比较高，则可以采用ASYNC_MASTER + ASYNC_FLUSH的方式，这样可以尽可能的提高消息的吞吐量。

如何保证消息队列服务的高可用?

消费端的高可用

Master Broker支持读和写，Slave Broker只支持读。

当Master不可用的时候，Consumer会自动切换到Slave进行读，也就是说，当Master节点的机器出现故障后，Consumer仍然可以从Slave节点读取消息，不影响消费端的消费程序。

生产端的高可用

集群配置参数说明：

brokerName: broker的名称，需要把Master和Slave节点配置成相同的名称，表示他们的主从关系，相同的brokerName的一组broker，组成一个broker组；
brokerId: broker的id，0表示Master节点的id，大于0表示Slave节点的id。
在RocketMQ中，机器的主从节点关系是提前配置好的，没有类似Kafka的Master动态选主功能。

如果一个Master宕机了，要让生产端程序，继续可以生产消息，您需要部署多个Master节点，组成多个broker组。这样在创建Topic的时候，就可以把Topic的不同消息队列，分布在多个broker组中，即使某一个broker组的Master节点不可用了，其他组的Master节点仍然可用，保证了Producer可以继续发送消息。

如何构建一个高可用的RocketMQ双主双从最小集群？

为了尽可能的保证消息不丢失，并且保证生产者和消费者的可用性，我们可以构建一个双主双从的集群，搭建的架构图如下所示：

部署架构说明：

• 两个Broker组，保证了其中一个Broker组的Master节点挂掉之后，另一个Master节点仍然可以接受某一个Topic的消息投递；
• 主从同步，采用SYNC_MASTER，保证了生产者写入消息到Master之后，需要等到Slave也复制成功，才返回消息投递成功。这样即使主节点或者从节点挂掉了，也