【譯】Kafka最佳實踐 / Kafka Best Practices

本文來自於DataWorks Summit/Hadoop Summit上的《Apache Kafka最佳實踐》分享，裏面給出了不少關於Kafka的使用心得，很是值得一看，今推薦給你們。

硬件配置

 

JBOD: Just bunch of disks，就是普通的一堆磁盤組成的集羣

OS調優

1 頁緩存：儘可能分配與全部日誌的激活日誌段大小相同的頁緩存大小

2 文件描述符限制： 10萬以上

3 禁掉swap

4 使用Java 8和G1，分配6~8GB的堆大小

 磁盤調優

1 使用多塊磁盤，專屬分配給kafka

2 通常環境使用JBOD便可，但JBOD有一些固有的缺陷，好比磁盤失敗將致使Kafka異常關閉，形成數據不一致，社區已經着手解決

3 使用EXT4或XFS

4 儘可能使用SSD

基本監控

1 CPU負載

2 網絡帶寬

3 文件句柄數

4 磁盤空間

5 磁盤IO性能

6 垃圾回收

7 zookeeper監控

如何監控備份不足狀況發生？

JMX指標：kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

可能緣由

• broker掛了
• controller問題
• zk問題
• 網絡問題

解決辦法

• 調整ISR參數，好比 min.insync.replica和replica.lag.time.max.ms, num.replica.fetchers
• 增長broker數

 controller問題

1 避免zk會話超時

• ISR抖動
• zk性能問題
• Long GC
• 網絡問題

 2 監控controller

• kafka.controller:type=KafkaController,name=ActiveControllerCount應該=1
• 監控LeaderElectionRate

unclean leader選舉

1 容許非ISR中的副本成爲leader

2 監控JMX指標： kafka.controller:type=ControllerStats,name=UncleanLeaderElectionsPerSec

集羣評估(sizing)

1 broker評估

• 單broker上的分區數<2000
• 控制分區大小，不要超過25GB

2 broker數評估：根據retention和流量進行評估

3 集羣擴展

• 磁盤使用率<60%
• 網絡使用率<75%

4 集羣監控

• 確保topic分區分佈儘可能均勻
• 確保broker節點不會磁盤、帶寬耗盡

broker監控

1 分區數： kafka.server:type=ReplicaManager,name=PartitionCount

2 leader副本數： kafka.server:type=ReplicaManager,name=LeaderCount

3 ISR擴容率/縮容率：kafka.server:type=ReplicaManager,name=IsrExpandsPerSec

4 入站消息/出站消息：Message in rate/Byte in rate/Byte out rate

5 broker網絡請求處理平均空閒率： NetworkProcessorAvgIdlePercent

6 請求平均處理空閒率： RequestHandlerAvgIdlePercent

topic評估

1 分區數

• 至少和最大的消費者組中consumer的數量一致
• 分區不要太大，小於25GB
• 要考慮將來業務的擴容

2 使用keyed消息，即指定key

3 爲擴展分區確立閾值，即肯定當分區大小達到閾值時增長topic分區數

選擇分區

1 基於TPS需求大體肯定分區數, 即目標TPS/min(Producer TPS, Consumer TPS)

2 更多分區意味着更多的文件句柄、消息處理延時和更多的內存使用

份額控制

1 避免惡意客戶端並維護SLA

2 設定字節率閾值限制

3 監控throttle-rate，byte-rate

4 replica.fecth.response.max.bytes： 設置follower副本FETCH請求response大小

5 限制帶寬： kafka-reassign-partitions.sh --throttle options...

Kafka producer

1 使用Java版本producer

2 使用kafka-producer-perf-test.sh測試

3 設置好內存、cpu、batch、壓縮等參數

• batch.size: 越大，TPS越大，延時也越大
• linger.ms: 越大，TPS越大，延時也越大
• max.in.flight.requests.per.connection: 增長TPS，關乎消息接收順序
• compression.type: 設置壓縮類型，提高TPS
• acks: 設置消息持久性級別 

4 避免發送大消息(會使用更多內存，下降broker處理)

性能調優

1 若是TPS<網絡帶寬

• 增長用戶線程
• 增長batch size
• 使用多個producer實例
• 添加分區

2 acks=-1時如何下降延時：增長num.replica.fetchers

3 跨數據中心的傳輸：增長Socket緩衝區設置，以及TCP緩存設置

監控指標

• batch-size-avg
• compression-rate-avg
• waiting-threads
• buffer-available-bytes
• record-queue-time-max
• record-send-rate
• records-per-request-avg

Kafka Consumer

1 使用kafka-consumer-perf.test.sh測試

2 TPS問題

• 分區數不夠
• OS緩存命中過低，分配更多頁緩存
• 處理邏輯太重

3 位移管理： 異步提交+手動提交

4 重要參數

• fetch.min.bytes、fetch.max.wait.ms
• max.poll.interval.ms
• max.poll.records
• session.timeout.ms

監控

1 consumer lag

2 JMX指標： records-lag-max

3 bin/kafka-consumer-groups.sh

4 如何減小lag

• 分析consumer，是GC問題仍是consumer hang住了
• 增長consumer instances
• 增長分區數

無數據丟失配置

1 producer端

• retries = MAX
• acks=all
• max.in.flight.requests.per.connection = 1
• 關閉producer

 2 broker端

• replication factor >= 3
• min.insync.replicas = 2
• 關閉unclean leader選舉

 3 consumer端

• 關閉auto.offset.commit
• 消息被處理後提交位移