作者：京東零售 饒璐

1、背景

在數字化轉型的浪潮席卷之下，大數據和云計算技術已成為企業創新和發展的關鍵驅動力。尤其是以京東為代表的電商平臺為例，其日常運營中持續生成海量數據，涵蓋實時交易記錄、點擊曝光統計及用戶行為軌跡等，這些數據對精準業務決策、深化用戶體驗優化等方面具有重要意義。然而，隨著業務版圖的快速擴張，特別是在618、雙11等年度大促盛宴中，數據流量呈現井噴式增長，給數據系統帶來前所未有的壓力。

在此情境下，盡管Apache Kafka憑借其卓越的高吞吐能力與低延遲特性，成為了企業處理實時數據流的首選，但面對當今降本增效的宏觀趨勢，企業急需在不增加過多資源負擔的前提下，實現效能的最大化。特別是針對網絡帶寬這一寶貴資源，如何在海量數據與復雜業務場景交織的挑戰中，實施更加精細、高效且智能的流量限速控制策略，以確保消息中間件服務能夠持續提供高可用性與高穩定性，成為了企業技術團隊亟需攻克的難關。

JDQ 是基于 Apache 基金會開源的 Kafka 消息隊列，深入打造的具備高吞吐、低延遲、高可靠性的實時流式消息中間件框架，可應用于數據管道、實時數倉、數據分析、等多種場景，是京東統一的實時數據總線。京東JDQ團隊結合降本增效的行業趨勢，針對開源Kafka在限流技術方面的不足和局限性進行了深入研究，并在此基礎上進行了創新性優化，開發出支持多維度、動態以及優先級等限流功能的JDQ帶寬管控限流架構。本文將針對Kafka限流存在的問題，以及JDQ限流架構進行深入介紹。

2、Kafka 限流

2.1 限流概述

在服務器日常運營中，限流是一種自我保護機制，用于避免突發和異常的數據流入流出量徒增對系統造成的沖擊。這種情況尤其常見于電商促銷高峰期，此時某些特定的主題（topics）可能會經歷流量激增，導致過多的占用Broker帶寬資源和磁盤I/O資源。如果不加以控制，這不僅會影響其他客戶端的正常讀寫操作，還會干擾集群內部的主從同步過程，給整個集群帶來巨大的壓力。當集群承受過大的壓力，不僅可能導致服務過載，甚至可能引發系統崩潰。部分節點的故障雪崩，最終會波及到集群內所有業務的正常運行。因此，通過精細化的限流策略，我們能夠有效維護集群的穩定運作，保障業務的連續性和服務質量。

2.2 原生 Kafka 限流機制

Kafka 原生的限流機制是配額優先級限流機制，kafka提供兩個配額配置參數，三種粒度來進行限流管理：

兩個配置參數：（可以動態調整）

（1）producer_byte_rate：生產者單位時間（每秒）內最高允許發送到單臺broker的字節數。

（2）consumer_byte_rate：消費者單位時間（每秒）內最高允許從單臺broker拉取的字節數。

三種粒度：

（1）user(認證方式)

（2）client.id(客戶端標識)

（3）user + client.id

user只能在集群中開啟身份認證鑒權的情況下使用，在每個broker的ProduceRequest和FetchRequest中攜帶的client/user客戶端身份標識，進行對應的限流。

Kafka 為user、client-id以及 （user+client-id）這三種粒度定義配額配置，同時支持設定默認值，具體的配額可以覆蓋默認配額，配額配置參數都是寫入zookeeper的 /config 路徑下，其中user 以及 （user+client-id）的配置是寫入 /config/users 下，而client-id是直接寫入 /config/clients 下，可以設置所有的user或者所有的clients默認配額，如果有指定user或者指定clients則會覆蓋默認值。這些覆蓋可以及時被服務監聽，無需滾動重啟整個集群也能夠動態更新這些參數配置。

如果同時配置了多粒度的參數，限流優先級從高到低如下：

/config/users//clients/ 指定的 user+client-id的配置值 那么優先級最高； /config/users//clients/ 指定user配置+clients的默認值 /config/users/ 單獨的user粒度，指定user /config/users//clients/ user的默認值+指定client-id /config/users//clients/ user的默認值+默認的client-id /config/users/ 單獨的user的粒度，所有user的默認值 /config/clients/ 單獨的client-id粒度，指定client-id /config/clients/ 單獨的client-id粒度，所有client的默認值，優先級最低

如果同時集群下存在多種配額配置參數，以優先級高的配額配置為準。

舉一個例子解釋限流優先級：如果指定一個user，userA設定他的producer_byte_rate為10M/s，同時該集群上還為所有user的都配置了默認producer_byte_rate為50M/s，以及為默認值下還設置了client-id粒度的配額；此時如果那user認證的生成程序向集群生產，生產速率的配額，應該以user指定為準，即為10M/s。（第3級優先于第5級）

限流算法：

我們假設當前實際速率是O，T是預設的user限流速率值（可以根據實際情況配置），而W表示某一段時間范圍，我們希望在W時間內O能夠下降到T以下（如果O本來就比T小，則什么都不用做），那么broker端就需要延緩等待一段時間后再響應請求。如果假設這段時間是X，那么以下等式成立：

O * W = (W + X) * T

由此得出X = (O - T) / T * W。這就是Kafka用于計算限流等待時間的公式。當然在具體實現時，Kafka提供了兩個參數來共同計算W：W = quota.window.num * quota.window.size.seconds。前者表示取樣的時間窗口個數，后者表示時間窗口大小。

超額處理：

消息隊列本身的功能是削峰填谷，在有突發流量的時候，流量很容易超過配額。此時，機器層面一般是有能力處理流量的，如果直接拒絕流量，就會導致消息投遞失敗，客戶端請求異常。所以，在限流后，Kafka的處理方式是延時回包，通過加大單次請求的耗時，整體上降低集群的吞吐。因為正常狀態下，客戶端和服務端的連接數是穩定的，如果提升單次處理請求的耗時，集群整體流量就會相應下降。增加的耗時時長就是使用上述的限流算法計算的。

2.3 Kafka限流舉例

Kafka限流是各個粒度對于broker-topic請求下的限流，依賴于這個broker上承擔了多少個分區的 leader 分布，下述兩個例子具體說明：（以生產請求為例，特定user只設置了user的生產配額）

eg1：假設存在topic1，有3個分區，每個分區有2個副本，具體的副本分區如下圖，其中分區色塊為粉紅色的是leader節點

當user1 對 topic1 授予了producer的權限，user1的單機生產限流配額 producer_byte_rate 為10M/s，那使用user通過認證的生產客戶端可以往topic1里的每個分區生產數據，那么每個分區的峰值流量都為10M/s；超過10M/s將會用觸發限流機制，根據限流算法計算出一個等待時長，來延緩下一個生產請求的發出。

eg2：假設存在topic2，有3個分區，每個分區有2個副本，具體的副本分區如下圖，其中分區色塊為粉紅色的是leader節點

當user1 對 topic2 授予了producer的權限，user2的單機生產限流配額 producer_byte_rate 為10M/s，那使用user通過認證的生產客戶端可以往topic1里的每個分區生產數據，那么分區1，2共享限流為10M/s；分區3的限流為10M/s；同樣；當分區1和分區2累加的每秒生產的字節數超過了10M/s，或者分區3每秒生產的字節數超過了10M/s，觸發限流機制。

2.4 Kafka限流機制的局限性分析

2.4.1 Broker-Topic維度限流的固有缺陷：節點故障leader切換引發的速率波動

從2.3的兩個例子中，不難發現，如果Kafka集群的某個Topic Leader在發生故障切換時，會對生產與消費速率產生的間接影響，暴露了現有限流機制的一個短板。在標準配置下，生產者消費者的吞吐量分配與分區Leader的物理分布密切相關。

具體而言，假設一Topic擁有m個分區，初始分布于n個活躍Broker之上，每個Broker承載m/n個分區的Leader。消費者對于該Topic的限速配額設定為 s MB/s，理論上可實現總吞吐量 s*n MB/s。然而，一旦某Broker遭遇故障，Leader角色將重新分配至剩余 n-1 個Broker，盡管整體分區數保持不變，但限速原則卻按s*(n-1) MB/s重新計算，導致吞吐量驟減。這一現象表示Kafka限流算法在適應動態故障場景時的脆弱性，用戶需承受非預期的消費速率下降及潛在的數據積壓風險。

2.4.2 缺乏單機限流機制與實時彈性調節能力

根據2.2所述，Kafka 現行限流機制聚焦于 User-Client 層面，忽視了單機 Broker 的容量限制，從而在面對這個 broker 下的user的生產/消費的總速率超過單機硬件限制的理論帶寬上限的情況時，只能手動向下調整平臺上與 broker 有關的生產者，消費者的配額參數，而 Kafka 集群本身并不會做出什么相應的限流舉動，任由過載狀態持續影響所有業務，直至觸發網絡擁塞或數據丟失。同時，Kafka 限流機制高度依賴于預先設定的業務系統限流配額，無法依據實時網絡狀況或 Broker 負載動態調整對應的生產消費配額，削弱了系統的彈性和響應性。

2.4.3 資源分配非最優與業務優先級處理缺失

當前限流技術在自動化處理業務重要性等級方面存在短板，未能充分考慮到不同業務場景的獨特性。特別是在資源競爭激烈的環境中，該技術未能針對不同業務的關鍵程度做出有效區分。當達到限流閾值時，所有業務均遭受無差別的限制，忽視了高優先級服務的特殊需求。這種粗放式的處理方式，不僅無法滿足特定業務場景的個性化需求，還可能阻塞關鍵業務流程或降低用戶體驗，進而引發用戶的不滿和投訴。在當前強調成本控制和效率提升的大環境下，迫切需要一種解決方案，能夠在資源緊張時優先保障高優先級業務，通過錯峰生產/消費模式，實現資源的合理配置和高效利用，以實現最大價值。

綜上所述，開源Kafka在限流技術方面存在一些不足之處，包括但不限于：

?維度單一：限流策略過于粗放，未能覆蓋分區級別或單Broker層級的精細化控制；

?缺乏實時彈性：依賴預設限流配額，無法根據實時業務情況進行動態自動調整。

?未區分業務優先級：未能根據業務的重要性和緊急性進行差異化處理，影響了流量資源的最優配置。

上述分析為Kafka限流機制的改進指明了方向，促使我們探索更為先進且靈活的限流策略，以應對復雜多變的生產環境。

3、JDQ限流核心架構

3.1 JDQ限流模型

其中：分區色塊為粉紅色的是leader節點，“X”為故障節點

3.2 多維度的精細化限流粒度

如上述限流模型所示，在Kafka的基礎上，JDQ平臺支持更精細化粒度限流，即分區級別限流，可以讓生產消費的吞吐量都不受故障節點影響而降低。

核心邏輯為：在 Controller 發起的元數據更新請求中，記錄下來 Broker 上每個 Topic 對應的 leader 數量，在計算消費等待時長時，會讓消費限速配額 consumer_byte_rate * 該 Topic 在分區 Leader 數量，從而實現不論 Topic 的分區 Leader 分布在幾臺機器上，消費者或者生產者的總速率都能保持不變

具體而言，假設一Topic擁有m個分區，初始分布于n個活躍Broker之上，每個Broker承載m/n個分區的Leader。生產者/消費者對于該Topic的限速配額設定為 s MB/s，理論上可實現總吞吐量 s*n MB/s。然而，一旦某Broker遭遇故障，Leader角色將重新分配至剩余 n-1 個Broker，但是整體分區數保持不變，原限流機制的理論總吞吐為 s*(n-1) MB/s, 但改造后的限流原則在節點故障前后均用 s*m MB/s計算，使得速率恒定為 配額*分區數，進而解決機器故障是對生產/消費的吞吐量的影響。

3.3 單機限流和分級動態彈性限流

其圖中，L1、L2、L3的限流邏輯為，根據為每個等級下分配的被分級限流時不同的帶寬配額（可動態改配），以及分區粒度的限流算法進行計算等待時間，使對應等級的業務進行限流；

這一架構的核心在于引入單機帶寬使用閾值，以及重要性等級機制（在分區限流的基礎上），為不同等級(L0,L1,L2,L3)的生產者/消費者（即業務系統）分配差異化的限流帶寬配額。這些參數可以支持動態配置地傳入Kafka集群服務端，使得集群能夠實時根據單機帶寬使用情況，自動、彈性地調整對各個重要性等級業務系統的限流與恢復策略。具體來說，當單機帶寬使用超過預設閾值時，Kafka集群將依據重要性等級從低到高，分級實施限流措施，確保高重要性業務系統得到優先保障。反之，當帶寬使用回落到安全范圍內時，系統將自動恢復限流，保障業務系統的順暢運行。

此架構能夠有效地應對帶寬使用的潮汐變化，實現對不同重要性等級業務系統的精準限流與恢復，實現帶寬資源錯峰使用的智能化管理，確保重要性較高的業務系統能夠得到優先保障，最大程度的減少資源有限的情況下，因帶寬過載而可能造成的損失。此外，還顯著降低現有技術中人為參與調整業務系統流量配額所耗費的人力成本，避免了人為誤操作的風險。同時，其可配置參數的高度可擴展性和靈活性使得用戶可以根據實際業務需求和網絡狀況，動態調整重要性等級、單機帶寬過載閾值以及限流配額等參數，確保該限流機制在不同環境和場景下都能表現出卓越的性能和適應性。這一限流架構不僅提升了Kafka集群的帶寬管理效率，發揮有限資源的最大價值，也增強了業務系統的穩定性和可靠性。

4、實際應用效果

具體實例1：（驗證分區限流）三臺機器分別為同一個topic的三個分區的leader，經過我們分區粒度的限流后，就算存在有一臺機器故障時（停掉服務模擬故障），切換leader之后，消費者的總速率應該為30M/s

原限流邏輯：

改造分區限流邏輯：

具體實例2：（驗證單機和分級限流）以消費請求為例，JDQ的限流策略是如何在大促洪峰流量出現時，保證資源優先分配給高等級的任務呢？以消費為例，當機器單機流出配額帶寬為50M/s時 (單機配額較低，模擬數據洪峰達到機器帶寬上限)，對應的分級限流的差異化流出帶寬配額為L1-10M/s、L2-5M/s、L3-1M/s。啟動L0、 L1、 L2、 L3四個不同的等級業務系統的消費程序，正常的消費時分區速率在50M/s 以上，觸發逐級限流時的測試結果如下圖，L3立即限流至1M/s，L2隔段時間限流至5M/s，L1再隔段限流至10M/s，L0不限流，按照等級由低到高逐級進行限流，對重要性等級高的系統優先分配帶寬，優化了帶寬資源分配，錯峰消費。

具體實例3：（驗證彈性限流）在實例2的基礎上，將機器單機流出配額帶寬動態修改至1000（模擬數據洪峰已過），可以看到所有的就正常全力消費，不被限制，符合彈性根據潮汐值進行限流

5、未來限流優化方向

在未來的Kafka限流技術研發方向上，我們將計劃針對以下幾個方面進行優化和創新：

?多形式多粒度的限流粒度：未來優化將著眼于更多形式的限流，比如根據QPS限流，更細粒度的限流，如消息類型的限流，從而更好地滿足多樣化的業務需求和資源分配策略。

?基于容器化的帶寬彈性伸縮：進一步探索JDQ與容器技術的深度融合，實現集群的按需彈性伸縮。用戶限速帶寬可以根據平時的實際使用率自動調整，確保資源的高效利用與成本控制，同時提升系統的整體響應能力和彈性。

?智能化限流規劃與研發：為了進一步降低運維復雜度，提升系統可靠性，未來將加大投入于智能化限流方案的研發，實現限流策略的自動優化，減少人為干預，提升運維效率。

綜上所述，JDQ的未來限流優化將緊密圍繞用戶需求與技術前沿，致力于打造一個既能應對高并發挑戰，又能在成本控制，資源管理以及運維層面實現智能化、自動化的實時數據處理平臺。

6、結語

我們來自實時平臺研發部JDQ團隊，我們將繼續致力于 Kafka 限流技術的優化與創新，探索更多前沿技術，以進一步提升 Kafka 的穩定性和效率。

同時，我們也將加強與業界的交流與合作，共同推動 Kafka 技術的發展與應用，為大數據時代的數字化轉型貢獻更多力量。

審核編輯 黃宇