導語

在當今大數據和實時通信的時代，消息隊列在分布式系統中扮演著至關重要的角色。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 的限流功能，以達到最佳的使用效果。