文章目錄
面向面試的博客，以問答式Q/A方式呈現。
Question1：簡單介紹一下你對 Kafka 的理解？
Answer1：
Kafka 是一種高吞吐量、高可用、基於發佈/訂閱的消息系統，最初由 LinkedIn 公司開發，使用Scala 語言編寫，目前是 Apache 的開源項目。
附：
高吞吐量：生產者發送數據的時候採用壓縮的方式來減少傳輸的數據量，減輕對網絡傳輸的壓力，採用批量發送的方式來減少 broker 存儲消息的 IO 操作次數，獲得更大的吞吐量。
高可用：同一個Partition的Replica副本儘量分散到不同的機器，保證高可用，不會因爲某一個broker故障影響整體。
圖中概念解釋：
Partitioned Data Pubilcation：分區數據發佈；Ordered Subscription：訂購；
TopicA-part0：表示TopicA-partition0，同理，TopicA-part1 表示TopicA-partition1，TopicA-part2 表示 TopicA-partition2，同一個partition只能有一個leader，由zookeeper負責partition中leader的選舉。
圖中內容解釋：
一個Topic可以包含多個partition，如圖所示，同時注意，同一個Partition的Replica副本儘量分散到不同的機器，保證高可用，圖中TopicA-part0在左邊和中間兩個broker上，圖中TopicA-part1在中間和右邊兩個broker上，圖中TopicA-part2在左邊和右邊兩個broker上，都不會在同一個broker上的，體現Kafka高可用。
- broker：Kafka 服務器，負責消息存儲和轉發。
- topic：消息類別，Kafka 按照 topic 來分類消息。
- partition：topic 的分區，一個 topic 可以包含多個 partition，topic 消息保存在各個partition 上。
- offset：消息在日誌中的位置，可以理解是消息在 partition 上的偏移量，也是代表該消息的唯一序號。
- Producer：消息生產者。
- Consumer：消息消費者。
- Consumer Group：消費者分組，每個 Consumer 必須屬於一個 group。
- Zookeeper：保存着集羣 broker、topic、partition 等 meta 數據；另外，還負責 broker 故障發現，partition leader 選舉，負載均衡等功能。
Question2：介紹一下 Kafka 數據存儲結構？
Answer2：
Kafka 數據存儲結構包括 partition數據文件、segment數據文件、數據索引文件，如下：
partition 數據文件（ offset，MessageSize，data ）
partition中的每條Message包含了以下三個屬性：
offset，MessageSize，data。
offset表示 Message 在這個 partition 中的偏移量，offset 不是該 Message 在 partition 數據文件中的實際存儲位置，而是邏輯上一個值，它唯一確定了partition中的一條Message，可以認爲offset是 partition 中 Message 的 id；
MessageSize 表示消息內容 data 的大小；
data 爲 Message 的具體內容。
segment數據文件（ 順序讀寫、分段命令、二分查找 ）
順序讀寫：partition 物理上由多個 segment 文件組成，每個 segment 大小相等，順序讀寫。
分段命令：每個 segment數據文件以該段中最小的 offset 命名，文件擴展名爲.log。
二分查找：這樣在查找指定 offset 的 Message 的時候，用二分查找就可以定位到該 Message 在哪個 segment 數據文件中。
索引文件（分段索引、 稀疏存儲 ）
分段索引：Kafka 爲每個分段後的數據文件建立了索引文件，文件名與數據文件的名字是一樣的，只是文件擴展名爲.index。
稀疏存儲：index 文件中並沒有爲數據文件中的每條 Message 建立索引，而是採用了稀疏存儲的方式，每隔一定字節的數據建立一條索引。這樣避免了索引文件佔用過多的空間，從而可以將索引文件保留在內存中。
索引文件和數據文件對應關係，如下圖所示：
左邊.index是索引文件，右邊.log是數據文件。
Question3：簡要闡述一下 Kafka 生產者設計？
Answer3：
Kafka 生產者設計架構，如下圖所示：
1、負載均衡（partition 會均衡分佈到不同 broker 上）
由於消息 topic 由多個 partition 組成，且 partition 會均衡分佈到不同 broker 上，因此，爲了有效利用 broker 集羣的性能，提高消息的吞吐量，producer 可以通過隨機或者 hash 等方式，將消息平均發送到多個 partition 上，以實現負載均衡。
2、批量發送
是提高消息吞吐量重要的方式，Producer 端可以在內存中合併多條消息後，以一次請求的方式發送了批量的消息給 broker，從而大大減少 broker 存儲消息的 IO 操作次數。但也一定程度上影響了消息的實時性，相當於以時延代價，換取更好的吞吐量。
3、壓縮（ GZIP 或 Snappy ）
Producer 端可以通過 GZIP 或 Snappy 格式對消息集合進行壓縮。Producer 端進行壓縮之後，在Consumer 端需進行解壓。壓縮的好處就是減少傳輸的數據量，減輕對網絡傳輸的壓力，在對大數據處理上，瓶頸往往體現在網絡上而不是 CPU（壓縮和解壓會耗掉部分 CPU 資源）。
Question4：簡要闡述一下 Kafka 消費者設計？
Answer4：
Kafka 消費者設計架構，如下圖所示：
同一 Consumer Group 中的多個 Consumer 實例，不同時消費同一個 partition，等效於隊列模式。partition 內消息是有序的，Consumer 通過 pull 方式消費消息。Kafka 不刪除已消費的消息。對於 partition，順序讀寫磁盤數據，以時間複雜度 O(1)方式提供消息持久化能力。
