今天帶來一篇譯文“調優Apache Kafka集群”，里面有一些觀點並無太多新穎之處，但總結得還算詳細。該文從四個不同的目標出發給出了各自不同的參數配置，值得大家一讀~ 原文地址請參考：https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
==========================================
Apache Kafka是當前最好的企業級流式處理平台。把你的應用程序鏈接到Kafka集群，剩下的所有事情Kafka都可以幫你做了：自動幫你完成負載均衡，自動實現Zero-Copy的數據傳輸、消費者組成員變動時自動的rebalance以及應用狀態持久化存儲的自動備份以及分區leader自動的故障轉移等——運維人員的夢想終於成真了！
————筆者：最近在看Apache Flink。說到streaming這部分，Flink可一點都不比Kafka streams差。至於是不是最好的流式處理平台，仁者見仁吧~~
使用默認的Kafka參數配置你就能夠從零搭建起一個Kafka集群環境用於開發及測試之用，但默認配置通常都不匹配你的生產環境，因此必須要做某種程度的調優。畢竟不同的使用場景有着不同的使用需求和性能指標。而Kafka提供的各種參數就是為了優化這些需求和指標的。Kafka提供了很多配置供用戶設置以確保搭建起來的Kafka環境是能夠滿足需求目標的，因此詳細地去調研這些參數的含義以及針對不同參數值進行測試是非常重要的。所有這些工作都應該在Kafka正式上生產環境前就做好，並且各種參數的配置要考慮未來集群規模的擴展。
執行優化的流程如下圖所示：
- 明確調優目標
- 有針對性地配置Kafka server端和clients端參數
- 執行性能測試，監控各個指標以確定是否滿足需求以及是否有進一步調優的可能
一、確立目標
第一步就是要明確性能調優目標，主要從4個方面考慮：吞吐量(throughput)、延時(latency)、持久性(durability)和可用性(availability)。根據實際的使用場景來確定要達到這4個中的哪個(或哪幾個)目標。有時候我們可能很難確定自己到底想要什么，那么此時可以嘗試采用這樣的方法：讓你的團隊坐下來討論一下原本的業務使用場景然后看看主要的業務目標是什么。確立目標的原因主要有兩點：
- “魚和熊掌不可兼得”——你沒有辦法最大化所有目標。這4者之間必然存在着權衡(tradeoff)。常見的tradeoff包括：吞吐量和延時權衡、持久性和可用性之間權衡。但是當我們考慮整個系統時通常都不能孤立地只考慮其中的某一個方面，而是需要全盤考量。雖然它們之間不是互斥的，但使所有目標同時達到最優幾乎肯定是不可能的
- 我們需要不斷調整Kafka配置參數以實現這些目標，並確保我們對Kafka的優化是滿足用戶實際使用場景的需要
下面的這些問題可以幫助你確立目標：
- 是否期望着Kafka實現高吞吐量(TPS，即producer生產速度和consumer消費速度)，比如幾百萬的TPS？由於Kafka自身良好的設計，生產超大數量的消息並不是什么難事。比起傳統的數據庫或KV存儲而言，Kafka要快得多，而且使用普通的硬件就能夠做到這點
- 是否期望着Kafka實現低延時(即消息從被寫入到被讀取之間的時間間隔越小越好)？ 低延時的一個實際應用場景就是平時的聊天程序，接收到某一條消息越快越好。其他的例子還包括交互性網站中用戶期望實時看到好友動態以及物聯網中的實時流處理等
- 是否期望着Kafka實現高持久性，即被成功提交的消息永遠不能丟失？比如事件驅動的微服務數據管道使用Kafka作為底層數據存儲，那么就要求Kafka不能丟失事件。再比如streaming框架讀取持久化存儲時一定要確保關鍵的業務事件不能遺漏等
- 是否期望着Kafka實現高可用？即使出現崩潰也不能出現服務的整體宕機。Kafka本身是分布式系統，天然就是能夠對抗崩潰的。如果高可用是你的主要目標，配置特定的參數確保Kafka可以及時從崩潰中恢復就顯得至關重要了
二、配置參數
下面我們將分別討論這四個目標的優化以及對應的參數設置。這些參數涵蓋了producer端、broker端和consumer端的不同配置。如前所述，很多配置都提現了某種程度的tradeoff，在使用時一定要弄清楚這些配置的真正含義，做到有的放矢。
producer端
- batch.size
- linger.ms
- compression.type
- acks
- retries
- max.in.flight.requests.per.connection
- buffer.memory
Broker端
- default.replication.factor
- num.replica.fetchers
- auto.create.topics.enable
- min.insync.replicas
- unclean.leader.election.enable
- broker.rack
- log.flush.interval.messages
- log.flush.interval.ms
- unclean.leader.election.enable
- min.insync.replicas
- num.recovery.threads.per.data.dir
Consumer端
- fetch.min.bytes
- auto.commit.enable
- session.timeout.ms
1 調優吞吐量
Producer端
- batch.size = 100000 - 200000（默認是16384，通常都太小了）
- linger.ms = 10 - 100 (默認是0)
- compression.type = lz4
- acks = 1
- retries = 0
- buffer.memory：如果分區數很多則適當增加 (默認是32MB)
Consumer端
- fetch.min.bytes = 10 ~ 100000 (默認是1)
2 調優延時
Producer端
- linger.ms = 0
- compression.type = none
- acks = 1
Broker端
- num.replica.fetchers：如果發生ISR頻繁進出的情況或follower無法追上leader的情況則適當增加該值，但通常不要超過CPU核數+1
Consumer端
- fetch.min.bytes = 1
3 調優持久性
Producer端
- replication.factor = 3
- acks = all
- retries = 相對較大的值，比如5 ~ 10
- max.in.flight.requests.per.connection = 1 (防止亂序)
Broker端
- default.replication.factor = 3
- auto.create.topics.enable = false
- min.insync.replicas = 2，即設置為replication factor - 1
- unclean.leader.election.enable = false
- broker.rack: 如果有機架信息，則最好設置該值，保證數據在多個rack間的分布性以達到高持久化
- log.flush.interval.messages和log.flush.interval.ms: 如果是特別重要的topic並且TPS本身也不高，則推薦設置成比較低的值，比如1
Consumer端
- auto.commit.enable = false 自己控制位移
4 調優高可用
Broker端
- unclean.leader.election.enable = true
- min.insync.replicas = 1
- num.recovery.threads.per.data.dir = log.dirs中配置的目錄數
Consumer端
- session.timeout.ms：盡可能地低
三、指標監控
1 操作系統級指標
- 內存使用率
- 磁盤占用率
- CPU使用率
- 打開的文件句柄數
- 磁盤IO使用率
- 帶寬IO使用率
2 Kafka常規JMX監控
3 易發現瓶頸的JMX監控
4 clients端常用JMX監控
5 broker端ISR相關的JMX監控
==========================================
以上就是這篇原文的簡要譯文。還是那句話，里面的很多參數設置都已經司空見慣了，並無太多新意。不過這篇文章從吞吐量、延時、持久化和可用性4個方面給出了不同的思考。從這一點上來說還是值得一讀的。