Download to read offline
Uploaded byRico Chen
Kafka cluster best practices
该文档介绍了Kafka集群的实践，包括Kafka的特性、架构及其在微服务架构中的作用。它详细解释了Kafka的生产者、消费者、主题、分区等关键概念以及重要配置设置，展示了Kafka如何提高系统的可靠性、可扩展性和性能。文档还提供了Kafka在实际中的演示和性能测试结果。
Kafka cluster best practices
- 1.
- 2. 大綱 • Kafka 簡介 •Kafka 能幫系統什麼 • MicroService Architecture • Kafka 架構和重要名詞、職責 • Kafka 重要設定 • Demo - NetCore 實現 pub / sub • Perf Test of Throughput
- 3. KAFKA 簡介 • 分散式串流平台，具備高吞吐量、低延遲、高可用和高效能(responseof ms)特徵 • 2011年Open Source，且被各大企業廣泛應用，2017年11正式發布1.0.0(淬鍊7年) • Power by: LinkedIn、airbnb、Mozilla、Twitter、LINE、skyscanner、trivago、 Hotel.com、PayPal、Uber、Yahoo… • 安裝簡易、Online 水平擴充、Apache 頂級專案且資源取得容易 • 基於pub/sub的MQ 系統為主要設計 • 提供Message的Durability、順序保證(by each partition)和三種傳送類型 RabbitMQKafka
- 4. KAFKA 能幫系統什麼 • 降低系統相依性，生產者和消費者透過Kafka當中介層傳輸Message •提高系統承載性，不會因為突發流量(request)壓力 ，導致系統無法服務 • 提高系統擴充性，水平擴充kafka很簡單，AP端只須改config，無須改code • 提高系統可靠性，一些操作(Log Aggregation)並不需要耗用主要系統資源，可分散至 其他系統進行處理 • 系統邁向Microservice的基石，隔離每個service錯誤，不讓主要系統服務Crash，影響 公司收入 • *提供系統處理Message彈性，Kafka的Message有持久化特性，這增加Message冗餘 性，如Consumer拉完Message後，後續處理過程失敗的話，也不用擔心資料遺失風 險
- 5. MICROSERVICE ARCHITECTUREhttpRequest httpResponse 1.Check Token Validation 1.1Log this WebAPI(path...) 2.Get Player’s Profile 2.1 Log this WebAPI(path…) 3.Redirect to Lobby 4.Get Game Lists 4.1 Log this WebAPI(path…) 5.Get Recommend Games 5.1 Log this WebAPI(path..) 6.Get Jackpot Contribution 6.1 Log this WebAPI(path..) 7. Get Bonus’s Info 7.1 Log this WebAPI(path..) 7.Get Banner 7.1 Log this WebAPI(path..) ……. a. Play Game a.1 Log this WebAPI(path..) ..… httpRequest httpResponse Logger Service Recommend Service Game Lists Service Jackpot Service Bonus Service Banner Service Producer of Logger Producer of Game Lists MQ Topic of Logger MQ Topic of Game List KafkaEvent Listener Consumer of Logger Consumer of Game Lists Event Listener
- 6. KAFKA 架構 Producer Broker Consumer / ConsumerGroup Front EndFront End Front End Broker2 Broker3 Push(batch) Data Warehouse Real-Time monitor pull Message Switching Kafka cluster(p2p) replica zookeeper cluster(MA) Topoc’s config,broker status Cluster membership… Partitoin,Message Queue, offset manager,topic, replica manager, GroupCoordinator(rebalance)… socket socket socket Broker1 heartbeat
- 7. 重要名詞和職責 • Producer(生產者): 推送Messageto Broker(Kafka) • Broker(Kafka server/node):MQ process(kafka cluster最小單位) • Cosnumer/group(消費者/群組): 拉取Message from Broker(Kafka) • Topic(主題): Message要分類在那個Queue • Partition(分區): 有順序存放Message、提供容錯、平行、負載平衡和擴充處理 • Offset(位移號): 每一個Partition中，每一Message的流水號
- 8. KAFKA 重要設定 PRODUCER • MessageDelivery • Acks 類型 At most once(最多一次) At least once(最少一次) Exactly once(只有一次) 說明 Message可能遺失，但絕不重複發送 Message不太可能遺失，但可能重複發送 Message只會發送一次 類型 acks=0 acks=1 acks=all 說明 Producer不會等kafka回應，無法保證 message是否成功送至kafka Producer等待kafka’s Leader回應成功寫入 local file，但不保證follower也成功寫入 Producer不只會等Leader，也 會等待所有同步中的follower也 成功寫入local file Kestrel Server Kestrel Server Kestrel Server Load Balance Kafka Cluster BatchSzie BufferSize Async FireAndForget NonCompression Send error Handling Retry policy httpRequest Producer
- 9. KAFKA 重要設定 BROKER • Partition數量= broker倍數，單一topic不建議超過1024 • num.recovery.threads.per.data.dir=2 • Log.retention.hours=2 • replica.high.watermark.checkpoint.interval.ms=5000 • replica.fetch.wait.max.ms=3000 • min.insync.replicas=1 • log.cleanup.policy=delete • log.cleaner.enable=true • zookeeper.session.timeout.ms= 6000 • default.replication.factor=2 Partition 0 Leader 0 Replica 0,1 ISR 0,1 #1 Partition 1 Leader 1 Replica 1,2 ISR 1,2 #2 Partition 2 Leader 2 Replica 2,0 ISR 2,0 #3 Kafka Cluster
- 10. KAFKA 重要設定 CONSUMER • 開發上使用ConsumerGroup，才能平行處理，且自動負載平衡 •Consumer數量=broker 倍數 • auto.offset.reset=Earliest • Batch size越小才能避免Lag快速累積 類型 Earliest(最舊) Latest(最新) 說明 讀取最早一次offset 讀取最後一次offset Kafka Cluster MaxPollRecords FetchMaxWaitTime FetchMinSize FetchBatchSize Batch Insert Failed Event Process Consumer
- 11. KAFKA 重要設定 JVM • 避免OOM •避免頻繁觸發GC -Xmx8g –Xms8g -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 - XX:MaxMetaspaceFreeRatio=80 -XX:MinMetaspaceFreeRatio=50 -XX:G1HeapRegionSize=16M - XX:InitiatingHeapOccupancyPercent=35 -Xms: Set initial Java heap size -Xmx: Set maximum Java heap size +UseG1GC: Enable G1 GC MaxGCPauseMillis: Set maximum pause MaxMetaspaceFreeRatio: Set maximun metaspace free ratio MinMetaspaceFreeRatio: Set minimun metaspace free ratio G1HeapRegionSize: Adjust G1 region on each heap InitiatingHeapOccupancyPercent: initial Java heap occupancy threshold
- 12. DEMO - NETCORE實現 PUB / SUB
- 13. PERF TEST OFTHROUGHPUT • OS: CentOS Linux release 7.4.1708 • CPU : 2*2 E5-2620 v4 @ 2.10GHz • Memory: 4 GB • Kafak’s Version:1.0.1 • Producer (num-records=100000, record-size=100, throughput=1000, batch.size=100, compression.type=none)
- 14. PERF TEST OFTHROUGHPUT • Consumer (messages=100000, num-fetch-thread=2) Result of Producer Avg latency:0.88 ms Max latency:195 ms Sent: 999.920 records/sec Result of Consumer 9.5367 MB /sec 102774 message/sec
- 15.
- 16. 參考 • https://kafka.apache.org/ • https://github.com/apache/kafka •http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html • https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm
Editor's Notes
- #4 https://github.com/apache/kafka https://github.com/rabbitmq/rabbitmq-server
- #5 Note:實務上我個人會把失敗Message塞入nosql，並在publish一個message，通知負責重送message的consumer進行處理
- #6 Business drawback 1.Maybe reduce revenue Technical drawbacks 1.Result in dependencies 2.Failure affects everything 3.Chang is slow
- #7 Do not co-locate zookeeper on the same boxes as Kafka Zookeeper->Topic 有哪些Partition, Replica 存放在哪里, Leader 是誰 Controller :負責所有Partition 的leader/follower 關係 Zookeeper主要監控broker狀態，kafka依賴他達成資料一致性(sync)，透過zook選出leade的partition，Leader負責讀寫、把每個partition分散在每台broker 如果有某一個broker掛了，zookeeper也會通知producer and consumer Zookeeper cluster基本3台較好，奇數比較可以避免整個cluster crash(過半就crash) Sync，這一步leader開始分配消費方案，即哪個consumer負責消費哪些topic的哪些partition。一旦完成分配，leader會將這個方案封裝進SyncGroup請求中發給coordinator，非leader也會發SyncGroup請求，只是內容為空。coordinator接收到分配方案之後會把方案塞進SyncGroup的response中發給各個consumer。這樣組內的所有成員就都知道自己應該消費哪些分區了 P2P(peer 2 peer):好處是沒有單點問題，壞處是很難達成資料的一致性和備份，如果其他節點掛了，將導致資料遺失。
- #8 为了实现传统Message Queue消息只被消费一次的语义，Kafka保证每条消息在同一个Consumer Group里只会被某一个Consumer消费。与传统Message Queue不同的是，Kafka还允许不同Consumer Group同时消费同一条消息，这一特性可以为消息的多元化处理提供支持。 Consumergroup可以同時消費多個topic
- #9 Compression=gzip,snap (https://dotblogs.com.tw/ricochen/2017/10/29/052852) send.buffer.bytes=100*1024、batch.size=100 producer.type=async max.in.flight.requests.per.connection=5 99%的producer不須tun acks=-1等待所有ISR接收到消息后再给Producer發送Response(影響durability) 只找partition的leader 溝通並push message compression codecs ('gzip', 'snappy', 'lz4’) batch.size太大會timeout，並增加latency ( Total bytes between flush() / partition ) max.block.ms=60000 Linger.ms ( time based batching) max.in.flight.requests.per.connection=5，由於大於1，如果producer發送失敗會retry，這是會影響排序 High batch=high throughput =High latency
- #10 https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines 更多partition可以提高throughput 降低latency降低records queue time message.max.bytes=1000012 sure you set replica.fetch.max.bytes to be equal or greater than message.max.bytes log.flush.interval.messages=10000 higher will improver performance min.insync.replicas=2 num.network.threads=配置线程数量为cpu核数加1. num.io.threads= 配置线程数量为cpu核数2倍，最大不超过3倍. num.replica.fetchers 配置多可以提高follower的I/O并发度，单位时间内leader持有跟多请求，相应负载会增大，需要根据机器硬件资源做权衡 replica.fetch.min.bytes=1 太大可能follower讀取消息不及時 replica.fetch.max.bytes= 1MB，这个值太小，5MB为宜，根据业务情况调整 replica.high.watermark.checkpoint.interval.ms=5000 replica.fetch.wait.max.ms=500 follow拉取频率，频率过高，会导致cpu飙升，因为leader无数据同步，leader会积压大量无效请求情况，影響吞吐量
- #11 https://dotblogs.com.tw/ricochen/2017/10/29/015517 max.poll.records=5000 fetch.max.wait.ms=500 fetch.min.bytes=1 只找partition的leader溝通poll message At most once—Messages may be lost but are never redelivered. At least once—Messages are never lost but may be redelivered. Exactly once—this is what people actually want, each message is delivered once and only once. 数据一致性保证 一致性定义:若某条消息对Consumer可见,那么即使Leader宕机了,在新Leader上数据依然可以被读到 1.HighWaterMark简称HW: Partition的高水位，取一个partition对应的ISR中最小的LEO作为HW，消费者最多只能消费到HW所在的位置，另外每个replica都有highWatermark，leader和follower各自负责更新自己的highWatermark状态，highWatermark <= leader. LogEndOffset 2.对于Leader新写入的msg，Consumer不能立刻消费，Leader会等待该消息被所有ISR中的replica同步后,更新HW,此时该消息才能被Consumer消费，即Consumer最多只能消费到HW位置 这样就保证了如果Leader Broker失效,该消息仍然可以从新选举的Leader中获取。对于来自内部Broker的读取请求,没有HW的限制。同时,Follower也会维护一份自己的HW,Folloer.HW = min(Leader.HW, Follower.offset) 使用Consumer high level API时，同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。 如果需要实现广播，只要每个Consumer有一个独立的Group就可以了。要实现单播只要所有的Consumer在同一个Group里
- #12 Zookeeper:Make sure you allocate sufficient JVM , good starting point is 4Gb Min/MaxMetaspaceFreeRatio:avoid high frequency trigger GC MaxGCPauseMillis:设置最大GC停顿时间(GC pause time)指标(target). 这是一个软性指标(soft goal), JVM 会尽量去达成这个目标. InitiatingHeapOccupancyPercent:启动并发GC周期时的堆内存占用百分比. G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示"一直执行GC循环". 默认值为 45. G1HeapRegionSize:使用G1时Java堆会被分为大小统一的的区(region)。此参数可以指定每个heap区的大小. 默认值将根据 heap size 算出最优解. 最小值为 1Mb, 最大值为 32Mb. 頻繁GC會讓application 延遲 G1也是并发收集器，G1解决了CMS碎片，同时增加了更多响应时间优先的特性。 -XX:G1HeapRegionSize=4m: 设置内存分块的大小。范围是1MB~32MB。是一个很常用的参数。当系统中存在大量大对象的时候，大的Region会提升GC效率。 XX:InitiatingHeapOccupancyPercent=50: 设置使用整个对的x%时，系统开始进行并行GC。注意是整个堆的百分比。这与CMS收集器的类似参数不同 -XX:MaxGCPauseMillis=200: 单位为毫秒。此值为建议JVM的最长暂停时间。只是建议值，G1只能尽量保证，而无法完全保证。 Tuning JVM Garbage Collection for Production Deployments https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm Garbage First Garbage Collector Tuning http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html
- #13 1.HA test 2.Message delivery test 3.Auto rebalance(RR) test 4.Message order test
- #14 ./kafka-producer-perf-test.sh --num-records 100000 --record-size 100 --topic perfteest --throughput 1000 --producer-props bootstrap.servers=172.16.79.21:9092,172.16.79.22:9092,172.16.79.23:9092 max.in.flight.requests.per.connection=3 batch.size=100 compression.type=none
- #15 ./kafka-consumer-perf-test.sh --messages 100000 --broker-list=172.16.79.21:9092,172.16.79.22:9092,172.16.79.23:9092 --topic perfteest --group perfteest-group --new-consumer --num-fetch-threads 2