作者回复: 对，现在新版本Kafka的消费偏移是支持存在Broker主题上，我记得最早是只能存在ZK上。

作者回复: 在消息中间件中引入反压机制，会把系统搞复杂，一般两边的速度匹配问题，主要依赖堆积监控+扩容等手段来解决。 现在有一些反应式开发框架，比如https://projectreactor.io/，是支持所谓反压机制的。这个门槛较高，适用于一些高级场景。

作者回复: 1. 消费者拉消息和报心跳是两个独立功能，请求频率也完全不同，肯定不能合在一起。 2. Broker是无状态的，如果Broker出问题，Nginx健康检查机制会将其剔除(PMQ采用公司内部的Nginx层进行负载均衡)

作者回复: push模式的话，broker上有线程要负责去推消息的，如果consumer慢，broker上线程会被阻塞。用邮递员作比喻，相当于邮递员需要主动把信送到每个人家里，如果某个人接收慢(或者路上堵了)，可能把邮递员堵塞住，影响给其它人送邮件。 pull模式，broker上相当于只有消息数据，consumer端各自去broker上拉各自的消息，互不干扰，不会堵塞。用取邮件作类比，相当于每个人自己去邮局取邮件，各取各的，不会堵塞。

作者回复: 两者相辅相成看，看我视频有助于理解总体架构设计，撸代码可以理解更多细节、提升实践能力。

作者回复: 不好意思，没有完全理解你的问题，Kafka怎么会只有一个Partition？首先有Topic，然后才有Partition。 关于Kafka消费者偏移的存储，新版本的Kafka支持将消费者偏移提交到一个叫__consumer_offsets的Topic中，参考： https://stackoverflow.com/questions/41137281/offsets-stored-in-zookeeper-or-kafka

作者回复: 消费偏移最终是存在服务端的(PMQ是在元数据库中)，不管怎么重平衡，也不管某个分区的消费者是否因为rebalance而变化，最终都要从服务端去获取对应的消费偏移。

作者回复: 你理解错了，和Kafka一样，PMQ的消费者是有状态的，一个消费者必须记住它消费的Partition的消费偏移量。 有状态的就不能round robin。 你再思考下。