Kafka Test 4 - 限流機制實測 (Quotas)

Knowledge

• broker利用timeout(或稱delay)的原理去控制client TPS

  • https://www.slideshare.net/AdityaAuradkar/kafka-quotas-talk-at-linkedin

EX. 把所有producer的TPS都設成1MB/s, 觀察每個區間的TPS, 會發現TPS是忽高忽低的

測試-1

測試計畫

我用20client (10producer/10consumer) 的情境來驗證,

• 對特定producer/consumer做限流

  • Producer1-5, Consumer 1-5

    • TPS設1MB/s

  • Producer 6-10, Consumer6-10

    • TPS設100MB/s

結果

小結

• 內建的機制的確有做到針對不同client限流的效果, 但測起來的TPS超過設定的值 (1MB/s)

• 看有人測起來, TPS上限不會高過設定的值

• 不確定是哪些參數還需要調整, 要再研究

測試-2 模擬azure(1 MB/秒輸入，2 MB/秒輸出)

• 爬了一些文後終於知道為什麼有測試1這樣的結果

• 主因是這個quota值是套用在每個broker而不是整個cluster

  • 假設有3個broker, 你期望每個producer的TPS是1MB/s, 那你需要把producer quota值設1MB/3=0.33MB

  • Ref

    • https://stackoverflow.com/questions/48691975/how-do-kafka-quotas-work

    • https://docs.confluent.io/current/kafka/design.html#enforcement

測試計畫

• broker數量3個

• 期望做到的限流: Producer 1MB/s, Consumer 2MB/s

  • Producer quota值要設成1MB/3 =349525

  • Consumer quota值要設成2MB/3=699050

結果

但有一點比較怪

• Consumer的TPS預期應該要是2MB/s才對, 但這應該是因為沒那麼多資料讓consumer拿, 就是產生資料的速度趕不上拿資料的速度, 所以應該算合理

• 所以現在接著單獨再跑一次10個consumer, 但這次把consumer --from-latest這個參數拿掉, 讓每個consumer從頭開始拿

• 雖然TPS有提高, 但consumer還是不到預期的2MB/s的目標

• 以為是多partition的關係, 所以另外測了1 broker, 1 partition的情境, 也是達不到

測試-3 多client有相同clientId/多client有相同userId

Client TPS設 1MB/s

quota設到clientId層級

• 10個client都不同clientId

  • 每個cleint的TPS都是1MB/s

• 10個client都相同clientId

  • 每個client的TPS都是0.1MB/s

quota設到userId層級

• 10個client都不同userId

  • 每個cleint的TPS都是1MB/s

• 10個client都相同userId

  • 每個client的TPS都是0.1MB/s

小結

• 同一clientId下, 不管開幾個client, 流量是共享, 同一userId下, 不管開幾個client, 流量也是共享

• 所以我們可以限制整個kafka cluster的user上限或client上限來控制總流量

  • ex. 限制cluster能最多能服務100個userId, 確保kafka總流量為100MB/s

  • ex. 限制cluster能最多能服務100個clientId, 確保kafka總流量為100MB/s, 但某個user可能會占用這100個client