RocketMQ架构

上一篇主要介绍笔者在实际工作遇到的RocketMQ应用场景, 本篇笔者主要记录RocketMQ架构的学习笔记.

RocketMQ 是阿里开源的消息中间件，它是一个开源的分布式消息传递和流式数据平台。
RocketMQ提供亿级消息的堆积能力，这不是重点，重点是堆积了亿级的消息后，依然保持写入低延迟！

RockMQ组成

RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成。

NameServer

NameServer主要包括两个主要功能：

• 管理brokers：broker服务器启动时会注册到NameServer上，并且两者之间保持心跳监测机制，以此来保证NameServer知道broker的存活状态；
• 路由信息管理：每一台NameServer都存有全部的broker集群信息和生产者/消费者客户端的请求信息；

NameServer用于存储Topic、Broker关系信息, 功能简单，稳定性高。
多个NameService之间没有通信, 单台NameService宕机不影响其他
NameServer与集群; 即使整个Namesrv集群宕机，已经正常工作的
Producer, Consumer，Broker仍然能正常工作，但新起的Producer,
 Consumer，Broker就无法工作。

注意: nameServer压力不会太大, 平时主要的开销是在维持心跳和提供brock-topic的关系数据.但有一点需要注意，Broker向Namesr发心跳时，会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话，网络传输失败，心跳失败，导致Namesrv误认为Broker心跳失败。

Broker

消息中转角色，负责存储消息，转发消息。

• Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，并会定时将Topic信息注册到NameServer，顺带一提底层的通信和连接都是基于Netty实现的。
• Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型。
• 官网上有数据显示：具有上亿级消息堆积能力，同时可严格保证消息的有序性。

Broker的作用

1. 负载均衡: Broker上存Topic信息，Topic由多个队列组成，队列会平均分散在多个Broker上，而Producer的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个Broker上。
2. 动态伸缩能力（非顺序消息）: Broker的伸缩性体现在两个维度：Topic, Broker。

Topic维度：假如一个Topic的消息量特别大，但集群水位压力还是很低，
就可以扩大该Topic的队列数，Topic的队列数跟发送、消费速度成正比。

Broker维度：如果集群水位很高了，需要扩容，直接加机器部署Broker就
可以。Broker起来后想Namesrv注册，Producer、Consumer通过Namesrv
发现新Broker，立即跟该Broker直连，收发消息。

3. 高可用&高可靠

• 高可用：集群部署时一般都为主备，