文末尾有思維導圖，文字就是思維導圖的內容，如果不想看着，可以直接拉到末尾，查看思維導圖！ 注： 文章，是我學習了極客時間的《Kafka核心技術與實戰》專欄總結的學習筆記。
kafka基礎
核心術語
- Topic 主題
- Partition 分區，一個主題多個分區
- Record消息
- 副本Replica，爲消息提供冗餘
4.1 leader副本，對外提供服務
4.2 follower副本，僅作爲冗餘數據 - 消息位移Offset： 分區中每條消息的位置，單調遞增
Producer生產者
Consummer消費者
消費者位移：記錄消費者的進度，每個消費者都有自己的位移
消費者組：同一個消費組下，同一個Topic下，一個分區，有且僅有一個消費者消費
消費者組重平衡：一個消費組內有消費者掛了，其他消費者自動重分主題分區的過程。消費者端高可用手段。
Broker
集羣規劃注意事項：
| 因素 | 考量點 | 建議 |
|---|---|---|
| 操作系統 | 操作系統/IO模型 | 將kafka部署在Linux上，利用epoll模型 |
| 磁盤 | IO性能 | 普通機械磁盤，kafka副本+分區機制，可以不考慮搭建RAID |
| 磁盤容量 | 消息數，留存時間，平均消息大小，備份數估算磁盤容量 | 建議預留20%-30% |
| 帶寬 | 根據實現帶寬資源與業務SLA估算服務器的數量 | 千兆帶寬，建議每臺服務器按照700Mbps來計算，避免大流量下的丟包 |
4步集羣磁盤規劃
- 每日需要的磁盤淨容量（GB）= 每條消息平均大小（KB）每日消息數副本數 /1000/1000
- 考慮索引等數據每日磁盤容量（GB）=每日需要的磁盤容量* 1.1
- 不考慮壓縮的磁盤總大小（GB）=考慮索引等數據每日磁盤容量 * 留存時間
- 考慮壓縮的磁盤總大小（GB）=不考慮壓縮的磁盤總大小*0.75
參數配置
Broker重要參數
與存儲有關
log.dir和log.dirs
-
建議log.dirs按逗號分割,
-
目錄掛在在多個物理磁盤上。提升讀寫與故障恢復
與Zookeeper相關
zookeeper.connect 按逗號分割，記錄Zookeeper集羣的地址
與Broker連接相關
listener,advertised.liteners 格式爲：<協議名稱，主機名，端口號>
Topic管理相關
auto.create.topic.enable 建議fasle，是否自動創建主題
unclean.leader.election.enable 建議false，不允許非ISR副本，提升爲leader
auto.leader.rebalance.enable 是否自動換leader ，建議false
數據留存
broker級別
-
log.retention.{hours|minutes|ms} 一條消息保存多長時間
-
優先級ms>minutes>hours
-
log.retention.bytes： 保存消息的總容量大小，默認-1 不限制
-
message.max.bytes 單條消息最大字節，默認1000012 不足1MB，建議設置大些
Topic級別參數限制
-
retention.ms規定該Topic消息被保存的時長
-
retention.bytes 規定了要爲該Topic 預留多大的磁盤空間
-
max.message.bytes 決定kafka Broker能夠正常接受該Topic的最大消息大小
JVM參數
KAFKA_HEAP_OPS: 指定堆大小
推薦：KAFKA_HEAP_OPTS=--Xms6g --Xmx6g
KAFKA_JVM_PERFORMANCE_OPTS: 指定GC參數
首選G1，次選CMS
-server 按照server模式
-XX:+UseG1GC 使用G1回收器
-XX:MaxGCPauseMillis=20 表示每次GC最大的停頓毫秒數20ms
-XX:InitiatingHeapOccupancyPercent=35 當整個堆佔用超過某個百分比時，就會觸發併發GC週期
-XX:+ExplicitGCInvokesConcurrent 顯式的對 GC 的觸發也是併發執行
-Djava.awt.headless=true java.awt.headless是J2SE的一種模式，用於在缺失顯示屏、鼠標或者鍵盤時的系統配置。對於後端服務來講，很多都是需要將這個屬性設置爲true的
操作系統配置
文件描述符限制 ulimit -n 1000000
文件系統類型 XFS 的性能要強於 ext4
Swappiness 一個比較小的值。當使用swap時，可以觀察到Broker 性能急劇下降
Flush 落盤時間 默認是 5 秒 。kafka有分區+副本機制，可以適當調大
生產者
分區
每條消息，只會保存在某個分區中
分區是負載均衡以及高吞吐量的關鍵
Kafka 分區策略
默認分區策略：指定了 Key，使用消息鍵保序策略；沒指定 Key，使用輪詢策略。
其他常見分區策略：常見的，輪詢策略，隨機策略，按消息鍵保序策略，按地理位置分區策略
壓縮算法
Producer端壓縮、Broker端保存、Consumer端解壓
Broker端重新壓縮消息的2種情況
Broker端壓縮算法與Producer端壓縮算法不同
兼容老版本格式的轉換
壓縮算法
吞吐量方面：LZ4>Snappy>zstd,GZIP
壓縮比率： zstd>LZ4>GZIP>Snappy
啓動壓縮的條件
Producer運行機器本身CPU充足
帶寬資源有限
千兆網絡,CPU資源充足，建議開啓zstd
如何管理TCP連接
Kafka社區採用TCP作爲底層通訊協議
在創建KafkaProducer實例時創建TCP連接
創建時機
發送消息時
更新元數據後
誰負責連接
創建KafkaProducer實例時，生產者應用會在後臺創建一個Sender的線程，該線程會與Broker進行連接
會連接誰
Producer會對所有bootstrap.servers指定的Broker進行連接，生產環境中，建議指定3-4臺broker
關閉TCP
用戶主動關閉（kill -9）
kafka自動關閉(connections.max.idle.ms=-1 關閉，默認是9分鐘)
消費者
消費者組
提供的可擴展且具有容錯性的消費者機制
傳統模型的實現
所有實例都屬於同一個Group，就實現了消息隊列模型
所有實例分屬不同的Group，就實現了發佈訂閱模型
特性
Consumer Group下有一個或多個Consumer實例
Group ID標示唯一的一個Consumer Group
Consumer Group下所有實例訂閱主題的單個分區，只能分配給組內的某個Consumer實例消費。
位移
位移主題
__consumer_offsets保存Kafka消費者的位移
消息格式
消息Key
保存 3 部分內容：<Group ID，主題名，分區號 >
消息體
消息體1： 位移值+元數據
消息體2：保存Consumer Group的消息，用來註冊Consumer Group
消息體3：刪除Group過期位移，或刪除Group的消息。tombstone消息，delete mark，特點是消息體爲null
何時創建主題
第一個Consumer程序啓動時，Kafka會自動創建位移主題，默認分區50，副本數是3
Kafka使用Compact（壓實）策略
作用：刪除位移主題中的過期消息，避免該主題無限期膨脹
過程：Compact的過程就是掃描日誌的所有消息，剔除哪些過期的消息，把剩下的消息整理在一起。
什麼是過期消息：同一個Key兩條消息M1，M2，若M1的發送時間早於M2，那麼M1就是過期消息 。
位移提交
自動提交
enable.auto.commit設置爲true，默認爲true
手動提交
enable.auto.commit設置爲false
提交方式
同步位移提交：調用API，KafkaConsumer#commitSync().
異步提交位移：調用KafkaConsumer#commitAsync().
精細化位移管理
-
同步：commitSync(Map<TopicPartition，OffsetAndMetadata>)
-
異步：commitAsync(Map<TopicPartition,OffsetAndMetadata>);
CommitFailedException 異常處理
常見產生原因
消息處理時間超過了max.poll.interval.ms
如何預防
縮短單條消息處理時間
增加Consumer端允許下游消費一批消息的最大時長
減少下游系統，一次性消費的消息總數
下游系統使用多線程來加速消費
多線程消費者
多線程+多KafkaConsumer實例
優點：方便，速度快，分區內消費順序易維護
缺點：系統資源佔用多，受限於分區數，擴展性差，線程自己處理消息容易超時從而引發Rebalance
單KafkaConsumer+消息處理Worker線程池
優點：擴展性好，伸縮性好
缺點：實現難度高，難以維護分區內的消息消費順序，處理鏈路長，不易位移提交管理
關聯TCP連接
3個時機
發起FindCoordinator請求
連接協調者時
消費數據時
3種連接
確定協調者和獲取集羣元數據
連接協調者，令其執行組成員管理操作
執行實際的消息獲取。
監控消費進度
Kafka自帶的命令行工具，Kafka-consumer-groups腳本。
Kafka Java Consumer API編程
使用Kafka自帶的JMX監控指標
records-lag-max
records-lead-min 消費者最小消費消息的位移與分區當前第一條消息位移的差值。
控制器
職責
主題管理
分區重分配
Preferred領導選舉
集羣成員管理
數據服務
重度依賴於Zookeeper
Zookeeper 概述
高可用分佈式協調服務框架
類似於文件系統的樹形結構，以"/"開頭
znode分爲持久和臨時，臨時的znode會話結束會刪除
zonde發送變化，通過Watch通知功能
zookeeper，常用於集羣成員管理，分佈式鎖，領導者選舉
保存的重要數據
所有Broker信息
所有涉及運維任務的分區
選舉規則
第一個成功創建/controller節點的Broker會被指定爲控制器。
注意事項
集羣工作環境中，控制器只能有一個
JMX的指標，activeController，監控有幾個存活的控制器
0.11的改進 將多線程，改成了多線程加隊列
Kafka重要版本
0.11.0.0 提供冪等生產者，與事務API
1.0,2.0 kafka的streams的各種改進
