rocketmq 踩坑和吐槽

[bigpigeon]

• 1 个 queue 只能被一个消费者订阅，也就是说如果你消费者增加时必须手动调整 topic 的队列数
• round robin 只在 queue 层面，可以理解为就是生产者吧消息平均分配到多个 queue 上，但 queue 只能被单消费者消费，在慢任务做负载均衡不好做
• 没有 create topic 的 api，必须通过 mqadmin 来创建 topic，极其麻烦
• go sdk 的 consumer 连 ConsumeTimeout，ConsumeConcurrentlyMaxSpan，PullThresholdForQueue 这几个这么重要的参数都没有暴露出来，并发控制都不好做
• go 的 sdk 日志乱打，1 秒几十行的无用日志，压根没法正常阅读，必须通过环境变量控制日志级别

这 2 个月用下来的体验就是 go 开发者建议还是使用 nsq，没有入坑的别踩这个坑了

阿里的组件还是别碰的好

[bigpigeon]

@shuangchengsun 不同的 group 消息是互相独立的，也就是说一条消息在 2 个组会分别被消费一次，相当于 redis 的 pub sub，我们的需求是消费消息的负载均衡

[bigpigeon]

@yukong 特别是文档方面的，rocketmq 的文档写的感觉也很简单，特别是 go sdk 的文档，基本等于没有，全靠阅读源码找用法
还有就是 rocketmq 的容器化部署也不方便
日志还是默认打到文件里面而不是 stdout
而且 dashboard 是第三方的，还得自己想办法构造 Docker image
相比之下 nsq 这方面就做的好很多

[YouLMAO]

kpi 3.25

[cominghome]

凑合用吧，毕竟 KPI 产物，文档写得鬼一样

[bthulu]

@hun2008hun pulsar 的 java client 太大了, 加上它自身的依赖, 高达 36.1M. 我本身项目其余所有依赖加起来都没这家伙大, 不知道 pulsar 在搞什么