导语

在当今大数据和实时通信的时代，消息队列在分布式系统中扮演着至关重要的角色。CKafka 作为一种高性能、高可靠的消息中间件，被广泛应用于各种业务场景中。然而，随着业务的增长和数据流量的增加，CKafka 在生产者和消费者以极高的速度生产/消费大量数据或产生请求时，可能会导致 Broker上资源的过度消耗，造成网络 IO 饱和等问题。为了避免这种情况对全量业务产生影响，CKafka 设计了一套完善的限流方案。本文将详细探讨 CKafka 限流的相关内容，包括限流机制、最佳实践方法以及常见问题的分析，帮助用户更好地使用 CKafka，保障系统的稳定性和性能。

CKafka 限流方案概述

以售卖规格为 20MB 的实例为例：

CKafka 针对客户使用场景和需求，通常至少为 3 节点部署，因此 20MB 的流量设计为每个节点承受 6.67MB 的读和写流量。为了发挥最大效能，在使用上建议设置的分区数尽量为节点的 2 - 3 倍，这样可以使请求流量均衡地分布到各个节点上。

目前 CKafka 提供两种层级的限流能力，限流能力分别如下：

集群级限流

写限流：整体限制为 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。

CKafka 如何进行限流？

为保证服务的稳定性，CKafka 在消息出入上都做了流量管控。

用户所有副本流量之和超过购买时的峰值流量时，会发生限流。

在生产端发生限流时，CKafka 会延长一个 TCP 链接的回应时间，延迟时间取决于用户瞬时流量超过限制的大小。和道路交通管制的原理有点类似，流量超得越多，延时算法得出来的延时值越高，最高 5 分钟。

在消费端发生限流时，CKafka 会缩小每次 fetch.request.max.bytes 的大小，控制消费端的流量。

CKafka 限流机制及原理

软限流机制

CKafka 的限流机制是软限流，即当用户流量超过配额后，采用延时回包的方式进行处理，而不是给客户端返回报错。

以 API 限流为例，举例如下：

硬限流：假设调用频率为 100次/s，当每秒内客户端调用超过 100 次时，服务端就会返回错误，客户端就需要根据业务逻辑进行处理。

软限流：假设调用频率为 100次/s，正常耗时是 10ms。当每秒内客户端调用超过 100 次时：

如为 110 次，则本次请求耗时 20ms。
如为 200 次，则耗时为 50ms。此时对客户端就是友好的，不会因为突增流量或者流量波动产生报错告警，业务可以正常进行。

综上所述，在 Kafka 这种大流量的场景下，软限流是更符合用户体验的。

购买带宽和生产消费带宽的关系：

生产最大带宽（每秒）= 购买带宽 / 副本数
消费最大带宽（每秒）= 购买带宽

延时回包限流原理

CKafka 实例的底层限流机制是基于令牌桶原理实现的。将每秒分为多个桶，每个时间桶的单位为 ms。

限流策略会把每秒(1000ms)均分为若干个时间桶。例如分为10个时间桶，每个桶的时间则为100ms。每个时间桶的限流阈值就是总实例规格速度的1/10。如果某个时间桶内的 TCP 请求流量超过了该时间桶的限流阈值，会根据内部限流算法增加该请求的延时回包时间，使客户端无法快速收到 TCP 回包达到一段时间内的限流效果。

CKafka 限流最佳实践

分区数的规划与局部限流

由于 CKafka 实例采用多节点分布式部署，每个节点有固定的读写限流额度。为了提高流量使用率，客户应保证分区数尽量维持节点数的倍数，使流量尽可能均衡。特殊场景（如指定消息的key会使写入流量不均衡，但默认情况下 CKafka 的客户端会尽可能按分区均衡流量发送到服务端），合理规划分区数可以有效避免局部热点问题带来的局部限流问题。

实例限流次数与延时回包监控说明

限流次数统计

CKafka 的实例限流次数是各个节点限流次数之和，不代表整个实例的写入和消费性能，也不代表所有节点都触发了限流。当出现限流次数但限流流量整体低于规格值时，建议在高级监控中查看各个节点的限流次数统计，以确定是哪个节点出现了限流。

延时回包监控

遇到限流问题，需密切关注延迟回包时间。目前 CKafka 采用延迟回包策略，用户可在专业版的高级监控中查看该指标，以便及时了解系统运行状态。

写入和消费限流模型的区别

由于生产涉及副本同步，所以要除以副本数；消费只从 Leader 上拉取数据，不需要除以副本数。具体计算为：单节点的最大写入流量=规格值/节点数/副本数，单节点的消费流量=规格值/节点数。

关于偶发限流次数的应对

因为副本会占用写入限流，更多副本意味着写入流量会更低。限流实际是节点级别执行，监控是秒级，而客户看到的监控是分钟粒度，所以当整体写入流量大于70%（除以副本）时，个别节点在秒级可能会出现局部限流，但通常不会持续很久。客户可在高级监控节点限流查看具体超流量情况，若对响应时间要求较高，建议规格预留 30% 的 Buffer。

关于持续限流次数的处理

当实例出现限流次数，同时在高级监控中发现每个节点都持续出现限流，且实例的流量低于规格值 10% 以上，并排除了 Topic 限流规则的影响，这种情况不符合预期。针对此类问题，您可以提交工单寻求支持。

常见问题分析

监控生产/消费低于实例规格时触发限流的原因

CKafka 限流以 ms 为单位，控制台监控平台数据按每秒采集，分钟维度聚合。依据令牌桶原理，单个桶不强制限制流量。例如，当实例带宽规格为 100MB/s，每个 100ms 时间桶限流阈值为 10MB/桶，若某秒第一个 100ms 时间桶达到 30MB（时间桶限流阈值的3倍），会触发限流策略，增加延时回包时间。即使后续桶中流量减少，最终秒内流量速度仍可能因限流策略而低于实例规格。

生产/消费峰值流量高于实例规格的原因

同样假设实例带宽规格为 100MB/s，每个 100ms 时间桶限流阈值为 10MB。若某秒第一个 100ms 时间桶达到 70MB（时间桶限流阈值的 7 倍），会触发限流策略，增加延时回包时间，当后续时间桶有流量涌入时，秒内流量速度可能高于实例规格。

限流次数暴增的原因

限流次数以 TCP 请求统计，若某秒第一个时间桶流量超标，该时间桶剩余时间内所有 TCP 请求都会被限制并统计限流次数。

CKafka 限流的判断方法

健康度展示

在实例列表上，每个集群都有对应的健康度展示。当健康度显示为“警告”字样时，可以将鼠标移至其上查看弹出的详细数据。这个数据会展示当前用户的峰值流量以及发生限流的次数，用户可以根据这里的数据判断该实例是否发生过限流。

监控数据查看

用户可以打开监控数据查看流量的最大值，如果 (流量的最大值 × 副本数) ＞购买时的峰值带宽，则表明至少发生过一次限流。可通过配置限流告警得知是否发生限流。

控制台监控页面

在 CKafka 控制台的监控页面查看实例监控，当限流次数大于 0，证明发生过限流。

总结

CKafka 的限流机制对于保障系统的稳定性和性能至关重要。通过合理规划分区数、关注限流次数和延时回包监控、区别对待写入和消费限流模型、预留适当的 Buffer 以及及时处理持续限流等问题，同时掌握常见问题的分析方法和限流的判断技巧，用户可以更好地使用 CKafka，避免因资源过度消耗而影响业务运行。在实际应用中，应根据具体业务场景和需求，灵活运用 CKafka 的限流功能，以达到最佳的使用效果。