• 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，没有入坑的别踩这个坑了

阿里的组件还是别碰的好

对于第一点，据我了解，Kafka 中的分区和消费者也是这种设计。这样做的原因估计是在实现上会简单很多吧

推荐下 pulsar 吧，前三个问题都可以解决。go sdk 不了解，我只用过 java client

go rmq sdk 问题挺多的 当然了,也可能是我菜, 不会用..

我一直用 RocketMQ，不过是 Java 的，没什么问题哈

是啊
go sdk 我还遇到 一个 go 进程的 producer 关了，consumer 也不可用
一个进程无法创建多个 consumer 对象，等等问题，如果不是老大拍板，我肯定换回 nsq 了

关于第一个，我觉得没啥问题，1 个 topic 下面多个 queue 本身就是实现一种负载均衡了。多个消费者可以扔进一个消费 group 里，不需要去做每个消费者和 queue 之间的绑定，可以按负载随时启动新的消费者实例

ons client[doge]，用过加 tag 的 topic，不好用。

慢任务下为什么不好做负载均衡？

对数据有保障性要求的话还是 rabbitmq 吧. nsq 没 persistence, 每次都落盘的话性能就爆炸了.

前两点在 kafka 中不也是一样的嘛？
第三点为了生产环境的资源考虑的吧，只有运维人员可以操作，不允许开发人员随意创建 topic，开发环境可以配置自动创建不存在的 topic
后两点不了解

貌似整个 topic management 都不支持。。。阉割版 go client
是不是 go 在阿里是五等公民，没人用，没人做？

恰好有些耗时长的任务丢到某个队列，导致堆积的很长这种情况
我们这边需求是想要一些竞争去取任务方法

你触发了我的眼 parse，觉得是用 ons 包管理器安装一个叫做 client 的包，并具有参数 [doge] ……

而且创建 topic 只能发送方创建，我开发环境订阅一个不存在的 topic 直接报错
再说非要运维手动管理也不方便吧，比如调整个 topic queue 的操作都没法自动化

你订阅一个不存在的 topic 报错这逻辑没啥不对的吧

所以要 api 啊，在开发的时候方便创建 topic

关于第一个点，consumer 只要指定 group 了貌似就没有这个烦恼了吧，再就是 create topic 的事儿，我记得是可以通过配置来实现是否允许自己创建 Topic，只不过一般都是关闭的，一般来说部署的时候都是不允许自己创建 Topic，无论是在什么环境都会是关闭的，不然管理起来会很混乱。在阿里里面，有一个运维平台去创建 Topic，只不过在开发环境做的配置，会随着开发流程的推进，同步到测试环境，集成环境直到生产环境。不过我倒是没有用过 go 的 sdk 。

1. 用过 kafka 都知道 消费者跟消费者组的区别
2.生成产者的路由规则可以根据 key 与 tag 设置 消费者跟消费者组设置
3. 从运维层面来看 api 创建 topic 跟删除 topic 都是很危险的行为
4. go 的 sdk 没有用过 你可以检查一下是不是官方的 反正 java 可以设置
5. 日志配置 java 配置还是很灵活的 go 不清楚

关于配置或者日志设置这一方面 可能 go 的 sdk 支持的不是很到位，比较 go 的生态才刚刚起来 要理解一下

MQ 选用的人多的，
传统金融业务小吞吐选 RabbitMQ 、大吞吐高性能的选 Kafka

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

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

kpi 3.25

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