陈2023-07-27 来自广东pop模式优点 1.每个消费者都可以消费到所有queue的消息，消费者不用再关心重平衡。 2.消费者不与某个queue强绑定，不会因为某个消费者hang住导致某个queue堆积。 但是按照 "消息粒度负载均衡" 来消费数据不是也是同样的效果吗？为什么还要实现这个pop模式？作者回复: Pop 模型主要用来解决下面三个消费组机制存在问题： 1. 客户端实现较重。 2. 重平衡会暂停消费和重平衡时间不可控，导致的消费停止或消费慢的问题。 3. 分区消费可能会存在倾斜。 "消息粒度负载均衡" 的消费模式可以解决消费倾斜的问题。但是它的底层是基于消费组的机制来实现的。所以依旧会存在上面的问题1和2。 而Pop希望主要想解决的就是1和2，让客户端无状态、更轻量，这样对多语言的支持也比较友好，同时解决重平衡带来的消费慢、消费停滞的问题。
1
张申傲
2023-07-14 来自北京小建议：架构图中的Partition是不是换成MessageQueue好一点？虽然概念上是一致的～作者回复: 收到，感谢提醒，我们调整一下~
1
aoe2023-07-16 来自浙江原来支持 gRPC 是为了简化多语言 SDK 的开发作者回复: 从原始的设计初衷来看，有这一点的考虑的。在这一方面确实能带来一定的好处。
cykuo2023-07-14 来自北京首先在生产者开始生产消息，包括根据remoting协议序列化消息内容，然后尝试访问namesrv获取所有broker信息，然后根据自己发送消息topic消息决定将数据投递到具体哪个broker上。投递动作根据投递方式的不同分为同步发送，异步等发送方式的不同略有差异。消息在投递到broker之后，如果是发送到topic中，则需要在broker上完成生产分发的工作，决定消息最后投递到哪个queue上。如果是投递到queue则可以省略这一步。（这里不管是topic还是queue应该都是逻辑概念，通过索引所描述的在commitLog中的逻辑关系所决定的）。最后在consumer侧，则默认是使用pull模式来拉取消息，首先从namesrv中获取所有broker的信息，进而确定自己需要的数据坐标信息，在拉取消息之后还有提交消费位点等动作，另外在消费侧还有其他的消费模式POP/PUSH（这里问作者一个问题，POP模式是否可以避免因为消费者的rebalance？当然broker自身导致的rebalance是无法避免的。。。）3- 赵海升2023-07-17 来自上海许老师 这个消息粒度负载均衡 的配图有点小疑惑 , R3 和 R5 的 不被消费吗 ？R2 R4 别同一个消费组的cosume1 消费两次？这图是不是有问题1
- walle斌2023-09-05 来自北京rocketmq是支持批量发送，详细查看MessageBatch 这个类
Geek_8562b22023-08-07 来自江苏老师，消费端和生产端消费生产时是连接到整个NameServer集群吗，还是连接到某一个NameServer节点，如果只是连接到某一个NameServer节点，那么这个节点挂掉，生产端和消费端怎么获取其他NameServer节点信息。