作者回复: 这个不是kafka本身的问题，原来的PMQ 1.0有一个基于Kafka的方案，之前的架构师在Kafka上面包装了一个分发器(Dispatcher)，相当于把Kafka的拉模式又搞成了推模式，目的是想简化消息接收方。但是原来的推模式没有设计好隔离机制，在推消息的过程中，如果某个接收方慢，就会把分发器整个给堵住了，然后其它的消息接收方会受影响收不到消息。 如果采用分发器+推消息方式，要做好隔离机制还是比较难的，需要在分发器上做多线程隔离。

作者回复: 个人认为RocketMQ和RabbitMQ能力上基本等价。但是RocketMQ更面向互联网型大流量高性能消息应用，而RabbitMQ更面向传统企业级消息应用，RocketMQ功能更丰富，但是性能和扩展型不如RocketMQ。公司如果刚开始业务不大，可以从RabbitMQ开始，更容易上手，文档资料更多。到达一定体量，可以再考虑升级到RocketMQ。 虽然这两个MQ都可以部署到K8s环境，但是对于MQ这种有状态服务，其重要性和DB相当，建议独立于K8s单独部署/监控和运维。

作者回复: 你好，我看的RMQ代码还比较早，在2016年底左右，那个时候它还不是Apache孵化项目。RMQ这几年在Apache下应该有不少改进了，所以现在RMQ的代码质量可能已经大大改进了。

作者回复: 看情况。我个人建议如果有条件的话，尽量用云服务，这个长期是确实。除非某些业务场景(比如金融严格要求合规的场景)，或者本来就是自建数据中心，也有一定的研发运维能力，才考虑自己运维。

作者回复: 对，能不要造轮子就尽量不要造轮子，解决业务问题优先。但是PMQ这个轮子当时必须得造，具体看我视频中的三点说明。

作者回复: 嗯，到一定规模量级，选择开源是捷径，但定制封装也少不了，且需要一定的源码级把控。