RocketMQ
RocketMQ是一个统一的消息传递引擎，轻量级的数据处理平台。
Name Server
Name Server充当路由消息的提供者，生产者(Producer)或消费者(Customer)可以通过Name Server查找各主题对应的Broker IP列表，多个Name Server实例组成集群，但相互独立，没有信息交换。支持Broker的动态注册与发现。主要包括两个功能：
Broker管理：Name Server接收Broker集群的注册信息并且保存下来作为路由信息的基本数据，然后提供心跳检测机制，检查Broker是否存活；
路由信息管理：每个Name Server将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息，然后生产者(Producer)和消费者(Conumser）通过Name Server就可以知道整个Broker集群的整个路由信息和用于客户端查询的队列信息，从而进行消息的投递和消费。
Broker Server
负责存储消息、转发消息。Broker Server在RocketMQ系统中负责接收从生产者(Producer)发送来的消息并存储、同事为消费者的拉取请求做准备。Borker Server也存储消息相关的元数据，包括消费者组、消费进度偏移、主题和队列信息等。
Broker启动后需要完成一次将自己注册至NameServer的操作；随后每隔30s时间定时向NameServer上报Topic路由信息。
为了实现Broker中消息的存储、投递、查询以及服务高可用的保证，囊括一下几个重要的子模块信息：
Remoting Module：整个borker的实体，负责处理来自客户端的请求；
Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息；
Store Service：提供简单的API接口处理消息存储到物理硬盘和查询功能；
HA Service：高可用服务，提供Master Broker和Slaver Broker之间的数据同步功能；
Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。
Broker 架构
消息存储是RocketMQ中至关重要的一部分，想对其他来说会比较复杂。
消息存储架构
- CommitLog：消息主体以及元数据的存储主体，存储Producer端写入的消息主体内容，消息内容不是定长的，单个文件大小默认1G，文件名长度20位，左边补0，剩余为其实偏移量，比如00000000000000000000代表了第一个文件，其实偏移量为0，文件大小为1G=1073741824；当第一个文件写满了，第二个文件为00000000001073741824，起始偏移量为1073741824，以此类推，消息主要是顺序写入日志文件，当文件满了，写入下一个文件；
- ConsumeQueue：消息消费队列，引入的目的主要是提高消费消息的性能，由于RocketMQ是基于主题topic的订阅模式，消息消费是针对主题进行的，如果要遍历commitlog文件中根据topic检索消息非常低效的，Consumer即可根据ConsumeQueue来查找待消费的消息，其中，ConsumeQueue(逻辑消费队列)作为消费消息的索引，保存指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的hashCode值，consumequeue文件可以看成是基于topic的commitLog索引文件，所以consumequeue文件夹组织方式如下：topic/queue/file三层组织结构，具体存储路径为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}，同样consumequeue文件采用定长设计，每一个条目共20个字节，分别为8字节的commitlog物理偏移量，4字节消息长度，8字节tag hashcode，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个ConsumeQueue文件大小约为5.72M;
- IndexFile：IndexFile（索引文件）提供了一种可以通过key或时间区间来查询消息的方法。Index文件的存储位置是：$HOME/store/index/{fileName}，文件名fileName是以创建时的时间戳命名的，固定的单个IndexFile文件大小约为400M，一个IndexFile可以保存 2000W个索引，IndexFile的底层存储设计为在文件系统中实现HashMap结构，故rocketmq的索引文件其底层实现为hash索引。
消息刷盘
- 同步刷盘：只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性来说是一种不错的保障，但是性能上会有较大影响，一般适用于金融业务应用该模式较多。
- 异步刷盘：能够充分利用OS的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量。
Broker 角色
Broker角色分为ASYNC_MASTER(异步主机)、SYNC_MASTER(同步主机)以及SLAVE(从机)。
SYNC_MASTER(同步主机)：对信息的可靠性要求比较严格；
ASYNC_MASTER(异步主机)：对消息可靠性要求不高；
Broker 配置
| 参数名 | 默认值 | 说明 |
|---|---|---|
| listenPort | 10911 | 接受客户端连接的监听端口 |
| namesrvAddr | Null | nameServer地址 |
| brokerIP1 | 网卡的InetAddress | 当前broker监听的IP |
| brokerIP2 | 跟brokerIP1一样 | 存在主从broker时，如果在broker主节点上配置了brokerIP2属性，broker从节点会连接主节点配置的brokerIP2进行同步 |
| brokerName | null | broker的名称 |
| brokerClusterName | DefaultCluster | broker的名称 |
| brokerId | 0 | 0表示master，其他的正整数表示slave |
| storePathCommitLog | $HOME/store/commitlog/ | 存储 commit log 的路径 |
| storePathConsumerQueue | $HOME/store/consumequeue/ | 存储 consume queue 的路径 |
| mappedFileSizeCommitLog | 1024 * 1024 * 1024(1G) | commit log 的映射文件大小 |
| deleteWhen | 04 | 在每天的什么时间删除已经超过文件保留时间的 commit log |
| fileReservedTime | 72 | 以小时计算的文件保留时间 |
| brokerRole | ASYNC_MASTER | SYNC_MASTER/ASYNC_MASTER/SLAVE |
| flushDiskType | ASYNC_FLUSH | SYNC_FLUSH/ASYNC_FLUSH SYNC_FLUSH 模式下的 broker 保证在收到确认生产者之前将消息刷盘。ASYNC_FLUSH 模式下的 broker 则利用刷盘一组消息的模式，可以取得更好的性能。 |
nameSrv和Broker简单的架构图
</article>