上云无忧 > 文档中心 > 腾讯云消息队列 CKafka - 限流问题
消息队列 CKafka
腾讯云消息队列 CKafka - 限流问题

文档简介:
限流机制说明: Kafka 的限流机制是软限流,即当用户流量超过配额后,采用延时回包的方式进行处理,而不是给客户端返回报错。
*此产品及展示信息均由腾讯云官方提供。免费试用 咨询热线:400-826-7010,为您提供专业的售前咨询,让您快速了解云产品,助您轻松上云! 微信咨询
  免费试用、价格特惠

限流机制说明

Kafka 的限流机制是软限流,即当用户流量超过配额后,采用延时回包的方式进行处理,而不是给客户端返回报错。
以 API 限流为例,举例如下:
硬限流:假设调用频率为100次/s,当每秒内客户端调用超过100次时,服务端就会返回错误,客户端就需要根据业务逻辑进行处理。
软限流:假设调用频率为100次/s,正常耗时是10ms。当每秒内客户端调用超过100次时:
如为110次,则本次请求耗时20ms。
如为200次,则耗时为50ms。此时对客户端就是友好的,不会因为突增流量或者流量波动产生报错告警,业务可以正常进行。
综上所述,在 Kafka 这种大流量的场景下,软限流是更符合用户体验的。
购买带宽和生产消费带宽的关系:
生产最大带宽(每秒)= 购买带宽 / 副本数
消费最大带宽(每秒)= 购买带宽

延时回包限流原理

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

为什么监控生产/消费低于实例规格时会触发限流?

如上原理所述,因为限流是以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,证明发生过限流。 


相似文档
  • 客户端生产消息如何保证在同一分区是有序的? 如果 Topic 只有一个分区,那么消息会根据服务端收到的数据顺序存储,则数据就是分区有序的。 如果 Topic 有多个分区,可以在生产端指定这一类消息的 key,这类消息都用相同的 key 进行消息发送,CKafka 会根据 key 哈希取模选取其中一个分区进行存储,由于一个分区只能由一个消费者进行监听消费,此时消息就具有消息消费的顺序性了。对于单个生产者来说,对单个分区的生产,是保持有序的。
  • 剩余的未消费消息的条数是如何计算的? 计算方式为:未消费消息数量 = 最大的 offset - 提交的 offset。如下图:
  • CKafka 和 CMQ 有什么区别? CMQ 提供金融级的高可靠、高数据持久性消息传输,保证数据强一致性。 CKafka 适用于对吞吐率要求更高、对可靠性要求相对较低的场景(如日志聚合等业务)。此外,CKafka 完美兼容 Kafka 的老用户,可以做到零迁移成本,实例完全独占。
  • 任务创建失败怎么处理? 转储的任务创建失败时,在控制台中会有一个提示。
  • 如何确认数据上报成功? 当请求的云 API 接口返回 MessageId 字段时,即代表数据已上报成功。参见云 API 调用返回 云 API 返回结果。
官方微信
联系客服
400-826-7010
7x24小时客服热线
分享
  • QQ好友
  • QQ空间
  • 微信
  • 微博
返回顶部