Tencent Cloud

Recent Pages

限流问题

最后更新时间：2024-11-07 11:27:58

概述
CKafka 生产者和消费者以极高的速度生产/消费大量数据或产生请求，从而消耗 Broker 上的资源，造成网络IO饱和。因此 CKafka 设计限流方案，对节点进行自我保护，避免因为资源消耗过高而影响全量业务。
以下以售卖规格为 20MB 的实例为例，其中需要说明几点：
1. Ckafka 针对客户使用场景和需求，至少为 3 节点部署，因此 20MB 的流量，设计为每个节点承受 6.67MB 的读和写流量，因此在使用上建议您设置的分区数尽量为节点的 2-3 倍，使请求流量均衡，方能发挥最大效能。
﻿
2. 目前提供两种层级的限流能力，限流能力分别如下：
集群级限流
写限流整体限制为 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 回包达到一段时间内的限流效果。
﻿
﻿
﻿
Ckafka 限流最佳实践
分区数的规划与局部限流
由于 Ckafka 实例采多节点分布式部署提供整体的写入和消费服务，因此每个节点分配固定的读写限流额度，为了更好的提高 Ckafka 流量的使用率，需要客户保证分区数尽量维持节点数的倍数（在分区数是节点的倍数，Ckafka 会尽可能让每个节点存储同样的分区数），流量尽可能均衡（特殊场景如指定消息的 key 会使写入流量不均衡，默认情况下 Ckafka 的客户端会尽可能按照分区均衡流量发送到服务端），此时可以有效避免局部热点问题带来的局部限流问题。
实例限流次数与延时回包监控说明
Ckafka 的实例限流次数统计的是各个节点限流次数之和，并不代表整个实例的写入和消费性能，也不代表所有节点都触发了限流，因此当出现限流次数，但是限流流量整体看低于规格值，客户可以在高级监控中，查看各个节点的限流次数的统计，用于判断是哪个节点出现了限流。
遇到这类问题，建议尽可能调整分区数到节点的倍数，提高整体实例的带宽利用率。目前 Ckafka 采用延迟回包策略，因此，当出现限流后，您需要密切关注的指标是延迟回包的时间，该监控可以在专业版的高级监控中查看。
写入和消费限流模型的区别
由于生产涉及副本同步，所以要除以副本数；消费只从leader上拉取数据，所以不需要除以副本数。单节点的最大写入流量=规格值/节点数/副本数，单节点的消费流量=规格值/节点数。
关于偶发限流次数的说明
因为副本会占用写入限流，因此更多的副本，意味着写入流量会更低。其中限流实际执行是节点级别的执行，限流观测的是秒级的监控，客户看到的监控是分钟粒度的监控，因此，限流更为敏感，在整体写入流量大于70%（除以副本）时候，在秒级个别节点会出现局部限流，但是并不会持续很久，针对这个问题，客户可以在高级监控节点限流查看具体超了多少流量，如果对响应时间有较高要求，尽量规格预留 30% 的 Buffer。
关于持续限流次数的说明
当实例出现限流次数，同时观察高级监控，每个节点都持续出现限流，实例的流量低于规格值 10% 以上，且排除 Topic 限流规则的影响，此种情况不符合预期，针对这类问题提工单支持。
常见现象
为什么监控生产/消费低于实例规格时会触发限流？
如上原理所述，因为限流是以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，证明发生过限流。
﻿
﻿
﻿