@lsk569937453 这个项目我是从前辈那里接过来的。 目前已经在线上稳定运行一段时间。目前是不适宜在短时间内重构它。只想着在现有的情况下，特殊处理一下这个量大的 topic ，这个 topic 后续会下线掉。
@ZZ74 其实就是应用部署在云上有多个实例，每个实例在创建的时候都会尝试去创建 consumer 获取分区。由于都是用同一个消费者组，最终也就只有 topic 分区数的实力能够获取到该 topic 的其中一个分区，我这样理解是没问题的吧？

@ZZ74 谢谢大佬提供思路。我的想法是，只需要计算好 topic 对应的分区，多实例消费 topic 的时候，只有获取到分区的实例才能消费到数据。计算一下分区数*限流量应该就可以得到想要的结果了吧？

@wqhui 没错，就是大佬你说的意思。目前我考虑到通过使用限流器来限定特定的 consumer 1 秒只 poll 一次

@codedreamstar 不好意思之前没讲清楚，创建内存的线程池主要是为了异步处理消费者数量，consumer.poll 是不受内存线程池影响的。
@diagnostics 感谢提供思路，我之前也有考虑过用 sleep 来控制 poll 的次数，但考虑到实例多、消费 Topic 数量多等复杂情况，没有深入了解就用 sleep 感觉不太稳妥。
@lsk569937453 不好意思没有表达清楚需求。 由于存量 topic 推送过来的数据量并不大，因此目前并没有做任何限速处理，现有应用就是尽可能地去消费很多数据（依赖线程池异步处理 record)。 然后新 topic 由于数据量远远大于存量 topic 的数据量，如果不作消费限制的话，对于后续的业务处理是有着极大的压力和风险的。

感谢

gwjdYQC7EsEoimvK35Y4ZD

我也支持一下

我也来支持一下

讨论一圈下来发现没有人吐槽 Spotify 的推荐歌曲功能么？

我推一个魅族 20pro

天啊，原本以为我没钱买房在愁孩子学位够烦了。没想到 op 有了关内关外的房还会有类似的烦恼~