RocketMQ系列（二）: 路由中心（NameServer）和消息服务（Broker）

消息中间件的架构设计：

消息中间件的设计思路一般基于 主题的订阅发布机制，
消息生产者（Produer）发送某一主题的消息到服务器，
消息服务器负责该消息的持久化存储，
消息消费者（Consumer）订阅感兴趣的主题，
消息服务器根据订阅消息（路由消息）将消息推送到消费者（Push模式）或者消息消费者主动向消息服务器拉取消息（Pull模式），
从而实现消息生产者与消息消费者解耦。

NameServer的功能

• 服务注册：
  • Broker在启动时向所有的NameServer心跳语句，每隔30S向所有NameServer发起心跳包。NameServer收到心跳包后更新缓存。NameServer每隔10S扫描brokerLiveTable，如果连续120S没有收到心跳包，则NameServer移除Broker的路由信息同时关闭Socket连接。
  • 用来保存所有topic和该topic所有队列的列表；
  • NameServer用来保存所有broker的Filter列表
  • 接收client（Producer和Consumer）的请求根据某个topic获取所有到broker的路由信息；
• 服务发现：
  • RocketMQ的路由发现是非实时的。当topic对应的路由信息发生变化，NameServer并不会通知给客户端。而是由客户端定时拉取Topic对应的最新路由。不实时的路由发现引起的问题由客户端进行解决，保证了NameServer逻辑的简洁。

为什么不用zookeeper

• zookeeper是apache旗下用于分布式服务协调的开源软件，并且拥有选举机制，能够在master宕机时从slave中通过选举机制选出一台slave变成master。但是在NameServer的设计中，MasterBroker中没有一台拥有全部的Topic信息，消息分布平均，失去选举机制意义。其次，NameServer仅仅被用于存储集群的配置信息、元数据信息，不需要太复杂的功能，所以放弃重量级的zookeeper选择轻量级的NameServer。

Broker

Broker消息存储

在Broker中存在着两个角色：CommitLog和ConsumeQueue。

• CommitLog：实际储存消息的物理文件。
• ConsumeQueue：消息队列，队列中储存的是待消费消息的地址偏移量，类似于索引。
  通过CommitLog和ConsumeQueue相互配合完成消息的存储。