2019-09-20优点: nameserver本身设计为无状态，实现简单，
缺点: broker客户端通信成本复杂，适合在客户端环境完全可控的情况下设计。namesrv 一致性无法保证，需要定时幂等性心跳保持最终一致性。 1 4
2019-09-19NamingService集群有点像去中心化的结构设计，每个节点保存所有数据，很好的保证了节点的可用性，但每个节点之间不互相通信，很难确保节点间的数据一致性。想问下老师主题(和其中队列)在broker节点的分布情况是怎样的作者回复: 主题和队列是分散到所有Broker节点上的，每个Broker只保存自己负责的那部分主题和队列信息。并且实际上在集群中，元数据最终是以Broker上保存的信息为准的。
2
2019-09-17线上环境突发消息延迟2个小时，该如何尽快解决？以及后期如何避免这类问题？说说你的思路和经验！作者回复: 这个我在之前的课程中讲到过，首先需要先看一下是消费慢还是生产慢，如果是生产慢，一般需要扩容Producer的节点数量，如果是消费慢，需要扩容队列数和Consumer数量。
2
2019-11-17优点：实现简单，集群节点平等，比较容易的水平扩展节点数量提供高可用性。路由数据读写都是内存，QPS比较高。
缺点：每个 broker 需要与所有 nameserver 节点心跳通信，通信成本较大，无法保证强一致性。 1- 2019-10-25老师，我们生产环境。同一个group，多台机器消费同一个topic消息，遇到了某几个实例消费的分区延迟特别高，导致消息堆积的情况。但另外几个实例消费的分区并没有堆积。这通过扩容consumer也没法解决。而且很难排查，有什么好的方式吗
作者回复: 一是查一下每个分区入队速度是不是均匀，另外在消费者加一个消费监控（记录每次消费的时延）看一下消费速度是不是有问题。
1 
2019-09-17nnameserver各个节点独立不通信，是ap的思路。
各个节点总是可用，但是节点之间不通信，有可能由于网络原因，某个节点的路由信息可能会不一致。
客户端拉去所有节点的路由信息，可以弥补某个节点路由信息不一致的情况。 1- 2019-11-17请问下老师，如果 nameserver 有节点重启了或是新加了一个节点，恢复内存中的路由数据过程是通过 broker 的心跳上报路由信息重新注册一遍吗？
作者回复: 是的，RocketMQ的NameServer数据是以Broker上的为准，并且是从Broker上同步过来的。
2019-11-01优点是性能高，Broker只需关心单个节点，而不需要关注集群状态，客户端只需要和一个NameServer打交道，不用关心集群状态。
缺点是不能保证一致性
2019-10-25nameserver服务感觉跟注册中心有点像- 2019-10-25nameServer本身某几个实例挂了，会怎么处理呢
作者回复: 挂了也不影响集群正常使用，尽快修复就好了
2019-10-24优点：
1:Nameserver高可用，节点之间无状态，减少节点同步逻辑，非常轻量级。
缺点：
1:牺牲了一致性。两个nameserver数据不一致，导致消息数据倾斜
2019-10-12请问一下老师，如果namingServer集群的各节点在多机房部署，如果一个机房与所有broker的通信中断了，那这个节点的namingServer上的信息就与其他namingServer不一致了，出现这种情况怎么办？作者回复: 实际上，RocketMQ的路由数据是以Broker为准的，所以不会存在数据不一致的情况。由于NameServer与Broker有心跳机制，在这种发生网络隔离情况下，每个NameServer上就只有它可以连通的那些Broker的路由数据了。这也符合实际情况。
1
2019-09-29还有个缺点是NameService不支持写扩展，增加服务节点无法水平扩展，让我想起了zookeeper。不知道理解是否正确。
2019-09-19对于rocketmq和kafka而言，都有自己的“注册中心”，但对于rabbitmq而言，它的集群允许你连接到集群中的任何一台进行生产消费，即便队列master所在节点并不是你连接的这台，rabbitmq内部会帮你进行中转，但这会有一个很大的弊端，就是节点间会有较大的流量并且不可控，并且整体的性能会受影响
想请问下，这种时候，是否有较好的优化方式？
想到的一个办法是，自行做一个NameServer，按队列进行注册分流，生产者消费者先与NameServer交互得到真实的节点ip，然后直接连接到队列master所在节点进行生产消费作者回复: 理论上是可以的，但权衡工作量来说，最好还是换一个MQ吧。
2019-09-18老师最近的课都是在啃代码且非常整体性：学习上是越来越辛苦了，总要翻阅和梳理知识才能明白题目可能的问题。
节点之间不互相通信其实减少了网络开销以及相互的等待确认的过程从而节约了时间,不会互相影响互相继承：换个角度来思考这个问题其实就像是我们用虚拟化一样，RocketMQ的这种NameServer就像是docker/Kubernetes，各自出了问题不会影响其它的docker/K8。
优势就是减少了节点之间的通信以及等待的代价，不足就是出了问题如何发现以及通知系统/服务端。等待老师对于这个问题的答案的公布：等待明天老师继续的分享，谢谢。
2019-09-17多个NameServer独立对外提供服务是一种用冗余的路由注册来换维持集群式的NameServer间数据一致性和高可用性的方式，集群部署不可避免需要在数据一致性和高可用性间平衡，这会给程序设计、编码和后溪维护带来很大的代价，因为路由信息本就不会太多，所以选择了前者。
不过我更偏向于后者，单节点独立提供服务肯定会出现某个节点请求当前的NameServer找不到对应的正常Broker的情况，因为NameServer不能保证保存了完整的Broker集群拓扑。路由发现算法虽然会导致一些时间的服务不可用，但在Broker集群体量很大的时候，肯定比独立NameServer好点。当然目前也可以考虑部署RocketMQ集群，让每个独立的NameServer服务部分区域的Broker的设计思路吧- 2019-09-17这整个就是一个微服务架构
2019-09-17老师，我想问一下，如果起了很多个NameServer，都保持长连接的话是不是开销会较大呢，为什么没有采用订阅发布的模式去更新broker呢，是因为即时性吗作者回复: 这又是一个设计选择而已，NameServer只是负责存储一下元数据，数据量不大，处理请求的TPS也不高，所以没必要启动很多个NameServer，所以并不会存在你说的很多个NameServer的情况。