kafka 設計概要
吞吐量/延時
消息持久化
負載均衡和故障轉移
伸縮性
一些常用命令
通過GetOffsetShell 工具類查看 topic 分區消息
./kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.2.52:9092 --topic test
查看當前topic 當前對應的信息
./kafka-topics.sh --zookeeper 192.168.2.52:2181 --describe --topic test1
Topic: test1 Partition: 0 Leader: 0 Replicas: 0 Isr: 0
Topic: test1 Partition: 1 Leader: 0 Replicas: 0 Isr: 0
修改kafka分區個數
./kafka-topics.sh -alter --zookeeper 192.168.2.52:2181 --partitions 2 --topic test
給現有topic 添加新的配置 添加壓實配置
./kafka-configs.sh --zookeeper 192.168.2.52:2181 --alter --entity-type topics --entity-name test --add-config cleanup.policy=compact
查看當前topic 的配置
./kafka-configs.sh --zookeeper 192.168.2.52:2181 --describe --entity-type topics --entity-name test
對topic 進行生產者消息測試
./kafka-producer-perf-test.sh --topic topic1 --throughput -1 --num-records 50000 --record-size 100 --producer-props bootstrap.servers=192.168.2.52:9092 acks=1
查看當前存在的消費者組
./kafka-consumer-groups.sh --bootstrap-server 192.168.2.52:9092 --list
查看當前消費者組的信息
./kafka-consumer-groups.sh --bootstrap-server 192.168.2.52:9092 --describe --group topic1group
重置當前消費者組的offset
./kafka-consumer-groups.sh --bootstrap-server 192.168.2.52:9092 --group topic1group --reset-off sets --all-topics --to-earliest --execute
kafka rebalance 觸發條件
消費者新增或者 移除
topic 分區的新增或減少
Kafka多線程消費兩種方式
1 每個線程維護一個kafkaConsumer
2 單個kafkaConsumer 實例 一個線程對應一個分區
兩種方式的優缺點
方法1 (每個線程維護專屬 Ka fkaConsumer )
實現簡單；速度較快，因爲無線程 間交互開銷：方便位移管理；易於 維護分區間的消息消費順序
Socket連接開銷大；consumer數受限於topic分區 數，擴展性差；broker端處理負載高（因爲發往 broker的請求數多）；rebalance可能性增大
方法2 (全局consumer多 worker 線程）
消息獲取與處理解耦：可獨立擴展 consumer數和woricer數，伸縮性 好
實現負載：難於維護分區內的消息順序；處理鏈路 變長，導致位移管理困難；worker線程異常可能導 致消費數據丟失
寫入消息的時候， 什麼情況下 導致HW 會和LEO 不同步呢
follwer請求速度追不上，leader的接受消息的速度， 可能原因 follwer 副本所在的broker 的網絡I/O開銷過大導致備份消息的速度滿於 leader處獲取的消息速度
進程卡住： follwer在一段時間內無法向leader 請求數據， 比如之前提到的頻繁gc 或者程序bug
LEO log end offset 日誌末端唯一， 代表kafka 當前分區存了多少條數據， 12代表存在11條數據
HW 高水印 代表 這個kafka consumer 可見的 ，當前能夠讀取的 最大offset ， 8 代表kafka消費者最多可以獲取到7條數據
HW 必須小於或者等於 LEO 代表所有消息，已提交，或者已備份
分區中的HW 爲 ISR 中所有副本LEO 的最小值
log compaction 日誌壓實(必須設置key) 確保kafka topic 每個分區中，具有相同的key的消息， 至少會保存最新的value 的消息
_consumer_offsets 就使用了日誌壓實的策略， 最會保存(groupId + topic + 分區號)最新的
broker 中的controller 的作用
更新集羣元數據信息
創建topic 刪除topic 分區重新分配
prefered leader 副本選舉
topic 分區擴展， broker 加入集羣 ， broker 崩潰
受控關閉， controller leader 選舉
生產者如何實現，消息的精確一次處理的語義呢， 從kafka 0.11.0.0後 kafka提供了冪等性， enable.idempotence=true
kafka調優方向
1 吞吐量
2 延時
3 持久性
4 可用性
OS 級別的錯誤
connection refused
too many open files
address in use connect
解決方案 ，基礎設置
1 禁止atime(最新的訪問時間) 更新 可以使用 mount -o noatime
2 可以通過禁止記日誌操作， 的方式來提高寫的速度，
commit=N_secs 該選項是 沒N秒 同步一次數據和元數據 ， 默認是5秒。 如果該值設的比較小，
可以減少崩潰發生時帶來的數據丟失， 但若設置的較大， 則會提升整體的吞吐量，以及降低延時， 生產環境 推薦用戶設置一個較大的值 1-2分鐘
swapiness 設置
2 設置swapiness linux 默認爲 60 s 一般建議設置爲 0 禁用來提升 內存的使用率，
這裏存在一個問題， 當內存用完後， linux OOM Killer 回去殺掉一個進程， 這樣可能會導致數據丟失，
坐着建議， 設置爲 1-10 之間，
jvm 設置
由於kafka 並沒有大量使用堆上內存 所以堆內存設置爲 6G，差不多可以滿足
-Xmx6g -Xms6g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize—128m -XX:+UseG1GC
-XX:MaxGCPauseMillis— 20 -XX: InitiatingHeapOccupancyPercent 35 -XX:
GlHeapRegionSize—16M -XX: MinMetaspaceFreeRatio—50 -XX:
MaxMetaspaceFreeRatio=85
設置 單個jvm 最大支持的線程數 vm.max_map_count 65530
調優吞吐量，
1producer 設置 batch.size 和linger.ms 通常情況下， 會提升producer 端的TPS
會增加了 消息的延時性，
2合理設置分區個數， 分區的增大到某個數值，後由於鎖競爭，和內存佔用過多 降低tps, 在實際中，
可以用兩倍數來逐步測試 ，直到性能拐點
3設置compression.type 對數據進行壓縮，降低I/O的方式來提高tps ,壓縮的話主要時針對batch的，
kafka 支持的壓縮格式又， gzip ,snappy,lz4 相比來說，lz4組合的性能最好，
4 設置acks 參數， 當參數爲1 代表leaderx寫入底層文件系統即返回，無須等待follower 響應，acks=0,
表示 producer 端不理會 broker 端的響應， 會提升tps 但是犧牲了消息的持久化，
5 當 producer 端 retries 參數設置的值，進行指定次數的重試，如果消息能夠忍受偶爾的數據丟失， 可以將
retries 設置爲0 ， tps 會有提升， 但是 消息發生失敗後， 就不會重試，
6 max.block.ms 當producer 端的緩衝區被填滿後， producer 將會進入阻塞狀態， 最大的阻塞時長，
一旦超過， producer 就會拋出 TimeoutException 因此，設置 buffer.memeory(默認32MB) 的值 能使
producer 使得阻塞的情況得到緩解，
consumer 端 fetch.min.bytes 的作用， 設置leader 副本沒錯返回 consumer 的最小字節數，
通過增加該參數 fafka 會爲每個fetch 請求的response 填入更多的數據， 減少網絡開銷， 提升TPS， 另一方面，
會導致延時的增加，
broker ，num。replica.fetchers 的值， 該值控制follower 從leader 副本中，獲取的最大線程數， 默認使1 表示
follower 只有一個線程去實時拉去leader 的最新消息， 當 acks=all 的 producer 而言， 主要的延時可能都耽誤在follower於leader 同步的過程，
增加 該值能夠縮短同步的實際間隔， 提升producer的tps
參數總結
broker 端
•適當增加num.replica.fetchers,但不要超過CPU核數。
•調優GC避免經常性的Full GC。
producer 端
•適當增加batch.size，比如100-512KB。
•適當增加linger.ms，比如10-00毫秒。
•設置 compression.type=lz4。
• acks=0 或 1
• retries=0
•若多線程共享producer或分區數很多，增加buffer.memory。 consumer 端
•採用多consumer實例。
•增加 fetch.min.bytes，比如 100000。
調優延時， 大體和調優吞吐量相反，
broker 端
• 適 度 增 加 num.replica.fetchers。
•避 免 創 建 過 多 topic分 區 。
producer 端
•設 置 linger.ms=0
• 設 置 compression.type=none
•設 置 acks=l或 0
consumer 端
設 置 fetch.min.bytes=l
調優持久性
broker 端 調優持久性， 有兩個重要的參數可以調節，log.flush.interval.ms 和 log.flush.interval.message，
默認情況下， log.flush.interval.ms=0, log.flush.interval.message=long.max_value，一般不需要調節
broker 端
•設置 unclean.leader.election.enable=false (0.1 丨 .0.0之前版本）《
•設置 auto.create.topics.enable=false。
•設置 replicat丨 on.factor = 3， min.insync.replicas = replication.factor - 1»
•設置 default.replication.factor = 3。
•設 置 brokcr.rack屬性分散分區數據到不同機架。
•設置丨 og.flush.interval.message 和 丨 og.flush.interval.ms 爲一個較小的值
producer 端
•設置 acks=all。
•設 罝 retries爲一個較大的值，比如 10-30。
•設置 max.in.flight.requesls.per.connection=l
•設置 enabIe.idempotence=true 啓用冪等性。
consumer 端
•設置 auto.commit.enable=false。
•消息消費成功後調用commitSync提交位移。
調優可用性
broker 端
避 免 創 建 過 多 分
設 置 unclean.leader.election.enable=true。
設 置 min.insync.replicas=l。
設 置 num.recovery.threads.per.data.dir=brolcer 端 參 數 log.dirs 中 設 置 的 目 錄 數 9
producer 端
•設 罝 acks=l，若一定要設置爲all，則遵循h面broker端的min.insyn.replicas配置。
consumer 端
•設 置 session.timeout.ms爲 較 低 的 值 ， 比 如 10000。
• (0.丨0.1.0及之後版本）設罝max.poll.imerva丨.ms爲比消息平均處理時間稍大的值。
• (0.10.1.0 之前版本）設置 max.poll.records 和 max.partition.fetch.bytes 減少 consumer 處理 消 息 的 總 時 長 ， 避 免 頻 繁 rebalance。
筆記來源於 胡夕的apache kafka實戰， 有興趣的可以去看看那本書，