CKafka 提供集群级别和 Topic 级别两种维度的限流保护方案，具体的配置说明如下：
配置集群级限流规则
当您购买指定规格的峰值带宽后，系统会实时监测业务流量使用情况，并基于限流机制自动判断集群是否超出规格用量。若检测到流量持续超过购买规格的阈值，系统将自动触发限流保护，您无需特殊配置。详细的限流机制请参考限流机制说明。
配置 Topic 限流规则
您可以针对 Topic 设置限流规则，避免单个 Topic 流量过大而影响其他 Topic。
说明
只有 Broker 版本为1.1.1、 2.4.1 和 2.8.1 时才支持设置 Topic 限流规则。
操作步骤
1. 登录 CKafka 控制台。
2. 在左侧导航栏选择实例列表，单击目标实例的“ID”，进入实例基本信息页面。
3. 在实例基本信息页面，选择 Topic 列表页签，单击目标 Topic 操作列的更多 > 限流。
4. 在弹窗中开启限流，并配置限流规则。
topic 最大生产流量：不含副本流量，取值范围为 1MB/s 到该实例购买的最大带宽/该 Topic 副本数。
topic 最大消费流量：取值范围为 1MB/s 到该实例购买的最大带宽。底层针对 Broker 进行限流，实际限流值（等于 broker 数量的整数倍）可能会与设置的限流值略有区别。关于软限流机制说明请参见 限流机制说明。
CKafka 限流实践教程
分区数的规划与局部限流
由于 CKafka 实例采用多节点分布式部署提供整体的写入和消费服务，因此每个节点分配固定的读写限流额度，为了更好的提高 CKafka 流量的使用率，需要您保证分区数尽量维持节点数的倍数（在分区数是节点的倍数，Ckafka 会尽可能让每个节点存储同样的分区数），流量尽可能均衡（特殊场景例如指定消息的 key 会使写入流量不均衡，默认情况下 CKafka 的客户端会尽可能按照分区均衡流量发送到服务端），此时可以有效避免局部热点问题带来的局部限流问题。
实例限流次数与延时回包监控说明
CKafka 的实例限流次数统计的是各个节点限流次数之和，并不代表整个实例的写入和消费性能，也不代表所有节点都触发了限流，因此当出现限流次数，但是限流流量整体看低于规格值，客户可以在高级监控中，查看各个节点的限流次数的统计，用于判断是哪个节点出现了限流。
遇到这类问题，建议尽可能调整分区数到节点的倍数，提高整体实例的带宽利用率。目前 CKafka 采用延迟回包策略，因此，当出现限流后，您需要密切关注的指标是延迟回包的时间，该监控可以在专业版的高级监控中查看。
写入和消费限流模型的区别
由于生产涉及副本同步，所以要除以副本数；消费只从 Leader 上拉取数据，所以不需要除以副本数。
单节点的最大写入流量 = 规格值 / 节点数 / 副本数。
单节点的消费流量 = 规格值 / 节点数。
关于偶发限流次数的说明
因为副本会占用写入限流，因此更多的副本，意味着写入流量会更低。其中限流实际执行是节点级别的执行，限流观测的是秒级的监控，客户看到的监控是分钟粒度的监控，因此，限流更为敏感，在整体写入流量大于70%（除以副本）时候，在秒级个别节点会出现局部限流，但是并不会持续很久，针对这个问题，客户可以在高级监控节点限流查看具体超了多少流量，如果对响应时间有较高要求，尽量规格预留 30% 的 Buffer。
关于持续限流次数的说明
当实例出现限流次数，同时观察高级监控，每个节点都持续出现限流，实例的流量低于规格值 10% 以上，且排除 Topic 限流规则的影响，此种情况不符合预期，针对这类问题提工单支持。
常见问题
为什么实际限流值会小于配置的阈值？
限流所配置的限额实际会被下发到每台 Broker（单机限流），因此实例维度的限流会按照限流配置值/Broker 数量下发，Topic 限流值也会按照限流配置值/Broker 数量下发。
为什么监控生产/消费低于实例规格时会触发限流？
如上文所述，因为限流是以 ms 为单位的，控制台监控平台数据是按每秒采集，分钟维度聚合（最大值或者平均值）。
按令牌桶原理可知，单个桶不会强制限制流量。如果实例 A 的带宽规格为 100MB/s，那么每个 100ms 的时间桶的限流阈值为 100MB/10 = 10MB/桶，假设实例A 的生产流量在某秒的第一个 100ms 时间桶达到了 30MB （时间桶限流阈值的3倍）。那么这时会触发 Broker 限流策略增加延时回包时间，假设原先正常 TCP 返回时间是 100ms，超限后可能会增加 500ms 才返回。最终这秒的流量 ：30MB × 1 + 0MB × 5 + 10MB × 4 = 70MB，即这秒内的流量速度为 70MB/s 小于实例规格 100MB/s。
为什么生产/消费峰值流量会高于实例规格？
再次假设实例 A 的带宽规格为 100MB/s，那么每个 100ms 的时间桶的限流阈值为 10MB，假设实例 A 的生产流量在某秒的第一个 100ms 时间桶达到了 70MB（时间桶限流阈值的7倍）。那么这时会触发 Broker 限流策略增加延时回包时间，假设原先正常 TCP 返回时间是 100ms，超限后可能会增加 800ms 延时才返回，在第 900ms 回包后客户端立刻又在第10个时间桶打入了 70MB 流量。最终这秒的流量 (70MB × 1 + 0MB × 8 + 70MB × 1) = 140MB，即这秒内的流量速度为 140MB/s 大于实例规格 100MB/s。
限流次数为什么会暴增？
限流次数是以 TCP 请求统计的，如果实例A在某秒第一个时间桶流量打超了，那么超限后这个时间桶的剩余时间内所有的 TCP 请求都会被限制并统计限流次数。
CKafka 如何进行限流？
为保证服务的稳定性，CKafka 在消息出入上都做了流量管控。
用户所有副本流量之和超过购买时的峰值流量时，会发生限流。
在生产端发生限流时，CKafka 会延长一个 TCP 连接的回应时间，延迟时间取决于用户瞬时流量超过限制的大小。和道路交通管制的原理有点类似，流量超得越多，延时算法得出来的延时值越高，最高5分钟。
在消费端发生限流时，CKafka 会缩小每次
fetch.request.max.bytes 的大小，控制消费端的流量。如何判断 CKafka 是否发生限流？
1. 在实例列表上，每个集群都有对应的健康度展示。当健康度显示为“告警”字样时，可以将鼠标移至其上查看弹出的详细数据。这个数据会展示当前用户的峰值流量以及发生限流的次数，用户可以根据这里的数据判断该实例是否发生过限流。
2. 用户可以打开监控数据查看流量的最大值，如果 (流量的最大值 × 副本数) ＞ 购买时的峰值带宽，则表明至少发生过一次限流。可通过配置限流告警得知是否发生限流。告警规则等配置步骤请参考配置告警策略。
3. 在 CKafka 控制台的监控页面查看实例监控，当限流次数大于0，证明发生过限流。具体步骤请参考查看监控数据。
