1.kafka的主題會分爲多個區，生產者發送到kafka的同一主題的消息會分散到多個區，這其中有幾個策略
實現的原理也很簡單
List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
return Math.abs(key.hashCode()) % partitions.size();
簡單來說是通過hashcode對分區數量取餘。
最常用的是按照key來區分消息的策略，可以保證消息的順序性，kafka消息的特點是分區內有序，整體有序是保證不了的。
2 zookeeper在kafka中的作用
1、Broker註冊
Broker是分佈式部署並且相互之間相互獨立，但是需要有一個註冊系統能夠將整個集羣中的Broker管理起來，此時就使用到了Zookeeper。在Zookeeper上會有一個專門用來進行Broker服務器列表記錄的節點：
/brokers/ids
每個Broker在啓動時，都會到Zookeeper上進行註冊，即到/brokers/ids下創建屬於自己的節點，如/brokers/ids/[0…N]。
broker創建的是臨時節點，一旦宕機，broker的節點就會刪除
2、Topic註冊
在Kafka中，同一個Topic的消息會被分成多個分區並將其分佈在多個Broker上，這些分區信息及與Broker的對應關係也都是由Zookeeper在維護，由專門的節點來記錄，如：
/borkers/topics
Kafka中每個Topic都會以/brokers/topics/[topic]的形式被記錄，如/brokers/topics/login和/brokers/topics/search等。Broker服務器啓動後，會到對應Topic節點（/brokers/topics）上註冊自己的Broker ID並寫入針對該Topic的分區總數，如/brokers/topics/login/3->2，這個節點表示Broker ID爲3的一個Broker服務器，對於"login"這個Topic的消息，提供了2個分區進行消息存儲，同樣，這個分區節點也是臨時節點。
3.分區 與 消費者 的關係
消費組 (Consumer Group)：
consumer group 下有多個 Consumer（消費者）。
對於每個消費者組 (Consumer Group)，Kafka都會爲其分配一個全局唯一的Group ID，Group 內部的所有消費者共享該 ID。訂閱的topic下的每個分區只能分配給某個 group 下的一個consumer(當然該分區還可以被分配給其他group)。
同時，Kafka爲每個消費者分配一個Consumer ID，通常採用"Hostname:UUID"形式表示。
在Kafka中，規定了每個消息分區 只能被同組的一個消費者進行消費，因此，需要在 Zookeeper 上記錄 消息分區 與 Consumer 之間的關係，每個消費者一旦確定了對一個消息分區的消費權力，需要將其Consumer ID 寫入到 Zookeeper 對應消息分區的臨時節點上，例如：
/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]
其中，[broker_id-partition_id]就是一個 消息分區 的標識，節點內容就是該 消息分區 上 消費者的Consumer ID。
4.消費者註冊
消費者服務器在初始化啓動時加入消費者分組的步驟如下
註冊到消費者分組。每個消費者服務器啓動時，都會到Zookeeper的指定節點下創建一個屬於自己的消費者節點，例如/consumers/[group_id]/ids/[consumer_id]，完成節點創建後，消費者就會將自己訂閱的Topic信息寫入該臨時節點。
對 消費者分組 中的 消費者 的變化註冊監聽。每個 消費者 都需要關注所屬 消費者分組 中其他消費者服務器的變化情況，即對/consumers/[group_id]/ids節點註冊子節點變化的Watcher監聽，一旦發現消費者新增或減少，就觸發消費者的負載均衡。
對Broker服務器變化註冊監聽。消費者需要對/broker/ids/[0-N]中的節點進行監聽，如果發現Broker服務器列表發生變化，那麼就根據具體情況來決定是否需要進行消費者負載均衡。
進行消費者負載均衡。爲了讓同一個Topic下不同分區的消息儘量均衡地被多個 消費者 消費而進行 消費者 與 消息 分區分配的過程，通常，對於一個消費者分組，如果組內的消費者服務器發生變更或Broker服務器發生變更，會發出消費者負載均衡。
3.什麼時候觸發再均衡？
消費者宕機或者新增消費者，（擴展消費組內的消費者與分區關係是固定的，且一個分區只能綁定一個消費者）。
4.kafka 控制器選舉流程
搶佔式：kafka的控制器選舉很簡單，kafka的每一個broker都有一個ID唯一標識符，在集羣啓動的時候會把id註冊到zookeeper的/broker/ids/節點下作爲臨時子節點，節點的增加和刪除其他子節點都會得到通知，第一個啓動的broker會在zookeeper裏創建一個臨時節點/controll讓自己成爲控制器，其他後續節點啓動的也會創建，當發現已經存在這個臨時節點了那麼會拋出異常，會意識到此時節點已經存在，那麼後續的broker會在這個控制器節點創建watch事件，用來監聽控制器狀態，如果控制器的broker掛掉了，其他節點有機會成爲控制器
5.kafka 分區leader選舉過程
Controller在Zookeeper註冊Watch，一旦有Broker宕機（這是用宕機代表任何讓系統認爲其die的情景，包括但不限於機器斷電，網絡不可用，GC導致的Stop The World，進程crash等），其在Zookeeper對應的znode會自動被刪除，Zookeeper會fire Controller註冊的watch，Controller讀取最新的倖存的Broker
2.Controller決定set_p，該集合包含了宕機的所有Broker上的所有Partition
3.對set_p中的每一個Partition
3.1 從/brokers/topics/[topic]/partitions/[partition]/state讀取該Partition當前的ISR
3.2 決定該Partition的新Leader。如果當前ISR中有至少一個Replica還倖存，則選擇其中一個作爲新Leader，新的ISR則包含當前ISR中所有幸存的Replica（選舉算法的實現類似於微軟的PacificA）。否則選擇該Partition中任意一個倖存的Replica作爲新的Leader以及ISR（該場景下可能會有潛在的數據丟失）。如果該Partition的所有Replica都宕機了，則將新的Leader設置爲-1。
3.3 將新的Leader，ISR和新的leader_epoch及controller_epoch寫入/brokers/topics/[topic]/partitions/[partition]/state。
6.Kafka副本同步機制
Kafka中主題的每個Partition有一個預寫式日誌文件，每個Partition都由一系列有序的、不可變的消息組成，這些消息被連續的追加到Partition中，Partition中的每個消息都有一個連續的序列號叫做offset,
確定它在分區日誌中唯一的位置。
Kafka每個topic的partition有N個副本，其中N是topic的複製因子。Kafka通過多副本機制實現故障自動轉移，當Kafka集羣中一個Broker失效情況下仍然保證服務可用。在Kafka中發生複製時確保partition的預寫式日誌有序地寫到其他節點上。N個replicas中。其中一個replica爲leader，其他都爲follower，leader處理partition的所有讀寫請求，與此同時**，follower會被動定期地去複製leader上的數據。**
Kafka必須提供數據複製算法保證,如果leader發生故障或掛掉，一個新leader被選舉並接收客戶端的消息成功寫入。Kafka確保從同步副本列表中選舉一個副本爲leader,或者換句話說,follower追趕leader數據。**leader負責維護和跟蹤ISR中所有follower滯後狀態。**當生產者發送一條消息到Broker,leader寫入消息並複製到所有follower。消息提交之後才被成功複製到所有的同步副本。消息複製延遲受最慢的follower限制,重要的是快速檢測慢副本,如果follower”落後”太多或者失效,leader將會把它從replicas從ISR移除。
7producer是否直接將數據發送到broker的leader(主節點)？
producer直接將數據發送到broker的leader(主節點)，不需要在多個節點進行分發，爲了幫助producer做到這點，所有的Kafka節點都可以及時的告知:哪些節點是活動的，目標topic目標分區的leader在哪。這樣producer就可以直接將消息發送到目的地了
8Kafa consumer是否可以消費指定分區消息？
可以，參考代碼https://blog.csdn.net/zjx_z/article/details/83000794
9.Kafka高效文件存儲設計特點：
(1).Kafka把topic中一個parition大文件分成多個小文件段，通過多個小文件段，就容易定期清除或刪除已經消費完文件，減少磁盤佔用。
(2).通過索引信息可以快速定位message和確定response的最大大小。
(3).通過index元數據全部映射到memory，可以避免segment file的IO磁盤操作。
(4).通過索引文件稀疏存儲，可以大幅降低index文件元數據佔用空間大小。
10.Kafka 與傳統消息系統之間有三個關鍵區別
(1).Kafka 持久化日誌，這些日誌可以被重複讀取和無限期保留
(2).Kafka 是一個分佈式系統：它以集羣的方式運行，可以靈活伸縮，在內部通過複製數據提升容錯能力和高可用性
(3).Kafka 支持實時的流式處理
11.Kafka新建的分區會在哪個目錄下創建
在啓動 Kafka 集羣之前，我們需要配置好 log.dirs 參數，其值是 Kafka 數據的存放目錄，這個參數可以配置多個目錄，目錄之間使用逗號分隔，通常這些目錄是分佈在不同的磁盤上用於提高讀寫性能。
當然我們也可以配置 log.dir 參數，含義一樣。只需要設置其中一個即可。
如果 log.dirs 參數只配置了一個目錄，那麼分配到各個 Broker 上的分區肯定只能在這個目錄下創建文件夾用於存放數據。
但是如果 log.dirs 參數配置了多個目錄，那麼 Kafka 會在哪個文件夾中創建分區目錄呢？答案是：Kafka 會在含有分區目錄最少的文件夾中創建新的分區目錄，分區目錄名爲 Topic名+分區ID。注意，是分區文件夾總數最少的目錄，而不是磁盤使用量最少的目錄！也就是說，如果你給 log.dirs 參數新增了一個新的磁盤，新的分區目錄肯定是先在這個新的磁盤上創建直到這個新的磁盤目錄擁有的分區目錄不是最少爲止。
12.kafka生產者的ack機制
request.required.acks有三個值 0 1 -1
0:生產者不會等待broker的ack，這個延遲最低但是存儲的保證最弱當server掛掉的時候就會丟數據
1：服務端會等待ack值 leader副本確認接收到消息後發送ack但是如果leader掛掉後他不確保是否複製完成新leader也會導致數據丟失
-1：同樣在1的基礎上 服務端會等所有的follower的副本受到數據後纔會受到leader發出的ack，這樣數據不會丟失