参考：https://blog.csdn.net/wwwwwww31311/article/details/118612674
它由四个部分组成:name servers, brokers, producers 和 consumers
名称服集群务 NameServer cluster
NameServer服务提供了轻量级的服务发现和路由。每个NameServer服务记录完整的路由信息，提供一致的读写服务，支持快速存储扩展，支持集群搭建。
broker 管理，nameserver 接受来自broker集群的主动上传的注册信息并提供心跳来检测他们是否可用。
路由管理 每一个nameserver都持有关于broker集群和队列的全部路由信息，用来向客户端提供查询。
NameServer本身是无状态的，也就是说NameServer中的Broker、Topic等状态信息不会持久存储，都是由各个角色定时上报并 存储到内存中的
①单个Broker跟所有Namesrv保持心跳请求，心跳间隔为30秒，心跳请求中包括当前Broker所有的Topic信息。Namesrv会反查Broer的心跳信息， 如果某个Broker在2分钟之内都没有心跳，则认为该Broker下线，调整Topic跟Broker的对应关系。但此时Namesrv不会主动通知Producer、Consumer有Broker宕机。②Consumer跟Broker是长连接，会每隔30秒发心跳信息到Broker。Broker端每10秒检查一次当前存活的Consumer，若发现某个Consumer 2分钟内没有心跳， 就断开与该Consumer的连接，并且向该消费组的其他实例发送通知，触发该消费者集群的负载均衡(rebalance)。③生产者每30秒从Namesrv获取Topic跟Broker的映射关系，更新到本地内存中。再跟Topic涉及的所有Broker建立长连接，每隔30秒发一次心跳。 在Broker端也会每10秒扫描一次当前注册的Producer，如果发现某个Producer超过2分钟都没有发心跳，则断开连接。
Namesrv压力不会太大，平时主要开销是在维持心跳和提供Topic-Broker的关系数据。但有一点需要注意，Broker向Namesrv发心跳时， 会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话， 网络传输失败，心跳失败，导致Namesrv误认为Broker心跳失败。
基于以上的功能，producor向rocketmq发生消息时首先时首先经过namesrv，由于namesrv有完整的broker信息和实时状态，可以根据默认或者producor自定义的上传策略将消息写入broker的master类型的服务器中，同理consumer也是根据namesrv安装一定策略从salve类型的broker服务器中取到数据，
所以，所以再master broker，salve broker，producor，consumer这四者中都要配置namesrv的ip+port信息。namesrv协调整个消息传输过程
代理服务集群 Broker Cluster
Broker通过提供轻量级主题和队列机制来处理消息存储。它们支持Push和Pull模型，包含容错机制(2个副本或3个副本)，提供了极强的峰值处理里能力和按照时间顺序存储数以百万记的消息存储能力，此外，代理提供了灾难恢复、丰富的度量统计和警报机制，这些都是在传统的消息传递系统中缺乏的，
它(master)接受并存储来自生产者发送的消息，(slave)出来来自消费者的拉取请求。它也存储和消息有关的信息，包括消费者组，消费位置还有主题队列的信息,Brokers可以按照类别分成两类：master 和slave.，master同时提供读写服务，slave只提供读服务。要部署一个没有单点故障的高可用集群，需要部署多个broker。一个broker集群需要有一个brokerId为0的master和多个brokerId不为0的slave。这个broker集群的主从需要配置相同的brokerName，极端情况下，我们需要保证一个broker集群中至少部署两台brokers服务，每个topic都存在于两个或多个broker中。
生产者集群 Producer Cluster
produce支持分布式部署，分布式的produce通过broker集群提供的各种负载均衡策略将消息发送到broker集群中。发送过程支持快速失败是低延迟的。
消费者集群 Consumer Cluster
消费者也支持在推送和者拉取模式下分布式部署，它还支持集群消费和消息广播。提供实时的消息订阅机制，能够满足大多数消费者的需求
集群工作流程
启动namesrv，然后namsrv等待broker，producor，conusmer等来连接，namesrv是管理者，具有路由和状态监控的作用。
broker启动，跟所有的namesrv集群的namesrv服务器建立长连接，定时向namesrv集群的每个服务器发送心跳包（ip+prot+存储的topic信息），注册成功后namesrv上就有了topic跟broker的映射信息，注意，javaAPI中producor首次发送信息时没有指定topic和broker对应关系时是轮询传输到集群中的master服务器上，当下次重新启动集群时，会通过broker的信息上传在namesrv建立topic和broker的对应关系
消息发送前可以先建立topic，并手动指定topic和broker的对应关系，也可以在发消息时自动指定消息的topic，这种情况参考上一点
producor发送消息，与namesrv集群建立长连接，然后从namesrv哪里得知目标topic所在的broker服务器，每次发送消息轮询从队列链表中选择一个队列，与先关的broker服务器建立连接后向broker发送消息
consumer启动，与namesrv建立长连接，然后从namesrv哪里得知自己订阅的服务器消息也就是topic存在于那台服务器上，然后直接和broker建立连接来消费消息；
启动rockmq
[root@bogon /]# cd /usr/local/java/rocketmq/bin
[root@bogon bin]# nohup sh mqnamesrv & #启动namesrv
[root@bogon bin]# tail -f ~/logs/rocketmqlogs/namesrv.log #查看日志
[root@bogon bin]# nohup sh broker - n 公网ip -c conf/broker.conf autoCreateTopicEnable=true & #启动broker
[root@bogon bin]# tail -f ~/logs/rocketmqlogs/broker.log #查看日志
//第一次启动前需要编辑runbroker.sh和runserver.sh 修改默认JVM大小
[root@bogon bin]# vi runbroker.sh
[root@bogon bin]# vi runserver.sh
启动broker集群
nohup sh mqbroker -c /usr/local/java/rocketmq/conf/2m-2s-sync/broker-a-s.properties &
关闭集群
sh mqshutdown namesrv
sh mqshuconsumequeuetdown broker
查看集群状态
./mqadmin clusterList -h
./mqadmin clusterList -n nameserver1:9876
./mqadmin clusterList -n nameserver1:9876 -m
./mqadmin clusterList -n nameserver1:9876 -m -i 10
./mqadmin clusterRT -n nameserver1:9876 -c CLUSTERNAME -s 10 -a 1
