Tongwin

@codedreamstar 我大概讲一下场景出来吧。 应用 A 设计之初并没考虑到那么长远，初衷也是能消费多快就消费多快。因此就用上了多线程异步处理数据。 处理数据这块其实也只是为了把数据存到 redis 里。 然后我们有另外的进程去从 redis 的队列里拿到数据，然后把这些数据再下发到下游（通过调用下游接口，简称应用 B ）。 目前消费的 topic 都是推过来的实时数据，因此各项的 tps 都能够满足；不过应用 B 是有一个峰值的 tps 的。之前来了个需求，新接入一个 topic （简称(topic-new)，topic-new 推过来的量是固定的，我这边撑这块业务为：存量初始化。 之前协商好上游提供 topic 过来的时候是控制速率的（因此原本我这边不用考虑限速限流的），后来因沟通问题上游又不作限速处理，最终限速操作只能在应用 A 这边进行。
针对限速这块其实我是有过几个思考方案的
方案一：直接搞一个 Spark 应用来进行存量初始化，Spark 在控制批量消费还是很好控制的
方案二：使用令牌桶对应用 A 特殊的 Consumer 进行限流
方案三：对应用 A 的流入和流出都作限流操作（后续一定会排期对数据流出作限流操作，但是听各位大佬的建议，好像并不推荐对流入数据也作限流操作）
综合考虑各种因素，目前是考虑使用方案二进行限流操作，当完成存量初始化之后就可以下线该 topic 了，后续先实现流出的限流功能，其他功能再考虑可行性。