思考：recoketMQ设计有何特点？
kafka和Rocketmq都是分布式的消息系统，在集群化部署方面，kafka通过zk进行节点协调，而rocketmq通过自身namesrv进行节点协调，所以在协调节点的设计上rocket显得更加轻，存储方面，在rocketmq中，采用的是混合型的存储结构，即为Broker单个实例下所有的队列共用一个日志数据文件（即为CommitLog）来存储，RocketMQ采用混合型存储结构的缺点在于，会存在较多的随机读操作，因此读的效率偏低。同时消费消息需要依赖ConsumeQueue，构建该逻辑消费队列需要一定开销。
主从备份方面：当生产者者向rocketmq写入消息时，会将数据写入集群中的相关master broker上，而每个master broker都有1到多个slave broker, 这样在一定程度上保证master出现了不可恢复的故障时，不丢失数据。 同时如果master宕机了，消费者会自动重连到相应的salve上，不会出现消费停滞，那么同时在master和slave数据同步分为同步复制(有一定的效率损失)和异步复制(数据不一致)
在生产和消费消息方面：在kafka中，每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic，物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处，而这种能力实现的底层我想应该就是通过zk来完成的。 在rocketmq中，NameSrv提供。
研究RocketMQ的一个切入点
其实RocketMQ这个技术一共是包含了四个核心的部分：
第一块就是他的NameServer，这个东西很重要，他要负责去管理集群里所有Broker的信息，让使用MQ的系统可以通过他感知到集群里有哪些Broker。
第二块就是Broker集群本身了，必须得在多台机器上部署这么一个集群，而且还得用主从架构实现数据多副本存储和高可用。
第三块就是向MQ发送消息的那些系统了，这些系统一般称之为生产者，这里也有很多细节是值得深究的，因为这些生产者到底是如何从NameServer拉取路由信息的？如何选择Broker机器建立连接以及发送消息的？
第四块就是从MQ获取消息的那些系统，这些系统一般称之为消费者。
仔细想想消费者里其实也隐藏了很多的技术细节，比如到底是Broker主动推送消息给消费者？还是消费者自己从Broke里拉取消息？这些也都很值得深究。
那么到底从哪儿入手开始呢？因为自己的思路是边研究边落地，最好是初步搞清楚一些RocketMQ的架构设计细节，然后就申请一些机器开始落地部署了，可以测试测试，然后尝试让一些生产系统开始使用他。
一次关于RocketMQ NameServer设计原理的技术分享
要部署RocketMQ，就得先部署NameServer，那么这个NameServer到底可以部署几台机器呢？
是一台机器？还是可以部署多台机器？如果部署多台机器，他们之间是怎么协同工作的。
NameServer，首先是支持部署多台机器的。也就是说，NameServer是可以集群化部署的。
那为什么NameServer要集群化部署？
最主要的一个原因，就是高可用性。
因为大家都知道，NameServer是集群里非常关键的一个角色，他要管理Broker信息，别人都要通过他才知道跟哪个Broker通信，所以没了他就会很麻烦！
那么如果NameServer就部署一台机器的话，一旦NameServer宕机了，岂不是会导致RocketMQ集群出现故障？
所以通常来说，NameServer一定会多机器部署，实现一个集群，起到高可用的效果，保证任何一台机器宕机，其他机器上的NameServer可以继续对外提供服务！
Broker是把自己的信息注册到哪个NameServer上去？
下一个问题：Broker在启动的时候是把自己的信息注册到哪个NameServer上去的？
有的人可能会猜测，是不是这样，比如一共有10台Broker机器，2个NameServer机器，然后其中5台Broker会把自己的信息注册到1个NameServer上去，另外5台Broker会把自己的信息注册到另外1个NameServer上去。
那么到底是不是这样呢？
答案是：不对
这样搞有一个最大的问题，如果1台NameServer上有5个Broker的信息，另外1个NameServer上有另外5个Broker的信息，那么此时任何一个NameServer宕机了，不就导致5个Broker的信息就没了吗？
所以这种做法是不靠谱的，会导致数据丢失，系统不可用。
因此正确答案是：每个Broker启动都得向所有的NameServer进行注册
也就是说，每个NameServer都会有一份集群中所有Broker的信息。
在这个图里就示范了一个Master Broker得向两台NameServer都进行注册的情况，这才是真正的情况。
系统如何从NameServer获取Broker信息？
扮演生产者和消费者的系统们，如何从NameServer那儿获取到集群的Broker信息呢？
他们需要知道集群里有哪些Broker，才能根据一定的算法挑选一个Broker去发送消息或者获取消息。
有两种办法：
第一种办法是这样，NameServer那儿会主动发送请求给所有的系统，告诉他们Broker信息。
这种办法靠谱吗？明显不靠谱，因为NameServer怎么知道要推送Broker信息给哪些系统？未卜先知吗？
第二种办法是这样的，每个系统自己每隔一段时间，定时发送请求到NameServer去拉取最新的集群Broker信息。
这个办法是靠谱的，没有什么明显的缺陷，所以RocketMQ中的生产者和消费者就是这样，自己主动去NameServer拉取Broker信息的。
顺便在这里解释一下，图里的路由信息，大致可以理解为集群里的Broker信息以及其他相关的数据信息
通过这些路由信息，每个系统就知道发送消息或者获取消息去哪台Broker上去进行了，这起到一个把消息路由到一个Broker上的效果，所以一般我们把这种信息叫做路由信息。
如果Broker挂了，NameServer是怎么感知到的？
下一个问题，现在一个Broker启动之后向NameServer注册了，每个NameServer都知道集群里有这么一台Broker的存在了，然后各个系统从NameServer那儿也拉取到了Broker信息，也知道集群里有这么一台Broker
但是如果之后这台Broker挂了呢？
要解决这个问题，靠的是Broker跟NameServer之间的心跳机制，Broker会每隔30s给所有的NameServer发送心跳，告诉每个NameServer自己目前还活着。
每次NameServer收到一个Broker的心跳，就可以更新一下他的最近一次心跳的时间。
然后NameServer会每隔10s运行一个任务，去检查一下各个Broker的最近一次心跳时间，如果某个Broker超过120s都没发送心跳了，那么就认为这个Broker已经挂掉了。
Broker挂了，系统是怎么感知到的？
下一个问题，如果Broker挂掉了，那么作为生产者和消费者的系统是怎么感知到的呢？难道必须得NameServer发送请求给所有的系统通知他们吗？
这个是不现实的，之前已经说过了，NameServer去发送这个东西非常的不靠谱。
但是如果NameServer没有及时通知给那些系统，那么有没有可能出现这样一种情况，刚开始集群里有10个Broker，各个系统从NameServer那里得知，都以为有10个Broker。
结果此时突然挂了一个Broker，120s没发心跳给NameServer，NameServer是知道现在只有9个Broker了。
但是此时其他系统是不知道只有9个Broker的，还以为有10个Broker，此时可能某个系统就会发送消息到那个已经挂掉的Broker上去，此时是绝对不可能成功发送消息的。
大家可以想一下，如果确实是那个情况，可以有两种解决办法。
首先，你可以考虑不发送消息到那台Broker，改成发到其他Broker上去。
其次，假设你必须要发送消息给那台Broker，那么他挂了，他的Slave机器是一个备份，可以继续使用，你是不是可以考虑等一会儿去跟他的Slave进行通信？
总之，这些都是思路，但是现在我们先知道，对于生产者而言，他是有一套容错机制的，即使一下子没感知到某个Broker挂了，他可以有别的方案去应对。
而且过一会儿，系统又会重新从NameServer拉取最新的路由信息了，此时就会知道有一个Broker已经宕机了。