随着业务的增长和数据流量的增加，CKafka 在生产者和消费者以极高的速度生产/消费大量数据或产生请求时，可能会导致 Broker上资源的过度消耗，造成网络 IO 饱和等问题。为了避免这种情况对全量业务产生影响，CKafka 设计了一套完善的限流方案，对节点进行自我保护，避免因为资源消耗过高而影响全量业务。
限流方案概述
以售卖规格为 20MB 的实例为例：
CKafka 针对客户使用场景和需求，至少为 3 节点部署，因此 20MB 的流量，设计为每个节点承受 6.67MB 的读和写流量，因此在使用上建议您设置的分区数尽量为节点的 2-3 倍，使请求流量均衡，方能发挥最大效能。
目前 CKafka 提供两种层级的限流能力，限流能力分别如下：
集群级限流
写限流整体限制为 20MB/s，意味着客户最多压测到的写流量(计算副本)为 20MB/s 附近，但是 3 节点，单节点配置 6.67MB/s，因此在单分区情况下写入最大 6.67MB/s，如果单节点双分区，计算副本流量，最大写入为 3.33MB/s。
读限流整体限制为 20MB/s，意味着客户最多压测到的消费流量(不计算副本)为 20MB/s 附近。
Topic 级限流
客户可以配置 Topic 的限流，例如配置 Topic:Test，2 副本，写入限流 7MB/s（已计算副本），消费限流 20MB/s。
写入限流为：7MB/s
消费限流为：20MB/s
限流机制说明
CKafka 的限流机制是软限流，即当用户流量超过配额后，采用延时回包的方式进行处理，而不是给客户端返回报错。
以 API 限流为例，举例如下：
硬限流：假设调用频率为100次/s，当每秒内客户端调用超过100次时，服务端就会返回错误，客户端就需要根据业务逻辑进行处理。
软限流：假设调用频率为100次/s，正常耗时是10ms。当每秒内客户端调用超过100次时：
如为110次，则本次请求耗时20ms。
如为200次，则耗时为50ms。此时对客户端就是友好的，不会因为突增流量或者流量波动产生报错告警，业务可以正常进行。
综上所述，在 Kafka 这种大流量的场景下，软限流是更符合用户体验的。
购买带宽和生产消费带宽的关系：
生产最大带宽（每秒）= 购买带宽 / 副本数
消费最大带宽（每秒）= 购买带宽
延时回包限流原理
CKafka 实例的底层限流机制是基于令牌桶原理实现的。将每秒分为多个桶，每个时间桶的单位为 ms。
限流策略会把每秒（1000ms）均分为若干个时间桶。例如分为10个时间桶，每个桶的时间则为100ms。每个时间桶的限流阈值就是总实例规格速度的1/10。如果某个时间桶内的 TCP 请求流量超过了该时间桶的限流阈值，会根据内部限流算法增加该请求的延时回包时间，使客户端无法快速收到 TCP 回包达到一段时间内的限流效果。
