共计 3740 个字符，预计需要花费 10 分钟才能阅读完成。
前言
RocketMQ 是一款分布式、队列模型的消息中间件，由阿里巴巴自主研发的一款实用于高并发、高可靠性、海量数据场景的消息中间件。晚期开源 2.X 版本名为 MetaQ；2015 年迭代 3.X 版本，更名为 RocketMQ，2016 年奉献给 Apache，通过一年多的孵化，最终成为 Apache 的顶级开源我的项目之一。RocketMQ 是在 Kafka 的根底上倒退起来的，它的诞生参考借鉴了 Apache Kafka（前面的文章我会独自介绍 Kafka）。起因是随着阿里巴巴业务的倒退，他们发现 Kafka 对于具体的业务场景反对的不欠缺，于是阿里巴巴的团队借鉴 Kafka 的设计思路，并联合本身“双十一”场景，自行开发了更贴合本人业务场景的 RocketMQ，对 Kafka 进行了正当的扩大和 API 丰盛。RocketMQ 的音讯路由、存储、集群划分等设计思路与 Kafka 都极其类似，惟一的不同是 RocketMQ 对于业务个性的反对更欠缺，所以更实用于业务场景。
1 专业术语
每一个技术框架，都有它的专有名词，RocketMQ 的专业术语如下：
1）Producer：音讯生产者，负责产生音讯，个别由业务零碎负责产生音讯。
2）Consumer：音讯消费者，负责生产音讯，个别由后盾零碎负责异步生产。
3）Pull Consumer：Consumer 的一种，须要被动申请 Broker 拉取音讯。
4）Push Consumer：Consumer 的一种，须要向 Consumer 对象注册监听。
5）Producer Group：生产者汇合，个别用于发送一类音讯。
6）Consumer Group：消费者汇合，个别用于承受一类音讯进行生产。
7）Broker：MQ 音讯服务（中专角色，用于音讯存储和生产生产转发）。
2 能力与反对
1）反对集群模型、负载平衡、程度扩大能力，如上面咱们要讲的集群架构。
2）亿级别的音讯沉积能力。
3）采纳零拷贝的原理、程序写盘、随机读（索引文件）。
4）丰盛的 API 应用。
5）代码优良，底层通信框架采纳 Netty NIO 框架。
6）NameServer 代替 Zookeeper。
7）强调集群无单点，可扩大，任意一点高可用，程度可扩大。
8）音讯失败重试机制、音讯可查问。
9）开源社区活跃度高，足够成熟（通过双十一考验）。
3 外围源码包及性能阐明
如下图，咱们看一下 RocketMQ 源码包的组成，这有利于咱们当前更深刻的学习。
1）rocketmq-broker 次要的业务逻辑，音讯收发，主从同步,pagecache
2）rocketmq-client 客户端接口，比方生产者和消费者
3）rocketmq-common 专用数据结构等等
4）rocketmq-distribution 编译模块，编译输入等
5）rocketmq-example 示例，比方生产者和消费者
6）rocketmq-fliter 进行 Broker 过滤的不感兴趣的音讯传输，减小带宽压力
7）rocketmq-logappender、rocketmq-logging 日志相干
8）rocketmq-namesrv Namesrv 服务，用于服务协调
9）rocketmq-openmessaging 对外提供服务
10）rocketmq-remoting 近程调用接口，封装 Netty 底层通信
11）rocketmq-srvutil 提供一些专用的工具办法，比方解析命令行参数
12）rocketmq-store 音讯存储外围包
13）rocketmq-test 提供一些测试代码包
14）rocketmq-tools 管理工具，比方有名的 mqadmin 工具
4 集群架构
RocketMQ 为咱们提供了丰盛的集群架构模型，包含单点模式、主从模式、双主模式以及生产上应用最多的双主双主模式（或者说多主多从模式），咱们来看一下最经典的双主双从模式，如下图：
1）NameServer 集群
NameServer 集群作为超轻量级的配置核心，存储以后集群所有的 Broker 信息、Topic 与 Broker 的对应关系。每个 NameServer 记录残缺的路由信息，提供等效的读写服务，并反对疾速存储扩大。NameServer 只做集群元数据存储和心跳工作，性能简略，稳定性高。多个 NameServer 之间没有通信，不用保障节点间的数据强一致性，也就是说 NameServer 集群是一个多机热备的概念，单台 NameServer 宕机不影响其余 NameServer 工作。须要留神的是，及时整个 NameServer 集群宕机了，曾经失常工作的 Producer、Consumer、Broker 依然能失常工作，但新起的 Producer、Consumer、Broker 就无奈工作。
NameServer 采纳的是心跳机制，具体如下：
a、单个 Broker 跟所有 NameServer 放弃心跳申请，心跳距离为 30 秒，心跳申请中包含以后 Broker 所有的 Topic 信息。须要留神的是，Broker 向 Namesrv 发心跳时，会带上以后本人所负责的所有 Topic 信息，如果 Topic 个数太多（万级别），会导致一次心跳中，就 Topic 的数据就几十 M，网络状况差的话，网络传输失败，心跳失败，导致 Namesrv 误认为 Broker 心跳失败。
b、NameServer 会反查 Broer 的心跳信息，如果某个 Broker 在 2 分钟之内都没有心跳，则认为该 Broker 下线，调整 Topic 跟 Broker 的对应关系。但此时 NameServer 不会被动告诉 Producer、Consumer 有 Broker 宕机。
c、Consumer 跟 Broker 是长连贯，会每隔 30 秒发心跳信息到 Broker。Broker 端每 10 秒查看一次以后存活的 Consumer，若发现某个 Consumer 2 分钟内没有心跳，就断开与该 Consumer 的连贯，并且向该生产组的其余实例发送告诉，触发该消费者集群的负载平衡 (rebalance)。
d、生产者每 30 秒从 Namesrv 获取 Topic 跟 Broker 的映射关系，更新到本地内存中。再跟 Topic 波及的所有 Broker 建设长连贯，每隔 30 秒发一次心跳。在 Broker 端也会每 10 秒扫描一次以后注册的 Producer，如果发现某个 Producer 超过 2 分钟都没有发心跳，则断开连接。
2）Producer 集群
Producer 集群就是音讯生产者集群，它们在同一个生产者组 Producer Group。Producer 与 Name Server 集群中的其中一个节点（随机抉择）建设长连贯，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master 建设长连贯，且定时向 Master 发送心跳。Producer 齐全无状态，可集群部署。
3）Consumer 集群
Consumer 集群就是音讯消费者，它们在同一个消费者组 Consumer Group。Consumer 与 Name Server 集群中的其中一个节点（随机抉择）建设长连贯，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建设长连贯，且定时向 Master、Slave 发送心跳。Consumer 既能够从 Master 订阅音讯，也能够从 Slave 订阅音讯，订阅规定由 Broker 配置决定。
4）Broker 集群
对于 Broker 来说，通常 Master 和 Slave 为一组服务，它们互为主从节点，通过 NameServer 与内部的 Client 端裸露对立的集群入口。Broker 就是音讯存储的外围 MQ 服务。
5 总结
RockerMQ 作为国内顶级的消息中间件，其性能次要依赖于人造的分布式 Topic/Queue，并且其内存与磁盘都会存储音讯数据，借鉴了 Kafka 的“地面接力”概念，就是指数据不肯定落地，RocketMQ 提供了同步 / 异步双写、同步 / 异步复制的个性。在真正的生产环境中应该抉择合乎本人业务的配置。上面针对 RocketMQ 的高性能和瓶颈加以阐明：
1）在理论生产环境中面临的次要瓶颈最终会落在 IOPS 上，也就是磁盘读写能力。当高峰期降临，每秒收发音讯 IOPS 达到 10W+ 音讯，在云环境上，云环境的 SSD 物理存储显然和自建机房 SSD 有着很大的差距，这一点咱们无论是从数据库的磁盘性能、还是搜寻服务（ElasticSearch）的磁盘性能，都能给出精确的瓶颈点，单机 IOPS 达到 1 万左右就是云存储 SSD 的性能瓶颈，在这里咱们也看到了“木桶短板原理”的效应，在真正的生产中，CPU 的工作次要在期待 IO 操作，高并发下 CPU 资源靠近极限，然而 IOPS 还是达不到咱们想要的成果。
2）RocketMQ 的性能曾经足够好，然而在很多时候，咱们的业务会有一些非核心的音讯投递，能够进行消息中间件的业务拆分，把不重要的音讯（容许音讯失落、非可靠性投递的音讯）采纳 Kafka 的异步发送机制，借住 Kafka 弱小的吞吐量和音讯沉积能力来做业务分流，以此缓解 RocketMQ 的性能瓶颈。
如果感觉对你有帮忙点赞反对一下