More Related Content Similar to Kafka in Depth Similar to Kafka in Depth (20) Kafka in Depth3. Hardware
3
• Node: 3
• Memory: 16 GB
• CPU: 8 CPU/Core
Zookeeper + Kafka (現在)
• Zookeeper
• Node: 3
• Memory: 4 GB
• CPU: 4 CPU/Core
• Kafka Broker
• Node: 3
• Memory: 12 GB
• CPU: 8 CPU/Core
我們可以調整成:
4. Kafka 新版
與
Zookeeper
4
新版本的 Kafka broker 之間的資料不會
再流向 Zookeeper
新版本使用 _consumer_offsets Topic 讓
Kafka broker 自己紀錄 message offset
新版本使用 metadata API 來達到 broker
間的負載平衡
5. DevOps 會做的事 - Broker OS 作業系統優化
• Broker OS 作業系統優化
• Page cache : (buffer for kafka active segment)
• 主要作為檔案系統 file system 上檔案內容的 Buffer 使用,提高 I/O
• File descriptor limitation : >100,000
• Swapping : disable
• TCP : 暫不調整
• JVM GC : 使用 G1, JVM 至少 VM 的 60%
5
6. DevOps 會做的事- Broker System
Tuning
• https://kafka.apache.org/documentation/
• # server settings and socket settings
• broker.id=0 #不能與其他 broker 衝突 , 預設 broker.id.generation.enable=true
• 若為自動產生重新啟動 kafka 時 Topic 的partition 所在 broker 的 message 依舊是原 broker.id,會錯亂。
• socket.send.buffer.bytes=1048576 # Centos : sysctl net.ipv4.tcp_rmem
• socket.receive.buffer.bytes=1048576 # Centos: sysctl net.ipv4.tcp_wmem
• socket.request.max.bytes=104857600
• num.replica.fetchers=4 # 從一台 broker 同步 Message,最多能開多少個 Thread,可增加 IO 效率
• num.network.threads=3 # (CPU core 總數 + 1 )
• NetWorkerProcessorAvgIdlePercent JMX 指標,若指標低於0.3,則建議調高該值。
• num.io.threads=1 #(可以設定 CPU 核心數的 2 倍)
• queued.max.requests=1000
6
7. DevOps 會做的事- Broker System
Tuning
• # message.max.byte
• 因 producer 的 message 不做壓縮,因此需加大些。
• message.max.bytes=3070000
• # (3 MB) 故意設定比 3145728 小一點,
• 此設定調整需要同時將 replica.fetch.max.bytes 一起調整,不然會無法進行 replica,
• Consumer 端也要調整 max.partition.fetch.bytes, fetch.message.max.bytes 。
• replica.fetch.max.bytes= 3145728 # 請配合 message.max.bytes 修改
• replica.socket.receive.buffer.bytes=262144
• rerplica.lag.time.max.ms=10000
• # 如果 Leader 發現 follow 超過 10 秒沒有向它發起 fetch 請求
• rerplica.lag.max.messages=4000 # 相差4000條就移除
7
8. DevOps 會做的事- Broker System
Tuning
• # log basic setting
• log.dirs=/data-disk/kafka-logs #(message 寫的位置要特別設定)
• auto.create.topics.enable=false
• delete.topic.enable=false
• num.partitions=3 #可設定伺服器上總實體處理器核心數量的一半
• default.replication.factor=3
• replication.factor=3 #視情境調整,各 Topic 可獨立設定
• # replication.factor > Producer: min.insync.replicas
8
9. DevOps 會做的事- Broker System
Tuning
• # log purge settings
• log.flush.interval.messages=10000
• # 當 message 在記憶體的數量達此數值時,寫入到 log storage 中。
• log.flush.interval.ms=1000
• # 與上面的 log.flush.interval.messages 比對,看誰先達到門檻值便執行 log 寫入作業。
• log.flush.scheduler.interval.ms=3000
• log.segment.delete.delay.ms=60000
9
10. DevOps 會做的事- Broker System
Tuning
• # log retention
• log.roll.hours=1 # 強制在此時間後,建立新的 Segment,因為沒有壓縮 message, 因此,rolling 設定頻繁
一些。
• log.cleanup.policy=delete /compact
• log.cleaner.delete.retention.ms=86400000 (1天)
• log.retention.hours=72 #(Kafka 預設為 7 天 改為 3 天 ) ,超過時間便依據 log.cleanup.policy 策略
處理
• log log.retention.bytes=-1 # 暫不限制,Kafka 永遠不會根據大小來刪除 log, 而先依賴其他
retention policy
• log.segment.bytes=1073741824
• # (1GB) Log file 超過此數值變產生新的 log file,因為我們的 message 沒有壓縮,因此可調大一些。
• log.retention.check.interval.ms=60000
• log.cleaner.enable=true
10
11. DevOps 會做的事- Broker System
Tuning
• # Zookeeper
• zookeeper.session.timeout.ms
• # 如果 message.max.bytes 加大, JVM 的 GC 會拉長,因此這個直也要跟著拉長一些。
11
12. RD 對 Producer 可以調整的事
• 要在 Through Put 和 Message可靠性之間做取捨
• 請在 .NET 程式碼中的 kafka library 找到相對應的參數設定
• enable.auto.commit : false
• acks : all / -1
• 搭配設定 min.insync.replicas 數量,確保 message 有正常 replica 後,才算正常發
送成功,會降低效能,但換來**"高可靠"**不丟失 Message。 同時在 Broker 設定
提高 num.replica.fetchers 可以降低此 producer acks 設定的影響程度。
• 若 kafka broker 發生問題時會拋出類似 NotEnoughReplicas 或
NotEnoughReplicasAfterAppend 給 producer,producer 必須處理這類的錯誤,
避免資料遺失。
• 若是 linux 之類的 system log 可以設定為 0
12
13. RD 對 Producer 可以調整的事
• min.insync.replicas: 1 # 需要保證 ISR 中至少有多少個 replica
• 配合 ack: -1 才生效,目前使用預設值 1 即可,因設定值會影響到效能。
• 這邊若未達 min.insync.replicas: 1 系統會發出錯誤,因此需要 error handling
13
14. RD 對 Producer 可以調整的事
• buffer.memory: 67108864 (64MB)
• compression.type: none (以空間換取時間)
• linger.ms: 0
• 預設為 0 表示沒有延遲,收到即發送,不會等待 batch.size 滿了再發送。
• 若沒有立即性的訊息處理需求,可搭配 batch.szie 一起使用,減少 TCP 網路的傳輸次數
• batch.size: 524288 (512K)
• #累積到多少 message 容量大小, 可以減少 TCP 網路的傳輸次數和硬碟 IO 的次數, 需要在效
率和即時性方面做
• unclean.leader.election.enable: false
• # 關閉 unclean leader 選舉,即不允許非 ISR 中的副本被選舉為 leader,以避免數據丟失
14
15. ISR(In-Sync Replica)
• 每個 Partition leader 會維護一個 Replica 列表
• 如果一個 Follower 比一個 Leader 落後太多,或者超過一定時
間未發起 message replication request,則 Leader 將其重 ISR
中移除
• 當 ISR 中所有 Replica 都向 Leader 發送 ACK 後,Leader 才
commit
15
16. RD 對 Producer 可以調整的事
• retries: 0 ,
• 預設值為 0 ,不做 retry,
• 若有需要進行 retry = MAX_VALUE ,且對 message 有其**"順序性"**的要求,必須同步設
定 max_in_flight_requests_per_connection: 1,目的是為了讓 producer 每次發送後都等待
kafka broker 回覆,會有效能影響。
• max.in.flight.requests.per.connection: 1
• 預設值為 5 , 請依照使用情境設定,若 message 有順序性,請設定為 1 ,不過這會降低
throughput。
• 若發現 producer 的瓶頸在 IO bound,且各個 broker 負載不高,可適當增加該值。
• 過度增加此參數會造成 producer 的記憶體負載升高,還可能造成不必要的 lock 而降低
throughput
• 限制 Consumer 端在一個 Connection 上能夠發送的未響應請求的個數。設
置此值是1表示kafka broker在響應請求之前client不能再向同一個broker發
送請求。
16
17. RD 對 Consumer 可以做的事
• consumer.poll: 1000 ms
• # Broker 是透過 Consumer 再規則內未向他 fech, 便可能認定 consumer 掛了
• # Follower 負載過高太慢了,不希望他拖慢整體效能,便把他從 ISR 清單中移除。
• 注意 consumer 是有可能被踢出 consumer group 的,如何踢呢? 會依照系統預設條件及我們
給的設定值。
• # Consumer 被踢出便可能進行 partition rebalance,重新分配 consumer,影響甚大。
• session.timeout.ms: 10 s
• # 若某個 consumer 在整個 kafka consumer group 中的 heartbeat 連線愈時,會再此設定時間後被移除 group
• receiver.buffer.bytes: 1048576
• #(與 broker 的設定相同)
• fetch.message.max.bytes: 3200000
• # 此設定需要與 broker 的 message.max.bytes 配合修改,建議大於或等於
• max.partition.fetch.bytes: 3200000
• # 此設定需要與 broker 的 message.max.bytes 配合修改,建議大於或等於
17
18. Partition Rebalance
• ConsumerGroup 中消費者數量大於 Topic 中的分區數量,則某個消費者將沒有 Partition 可消費。
如下圖:Consumer 5,消費不到任何 message。
• ConsumerGroup 新增了幾個消費者,或者減少了幾個消費者,那麼 Kafka Broker 就會重新分配
Partition 給 Consumer。 (range 和 round-robin)
• 在 Rebalance 期間,Consumer 不能消費任何 Message
18
19. Message 重
複消費
19
比如 ConsumerA 得到了 PartitionA 的幾條 Message,
進行了處理,然後還未來得及向 Broker 確認它消費完了
這幾條消息 (未commit),它就掛了。
Broker rebalance 之後,把 PartitionA 交給了
ComsumerB 訂閱,那麼 ConsumerB 也會得到
ConsumerA 處理了但未提交的那幾條消息。
那這幾條消息就被重複消費了。
21. 如何選擇
Partition 數
量
21
More Partitions Lead to Higher Throughput
More Partitions Requires More Open File Handles
More Partitions May Increase Unavailability
More Partitions May Increase End-to-end Latency
More Partitions May Require More Memory In the
Client
22. 確保 Message 的順序性?
• Topic 只設定一個 Partition
• 沒有可靠性,因為 broker 掛了就全掛了,producer / consumer 無法
再讀寫 Message
• Replication 只能確保掛之前的 Message 還可以被消費
• Topic 可以設定多個 Partition
• Producer : max.in.flight.requests.per.connection: 1
• 每個 Message 給同一個 Partition Key (kafka 根據key 決定要放在哪個 Partition)
• Partition Key 坐落的 Broker 掛了,可以移轉到其他 Partition 繼續接
收 Message
• 上述兩種都只能由一個 Consumer 處理,因此,無法享受到負
載平衡。
22
Editor's Notes LEO: log end offset
HW :High watermark https://www.cnblogs.com/huxi2b/p/6223228.html https://www.confluent.io/blog/how-choose-number-topics-partitions-kafka-cluster