[大数据]RocketMq学习笔记【原理 + 实践 + 实现代码】（持续更新中）

***限流削峰***
MQ可以将系统的超量请求暂存其中以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统被压垮。

***异步解耦***
上游系统对下游系统的调用若为同步调用，则会大大降低系统的吞吐量与并发度，且系统耦合度太高。而异步调用则会解决这些问题。所以两层之间若要实现由同步到异步的转换，一般做法就是，在这两层间添加一个MQ层。

***数据收集***
分布式系统会产生海量级数据流，如：业务日志、监控数据、用户行为等。针对这些数据进行实时或批量采集汇总，然后对这些数据进行大数据分析，这是当前互联网平台的必备技术。通过MQ完成此类数据手机是最好选的选择。

***RabbitMQ***
RabbitMQ是使用ErLang语言开发的一款MQ产品。其吞吐量较Kafka与RocketMQ要低，且由于其不是Java语言开发，所以公司内部对其实现定制开发难度较大。

***Kafka***
Kafka时使用Scala/Java语言开发的一款MQ产品。其最大的特点就是高吞吐率，常用于大数据领域的实时计算、日志采集等场景。其没有遵循任何常见的MQ协议，而是使用自研协议。对于Spring Cloud Netflix,其仅支持RabbitMQ与Kafka。

***RocketMQ***
RocketMQ是使用Java语言开发的一款MQ产品，经过数年阿里双11的考验，性能与稳定性非常高。其没有遵循任何常见的MQ协议，而是使用自研协议。对于Spring Cloud Alibaba，其支持RabbitMQ、Kafka，但提倡使用RocketMQ。

1. JMS:
   java messageing service(java消息服务),是Java平台上面有关MOM(message originted middleware)面向消息中间件的技术规范,便于java应用程序进行消息交换,并且提供标准的产生,发送,接受信息的接口,适用于ActiveMQ,现在市场上已经不再使用ActiveMQ进行维护产品了,发稿时间为2021年7月22日12:58:42
2. STOP:
   面向文本的消息协议,也是MOM设计的简单文本协议,STOP提供一种可以互操的连接方式,允许客户与任意的STOP消息代理进行连接,也是ActiveMQ的典型实现,RabbitMQ可以通过插件实现
3. AMQP:
   高级消息队列协议提供消息服务的应用层标准,也是MOM设计,不受是不是同一产品,统一语言的限制,是RabbitMQ的典型实现
4. MQTT:
   是IBM开发的一个及时通讯协议,二进制协议,主要用服务器或者低功效的,服务器与物联网的连接协议.通过插件RabbitMQ,且支持所有平台,非常广泛
5. 目前较火的kafka 和RocketMQ不使用以上协议,而是自主研发的协议

整体的架构设计主要分为四大部分，分别是：Producer、Consumer、Broker、NameServer。

• Producer：消息生产者，可以集群部署。会先和 NameServer 集群中的随机一台建立长连接，得知当前要发送的 Topic 存在哪台 Broker Master上，然后再与其建立长连接，定时向Broker发送心跳。同时支持多种负载平衡模式发送消息。
• Consumer：消息消费者，可以集群部署。会先和 NameServer 集群中的随机一台建立长连接，得知当前要消息的 Topic 存在哪台 Broker Master、Slave上，然后它们建立长连接，定时向Broker发送心跳。同时支持集群消费和广播消费消息。
• Broker：主要负责消息的存储、查询消费，支持主从部署，一个 Master 可以对应多个 Slave。Master 支持读写，Slave 只支持读。Broker 会向集群中的每一台 NameServer 注册自己的路由信息。定期30s向NameServer上报Topic路由信息。
• NameServer：是Topic 路由注册中心，支持 Broker 的动态注册和发现，保存 Topic 和 Borker 之间的关系。也是集群部署，但是各 NameServer 之间不会互相通信， 各 NameServer 都有完整的路由信息，即无状态。

• Topic ： 表示一类消息的集合，每个注意包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。
• Queue：存储消息的物理实体。一个Topic中可以包含多个Queue，每个Queue中存放的就是该Topic的消息。一个Topic的Queue也被称为一个Topic中消息的分区。

Topic中每一个Queue消息只能被一个消费组中的消费者消费

• Producer : 消息生产者，负责生产并发送消息。
• Consumer : 消息消费者，负责接收并消费消息。根据消费方式分为两类：

Push Consumer：消息由消息队列推送至Consumer。 Pull
Consumer：Consumer主动从消息队列拉取消息。可以一次拉取固定数量消息，防止Consumer打垮。

• Group：生产组（Producer Group）或消费组（Consumer Group），Producer或Consumer通常生产或消费同一类消息，且消息发布或订阅的逻辑一致。这样可以实现负载均衡和容错策略。
• Tag ： 消息标签，二级消息类型，可以对Topic下消息进一步分类。
• Message ID：RocketMQ中每个消息拥有唯一的MessageId，且可以携带具有业务标识的Key，以方便对消息的查询。不过需要注意的是，MessageId有两个：在生产者send()消息时会自动生成一个MessageId(msgId)，当消息到达Broker后，Broker也会自动给生成一个MessageI(offsetMsgId)。msgId、offsetMsgId与key都称为消息标识。
• Message Key：消息业务标识Key，可以通过Key进行Hash打到相同消息队列中。
• Message： 消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。
• offset：偏移量可以认为就是消息下标。offset是long 类型，不会溢出。
• 集群消费：相同Group 的消费组下的所有Consumer平分消费消息。
• 广播消费：所有Consumer都会消费消息，保证消息至少被每个消费者消费一次。但不会重发消费消息失败需要业务方关注。
• 延迟消息：生产端设定一个时间点，消费端并不立即消费到，直到设定的时间点后消费端才收到消息。现阶段只支持时间级别，后续会支持自定义时间点。
• 事务消息：通过消息队列事务消息能达到分布式事务的最终一致。
• 顺序消息：消息生产端按照指定的Sharding Key发送消息时进行分区，消费端则按照消息的发送时间先后顺序消费。
• 消息堆积：Producer生产消息后，消费端由于处理能力慢或者其他因素导致消息没有被及时消费掉。业务方可以基于消息堆积进行监控告警，可以扩容消费端或者限制发送消息速率。
• 消息过滤：根据消息Tag标签进行过滤，只接受符合条件的消息。消费者订阅消息支持多种方式包括运算符,等于null或者*，则表示全部订阅。
• 消息轨迹：一条消息从Producer发出到Consumer消费处理过程中，由各个相关节点的时间、ip等数据汇聚而成的完整链路信息。通过消息轨迹，您能清晰定位消息从Producer发出，经由消息队列服务端，投递给Consumer的完整链路，方便定位排查问题。

主要包括两个功能：

• Broker管理：接收Broker集群的注册信息并保存下来作为路由信息的基本数据；提供心跳检测机制，检查Broker是否还存活。
• 路由信息管理：每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。Producer和Conumser通过NameServer可以获取整个Broker集群的路由信息，从而进行消息的传递和消费。

路由注册

NameServer通常也是以集群的方式部署，不过NameServer是无状态的，即NameServer集群中的各个节点间是无差异的，各节点间相互不进行信息通讯。那各个节点中的数据是如何进行数据同步的呢？
在Broker节点启动时，轮询NameServer列表，与每个NameServer节点建立长连接，发起注册请求。在NameServer内部维护着一个Broker列表，用来动态存储Broker的信息。
Broker节点为了证明自己是活着的，为了维护与NameServer间的长连接，会将最新的信息以心跳包的方式上报给NameServer，每30秒发送一次心跳。心跳包中包含BrokerId,Broker地址（IP-Port）、Broker名称、Broker所属集群名称等等。NameServer在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间。

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

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

这里的客户端指的是Product与Consumer
客户端在配置时必须要写上NameServer集群的地址，那么客户端到底连接的是哪个NameServer节点呢？客户端首先会生成一个随机数，然后再与NameServer节点数量取模，此时得到的就是索要连接的节点索引，然后就会进行连接。如果连接失败，则会采用round-robincelve，逐个尝试着去连接其它节点。
首先采用的是随机策略进行的选择，失败后采用的是轮询策略。

• 功能介绍：
  Broker充当着消息中转角色，负责存储消息、转发消息。Broker在RockerMQ系统中负责接收并存储从生产者发送来的消息，同时为消费者的拉取请求作准备。Broker同时也存储着消息相关的元数据，包括消费者组消费进度偏移offset、主题、队列等。
• 模块构成：
  

● SocketServer内部开启1个Acceptor线程接受对外的sock链接，然后转发给N个处理线程Processor，其中N=num.network.threads

● N个Processor将接受到的request存放至阻塞队列requestQueue

● M个处理线程 IO Thread从RequestChannel的请求阻塞队列requestQueue获取请求，调用kafkaApis处理不同的请求，M=num.io.threads

● Broker共处理10种不同的request，分别为RequestKeys.ProduceKey、RequestKeys.FetchKey、RequestKeys.OffsetsKey、RequestKeys.MetadataKey 、RequestKeys.LeaderAndIsrKey、RequestKeys.StopReplicaKey、

RequestKeys.UpdateMetadataKey、RequestKeys.ControlledShutdownKey、RequestKeys.OffsetCommitKey、RequestKeys.OffsetFetchKey。

● KafkaApis（业务逻辑处理层）通过ReplicaManager（副本管理模块），logManager（日志模块），OffsetManager（偏移量管理模块）共同实现正常的业务逻辑

● IO Thread将request处理过的response存放进RequestChannel的响应阻塞队列responseQueues[i]

● Processor Thread从对应的RequestChannel的响应阻塞队列responseQueues[i]获取之前自己发送的request，然后发送给客户端

● Control（集群状态控制层）通过ZK选举改变自身的状态，集群中只有1台broker成为leader，主要负责应对topic的创建和删除，topic的分区变化，topic的分区内部的复本变化，broker的上下线。

● KafkaHealthcheck（Broker 健康状态监测层）通过在ZK上注册EphemeralPath来实现

● TopicConfigManager（topic配置信息监控层）主要响应topic的配置信息的变化

十一、集群部署（原理）

• 为了增强Broker性能与吞吐量，Broker一般都是以集群形式出现的。各集群节点中可能存放着相同Topic的不同Queue。不过，这里有个问题，如果某个Broker节点宕机，如何保证数据不丢失呢？其解决方案是，将每个Broker集群节点进行横向扩展，即将Broker节点再建为一个HA集群，解决单点问题。
• Broker节点集群是一个主从集群，即集群中具有Master与Slave两种角色。Master负责处理读写操作请求，Slave负责对Master中的数据进行备份。当Master挂掉了，Slave则会自动切换为Master去工作，所以这个Broker集群是主备集群。一个Master可以包含多个Slave，但一个Slave只能隶属于一个Master。Master与Slave的对应关系是通过指定相同的BrokerName、不同的BrokerId来确定的。BrokerId为0表示Master，非0表示Slave。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。

1. 启用NameServer，NameServer启动后开始监听端口，等待Broker、Producer、Consumer连接。
2. 启动Broker时，Broker会与所有的NameServer建立并保持长连接，然后每30秒向NameServer定时发送心跳包。
3. 发送消息前，可以先创建Topic，创建Topic时需要指定该Topic要存处在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中。不过，这步是可选的，也可以在发送消息时自动创建Topic。
4. Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic消息的Queue与Broker的地址(IP-Port)的映射关系。然后根据算法策略从队列中选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息。
5. Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消息的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer更新一次路由信息。不过不用于Producer的是，Consumer还会向Broker发送信息条，以确保Broker的存活状态。

手动创建Topic时，有两种模式：

• 集群模式：该模式下创建的Topic在该集群中，所有Broker中的Queue数量是相同的。
• Broker模式：该模式下创建的Topic在该集群中，每个Broker中的Queue数量可以不同。

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

读/写队列
从物理上来讲，读/写队列是同一个队列。所以，不存在读/写队列数据同步问题。读/写队列是逻辑上进行区分的概念。一般情况下，读/写队列数量是相同的。

例如：创建Topic时设置的写队列数量为8，读队列数量为4，此时系统会创建8个Queue，分别时 
0 1 2 3 4 5 6 7 Producer会将消息写入到这8个队列，但Consumer只会消费 0 1 2 3 这4个
队列中的消息，4 5 6 7中的消息是不会被消费到的。此时假设Consumer Group中包含Consuer
，Cconsumer1消费 0 1 2 3，而Consumer2消费 4 5 6 7。但实际情况是，Consumer2是没有消
息可消费的。

也就是说，当读/写队列数量设置不同时，总是有问题的。那么，为什么要这样设计呢？

其实这样设计的目的是为了，方便Topic中Queue的缩容。

例如：原来创建的Topic中包含16个Queue，如何能够使其Queue缩容为8个，还不会丢失消息？
可以动态修改写队列数量为8，读队列数量不变。此时新的消息只能写入到前8个队列，而消费者消
费的却是16个队列中的数据。当发现后8个Queue中的消息消费完毕后，就可以将读队列数量动
态设置为8。整个缩容过程，没有丢失任何消息。

准备一台虚拟机，并再克隆出一台。

修改两台虚拟机IP地址，方便后面搭建集群。

第一台服务器

• 设置静态IP地址与动态iIP差不多，也是要修改网卡配置文件

• vi /etc/sysconfig/network-scripts/ifcfg-ens33 (最后一个为网卡名称)

• bootproto=static

• onboot=yes

• 在最后加上几行，IP地址、子网掩码、网关、dns服务器

• IPADDR=192.168.1.163
  NETMASK=255.255.255.0
  GATEWAY=192.168.1.1
  DNS1=119.29.29.29
  DNS2=8.8.8.8

• （4）重启网络服务
  systemctl restart network
  

  第二台服务器

• 设置静态IP地址与动态iIP差不多，也是要修改网卡配置文件

• vi /etc/sysconfig/network-scripts/ifcfg-ens33 (最后一个为网卡名称)

• bootproto=static

• onboot=yes

• 在最后加上几行，IP地址、子网掩码、网关、dns服务器

• IPADDR=192.168.1.164
  NETMASK=255.255.255.0
  GATEWAY=192.168.1.1
  DNS1=119.29.29.29
  DNS2=8.8.8.8

• （4）重启网络服务
  systemctl restart network
  
  查看JDK版本

• Java -version
  
  官网下载RocketMQ
  RocketMQ官网
  通过Xftp 6将文件上传到虚拟机linux服务器中。

命令：unzip rocketmq-all-4.9.1-bin-release.zip 解压压缩包

• 修改runserver.sh（克隆服务器也要修改）
  使用vim命令打开bin/runserver.sh文件。将这些值修改为如下：
  
• 修改runbroker.sh（克隆服务器也要修改）
  使用vim命令打开bin/runbroker.sh文件。将这些值修改为如下：
  

在rocketMQ根目录下使用下面命令：

• nohup sh bin/mqnamesrv & （启动nameserver）
• nohup sh bin/mqbroker -n localhost:9876 & （启动Broker）

• export NAMESRV_ADDR=localhost:9876
• sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer （发送）
  
• sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer （接收）
  
• sh bin/mqshutdown broker （关闭 Broker）
• sh bin/mqshutdown namesrv （关闭NameServers）

下载：下载地址
配置：配置方式地址

1. 数据复制与刷盘策略
   复制策略：复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制和异步复制：

   同步复制：消息写入master后，master会等待slave同步数据成功后才向producer返回成功ACK。
   异步复制：消息写入master后，master立即向producer返回成功ACK，无需等待slave同步数据成功。
   异步复制策略会降低系统的写入延迟，RT变小，提高了系统的吞吐量。
   

   刷盘策略：刷盘策略指的是broker中消息的落盘方式，即消息发送到broker内存后消息持久化到磁盘的方式。分为同步刷盘与异步刷盘：

   同步刷盘：当消息持久化到broker的磁盘后才算是消息写入成功。
   异步刷盘：当消息写入到broker的内存后及表示消息写入成功，无需等待消息持久化到磁盘。
   异步刷盘策略会降低系统的写入延迟，RT变小，提高了系统的吞吐量。
   消息写入到Broker的内存，一般是写入到了PageCace。
   对于异步刷盘策略，消息会写入到PageCache后立即返回成功ACK。但并不会立即做落盘操作，而是当PageCache到达一定量时会自动进行落盘。
   

2. Broker集群模式
   根据Broker集群中各个节点间关系的不同，Broker集群可以分为以下几类：

   单Master
   只有一个broker（基本上就不能称为集群）。这种方式也只能是在测试时使用，生产环境下不能使用，因为存在单点问题。

   多Master
   Broker集群仅由多个master构成，不存在Slave。同一个Topic的各个Queue会分布在各个master节点上。

   优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息不会丢失（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。
   缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅（不可消费），消息实时性会受到影响。
   以上优点的前提是，这些Master都配置了RAID磁盘阵列，如果没有配置，一旦出现某Master宕机，则会发生大量消息丢失的情况。
   

   多Master多Slave模式-异步复制
   broker集群由多个master构成，每个master又配置了多个slave（在配置了RAID磁盘阵列的情况下，一个master一般配置一个slave即可）。master与slave的关系是主备关系，即master负责处理消息的读写请求，而slave仅负责消息的备份与master宕机后的角色切换。

   异步复制即前面所讲的复制策略中的异步复制策略，即消息写入master成功后，master立即向producer返回成功ACK，无需等待slave同步数据同步成功。

   该模式最大特点之一是，当master宕机后slave能够自动切换为master。不过由于slave从master的同步具有短暂的延迟（毫秒级），所以当master宕机后，这种异步复制方式可能会存在少量消息的丢失问题。

   Slave从Master同步的延迟越短，其可能丢失的消息久越少。
   对于Master的RAID磁盘阵列，若使用的也是异步复制策略，同样也存在延迟问题，同样也可能会丢失消息。但RAID阵列的秘诀是微秒级的（因为是由硬盘支持的），所以其丢失的数据量会更少。
   

   多Msater多Slave模式-同步双写
   该模式是多Master多Slave模式的同步复制实现。所谓同步双写，指的是消息写入master成功后，master会等待slave同步数据成功后才向prioducer返回成功ACK，即master与slave都要写入成功后才会返回成功ACK，也即双写。

   该模式与异步复制模式相比，优点是消息的安全性更高，不存在消息丢失的情况。但单个消息的RT略高，从而导致性能要略低（大约低10%）。

   该模式存在一个大的问题：对于目前的版本，Master宕机后，Slave 不能自动切换到 Master。

   最佳实践
   一般会为Master配置RAID10磁盘阵列，然后再为其配置一个Slave。即利用了RAID10磁盘阵列的高效，安全性，又解决了可能会影响订阅的问题。

   RAID磁盘阵列的效率要高于Master-Slave集群。因为RAID是硬件的支持。也正因如此，所以RAID阵列的搭建成本较高。
   多Master+RAID阵列，与多Master多Slave集群的区别是什么？
   多Master+RAID阵列，其仅仅可以保证数据不丢失，即不影响消息写入，但其可能会影响到消息的订阅。但其效率要远高于多Master多Slave集群
   多Master多Slave，其不仅可以保证数据不丢失，也不会影响消息写入。其运行效率要低于多Master+RAID阵列。
   

1. RAUD历史
   
2. RAID等级
   
3. 关键技术
   
   
   
4. RAID分类
   
5. 常见RAID等级详解
   
   
   这块后续知识可自行百度。。。。。。。。。。。。。。

1. 集群架构
   这里要搭建一个双主双从异步复制的Broker集群。为了方便，这里使用了两台主机来完成集群的搭建。这两台主机的功能与broker角色分配如下表。
   

2. 克隆生成linux虚拟机2。
   并修改两台虚拟机的IP地址。

3. 进入rocketMQ中有官方给的配置信息。
   

    2m-2s-async     双主双从异步
    2m-2s-sync      双主双从同步
    2m-noslave      双主
    deldger         单机模式
   

4. 修改broker-a.properties(虚拟机1)
   

5. 修改broker-b-s.properties
   

6. 修改broker-b.properties(虚拟机2)
   

7. 修改broker-a-s.properties
   

8. 启动服务器
   启动NameServer集群
   分别启动rocketmqOS1与rocketmqOS2两个主机中的NameServer。启动命令完全相同。

    在rocketMQ的bin目录下：
    nohup sh ./mqnamesrv  &
   

9. 启动两个Master
   分别启动rocketmqOS1与rocketmqOS2两个主机中的broker master。注意，它们指定所要加载的配置文件是不同的。

    虚拟机1：nohup sh mqbroker -c ../conf/2m-2s-async/broker-a.properties &
    虚拟机2：nohup sh mqbroker -c ../conf/2m-2s-async/broker-b.properties &
   

10. 启动两个Slave

    虚拟机1：nohup sh mqbroker -c ../conf/2m-2s-async/broker-b-s.properties &
    虚拟机2：nohup sh mqbroker -c ../conf/2m-2s-async/broker-a-s.properties &
    

11. 启动控制台

注意：一定要给虚拟机放通9876端口 或 关闭防火墙

server.contextPath=
server.port=7000
#spring.application.index=true
spring.application.name=rocketmq-console
spring.http.encoding.charset=UTF-8
spring.http.encoding.enabled=true
spring.http.encoding.force=true
logging.config=classpath:logback.xml
#if this value is empty,use env value rocketmq.config.namesrvAddr  NAMESRV_ADDR | now, you can set it in ops page.default localhost:9876
#修改这里连接两台虚拟机
rocketmq.config.namesrvAddr=192.168.1.163:9876;192.168.1.164:9876
#if you use rocketmq version < 3.5.8, rocketmq.config.isVIPChannel should be false.default true
rocketmq.config.isVIPChannel=
#rocketmq-console's data path:dashboard/monitor
rocketmq.config.dataPath=/tmp/rocketmq-console/data
#set it false if you don't want use dashboard.default true
rocketmq.config.enableDashBoardCollect=true

12. 成功
    

	1 消息的生产过程
	Producer可以将消息写入到某Broker中的某Queue中，其经历了如下过程：
	
	Producer发送消息之前，会先向NameServer发出获取消息Toic的路由信息的请求。
	NameServer返回该Topic的路由表及Broker列表。
	Producer根据代码中指定的Queue选择策略，从Queue列表中选出一个队列，用于后续存储信息。
	Producer对消息做一些特殊处理，例如，消息本身超过4M，则会对其进行压缩。
	Producer向选择出的Queue所在的Broker发出RPC请求，将消息发送到选择出的Queue。

	路由表：实际是一个Map，key为topic名称，value是一个QueueData实例列表。QueueData并不是一个Queue对应一个QueueData，而是一个Broker中该Topic的所有Queue对应一个QueueData。即，只要涉及到该Topic的Broker，一个Broker对应一个QueueData。QueueData中包含brokerName。简单来说，路由表的key为Topic名称，value则为所有涉及该Topic的BrokerName列表。
	Broker列表：其实际也是一个Map，key是brokerName，value是BrokerData。一个Broker对应一个BrokerData实例，对吗？不对。一套brokerName名称相同的Master-Slave小集群对应一个BrokerData。BrokerData中包含brokerName及一个map。该map的key为brokerId，value为该broker对应的地址。brokerId为0表示该broker为Master，非0表示Slave。