架构篇 RocketMQ 的架构设计

取得成就时坚持不懈，要比遭到失败时顽强不屈更重要 —— 拉罗什夫科

消息的生产者，Producer通过MQ 的负载均衡模块选择相应的Broker集群队列进行消息投递，比如电商系统产生的订单消息。

RocketMQ 中的消息生产者都是以生产者组的形式出现的，生产者组是同一类生产者的集合，发送相同Topic类型的消息,一个生产者组可以同时发送多条消息

消息的消费者，消费者会从Broker中获取数据，进行后续的消息处理，比如从Broker中获取到订单信息，之后库存业务系统会根据订单中的商品进行对应的库存减少。

RocketMQ 中的消费者都是以消费者组出现的，消费者组是同一类消费者的集合，这类Consumer消费的是同一个Topic类型的消息，消费者组使得在消息消费方面实现负载均衡【将一个Topic中的不同的Queue平均分配给同一个Consumer Group的不同的Consumer，注意，并不是将消息负载均衡】和容错【一个Consmer挂了，该Consumer Group中的其它Consumer可以接着消费原Consumer消费的Queue】

消费者组中的消费者Consumer的数量应该小于等于订阅的Topic中的Queue的数量，如果超出Queue数量，那么多出来的消费者Consumer 将不会工作。

一个类型的Topic类型的消息可以被多个消费者组同时消费，消费者组只能消费一个Topic的消息，不能同时消费多个Topic的消息，一个消费者组中的消费者必须订阅完全相同的Topic

路由中心，主要保存的是Broker和Topic的关系，支持Broker的动态注册和发现

每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。

Name Server 集群中每个节点是不互相通信的，每个节点都保存了全部的Broker集群的信息。

那么每个节点中的数据是如何进行保持数据的最终一致性呢？

Broker 在启动的时候会轮询Name Server集群列表，与每个Name Server进行长连接建立，发起注册请求，在Name Server 内部维护着一个Broker 列表，用来动态存储Broker信息【内存存储】

缺点：

Broker 必须知道所有的Name Server地址，否则注册不了，并且Name Server不能随便扩容，因为Name Server 扩容Broker 并不知道。

优点：

部署简单

Broker节点为了证明自己是活着的，为了维护与NameServer间的长连接，会将最新的信息以心跳包的方式上报给NameServer，每30秒发送一次心跳。心跳包中包含 BrokerId、Broker地址(IP+Port)、 Broker名称、Broker所属集群名称、Broker中所有的Topic信息等等。NameServer在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间

由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。NameServer中有⼀个定时任务，每隔10秒就会扫描⼀次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除

RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由

推送模型。其实时性较好，是一个“发布-订阅”模型，需要维护一个长连接。而长连接的维护是需要资源成本的，使用场景：Client数量不多，Server数据变化较频繁

拉取模型。存在的问题是，实时性较差

客户端选择策略【生产者和消费者】，客户端在配置时必须要写上NameServer集群的地址，那么客户端到底连接的是哪个NameServer节点呢？

客户端首先会生产一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的节点索引，然后就会进行连接。如果连接失败，则会采用round-robin策略，逐个尝试着去连接其它节点。

首先采用的是随即策略，如果随机策略失败，那么采用的是轮询策略

消息中转站，负责存储消息和转发消息，Broker 在RocketMQ 中负责接收并存储从生产者发来的消息，同时为消费者的拉取做准备，Broker 同时也存储消息相关的元数据，包括消费者组的消费进度偏移offset【集群消费的场景下】、主题、队列等等。

启动NameServer，NameServer启动后开始监听端口，等待Broker、Producer、Consumer连接

启动Broker时，Broker会与所有的NameServer建立并保持长连接，然后每30秒向NameServer定时发送心跳包

发送消息前，可以先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中。不过，这步是可选的，也可以在发送消息时自动创建Topic。

手动创建Topic 有两种模式：

注意：自动创建Topic时，默认采用的是Broker模式，会为每个Broker默认创建4个Queue。

Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic消息的Queue与Broker的地址（IP+Port）的映射关系。然后根据算法策略从队选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然，在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息。

Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer更新一次路由信息。不过不同于Producer的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。