Kafka in Depth
Download as PPTX, PDF0 likes99 views
本文档详细介绍了Kafka的生产和消费配置，包括集群架构、硬件要求、系统调优和参数设置。针对生产者和消费者的设置提供了具体的建议，以优化消息的可靠性、吞吐量和性能。文档还讨论了如何通过分区和复制策略提高消息处理的效率和可靠性。
Kafka in Depth
- 1. Kafka in depth 吳奕慶 1
- 2. Agenda 2 Kafka cluster of Production DevOps 會做的事 RD 對 Producer 可以調整的事 RD 對 Consumer 可以做的事
- 3. 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 處理了但未提交的那幾條消息。 那這幾條消息就被重複消費了。
- 20. Partition and Replication 20 Partition 分散 Message 到各 Broker， 等於有分散負載。 Replication 提升 Message 的 可靠性，降低丟失率。
- 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
- 23. Kafka Stream and KSQL 應用 23