1、Kafka 都有哪些特點？
2、請簡述下你在哪些場景下會選擇 Kafka？
3、 Kafka 的設計架構你知道嗎？
簡單架構如下
詳細如下
Kafka 架構分為 以 下幾個部分
4、Kafka 分區的目的？
分區對於 Kafka 集群的好處是： 實現負載均衡。 分區對於消費者來說，可以提高並發度，提高效率。
5、你知道 Kafka 是如何做到消息的有序性？
kafka 中的每個 partition 中的消息在寫入時都是有序的，而且單獨一個 p artit ion 只能由一個消費者去消費，可以在裡面保證消息的順序性。但是分區之間的消息是不保證有序的。
6、Kafka 的高可靠性是怎麼實現的？
可以參見我這篇文章： Kafka 是如何保證數據可靠性和一致性
7、請談一談 Kafka 數據一致性原理
一致性就是說不論是老的 Leader 還是新選舉的 Leader，Consumer 都能讀到一樣的數據。
假設分區的副本為3，其中副本0是 Leader，副本1和副本2是 follower，並且在 ISR 列表裡面。雖然副本0已經寫入了 Message4，但是 Consumer 只能讀取到 Message2。 因為所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的消息才支持 Consumer 讀取，而 High Water Mark 取決於 ISR 列表裡面偏移量最小的分區，對應於上圖的副本2，這個很類似於木桶原理。
這樣做的原因是還沒有被足夠多副本複製的消息被認為是「不安全」的，如果 Leader 發生崩潰，另一個副本成為新 Leader，那麼這些消息很可能丟失了。 如果我們允許消費者讀取這些消息，可能就會破壞一致性。 試想，一個消費者從當前 Leader（副本0） 讀取並處理了 Message4，這個時候 Leader 掛掉了，選舉了副本1為新的 Leader，這時候另一個消費者再去從新的 Leader 讀取消息，發現這個消息其實並不存在，這就導致了數據不一致性問題。
當然，引入了 High Water Mark 機制，會導致 Broker 間的消息複製因為某些原因變慢，那麼消息到達消費者的時間也會隨之變長（因為我們會先等待消息複製完畢）。 延遲時間可以通過參數 replica.lag.time.max.ms 參數配置，它指定了副本在複製消息時可被允許的最大延遲時間。
8、ISR、OSR、AR 是什麼？
ISR：In-Sync Replicas 副本同步隊列
OSR： Out-of-Sync Replicas
AR：Assigned Replicas 所有副本
ISR是由leader維護，follower從leader同步數據有一些延遲（具體可以參見 圖文了解 Kafka 的副本複製機制 ），超過相應的閾值會把 follower 剔除出 ISR, 存入OSR（ Out-of-Sync Replicas ）列表，新加入的follower也會先存放在OSR中。 AR=ISR+OSR。
9、 LEO 、HW、LSO、LW等分別代表什麼
10、Kafka 在什麼情況下會出現消息丟失？
可以參見我這篇文章： Kafka 是如何保證數據可靠性和一致性
11、怎麼儘可能保證 Kafka 的可靠性
可以參見我這篇文章： Kafka 是如何保證數據可靠性和一致性
12、消費者和消費者組有什麼關係？
每個消費者從屬於消費組。具體關係如下：
13、Kafka 的每個分區只能被一個消費者線程，如何做到多個線程同時消費一個分區？
參見我這篇文章：Airbnb 是如何通過 balanced Kafka reader 來擴展 Spark streaming 實時流處理能力的
14、數據傳輸的事務有幾種？
數據傳輸的事務定義通常有以下三種級別：
（1）最多一次: 消息不會被重複發送，最多被傳輸一次，但也有可能一次不傳輸
（2）最少一次: 消息不會被漏發送，最少被傳輸一次，但也有可能被重複傳輸.
（3）精確的一次（Exactly once）: 不會漏傳輸也不會重複傳輸,每個消息都傳輸被
15、 Kafka 消費者是否可以消費指定分區消息？
Kafa consumer消費消息時，向broker發出fetch請求去消費特定分區的消息，consumer指定消息在日誌中的偏移量（offset），就可以消費從這個位置開始的消息，customer擁有了offset的控制權，可以向後回滾去重新消費之前的消息，這是很有意義的
16、Kafka消息是採用Pull模式，還是Push模式？
Kafka最初考慮的問題是，customer應該從brokes拉取消息還是brokers將消息推送到consumer，也就是pull還push。在這方面，Kafka遵循了一種大部分消息系統共同的傳統的設計：producer將消息推送到broker，consumer從broker拉取消息。
一些消息系統比如Scribe和Apache Flume採用了push模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由broker決定消息推送的速率，對於不同消費速率的consumer就不太好處理了。消息系統都致力於讓consumer以最大的速率最快速的消費消息，但不幸的是，push模式下，當broker推送的速率遠大於consumer消費的速率時，consumer恐怕就要崩潰了。最終Kafka還是選取了傳統的pull模式。
Pull模式的另外一個好處是consumer可以自主決定是否批量的從broker拉取數據。Push模式必須在不知道下游consumer消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之後批量推送。如果為了避免consumer崩潰而採用較低的推送速率，將可能導致一次只推送較少的消息而造成浪費。Pull模式下，consumer就可以根據自己的消費能力去決定這些策略。
Pull有個缺點是，如果broker沒有可供消費的消息，將導致consumer不斷在循環中輪詢，直到新消息到t達。為了避免這點，Kafka有個參數可以讓consumer阻塞知道新消息到達(當然也可以阻塞知道消息的數量達到某個特定的量這樣就可以批量發
17、Kafka 消息格式的演變清楚嗎？
Kafka 的消息格式經過了四次大變化，具體可以參見我這篇文章： Apache Kafka消息格式的演變(0.7.x~0.10.x) 。
18、Kafka 偏移量的演變清楚嗎？
參見我這篇文章 ： 圖解Apache Kafka消息偏移量的演變(0.7.x~0.10.x)
1 9、 Kafka 高效文件存儲設計特點
20、Kafka創建Topic時如何將分區放置到不同的Broker中
具體可以參見 Kafka創建Topic時如何將分區放置到不同的Broker中 。
21、Kafka新建的分區會在哪個目錄下創建
在啟動 Kafka 集群之前，我們需要配置好 log.dirs 參數，其值是 Kafka 數據的存放目錄，這個參數可以配置多個目錄，目錄之間使用逗號分隔，通常這些目錄是分布在不同的磁碟上用於提高讀寫性能。
當然我們也可以配置 log.dir 參數，含義一樣。只需要設置其中一個即可。
如果 log.dirs 參數只配置了一個目錄，那麼分配到各個 Broker 上的分區肯定只能在這個目錄下創建文件夾用於存放數據。
但是如果 log.dirs 參數配置了多個目錄，那麼 Kafka 會在哪個文件夾中創建分區目錄呢？答案是：Kafka 會在含有分區目錄最少的文件夾中創建新的分區目錄，分區目錄名為 Topic名+分區ID。注意，是分區文件夾總數最少的目錄，而不是磁碟使用量最少的目錄！也就是說，如果你給 log.dirs 參數新增了一個新的磁碟，新的分區目錄肯定是先在這個新的磁碟上創建直到這個新的磁碟目錄擁有的分區目錄不是最少為止。
具體可以參見我博客：https://www.iteblog.com/archives/2231.html
22、談一談 Kafka 的再均衡
在Kafka中，當有新消費者加入或者訂閱的topic數發生變化時，會觸發Rebalance(再均衡： 在同一個消費者組當中，分區的所有權從一個消費者轉移到另外一個消費者)機制，Rebalance顧名思義就是重新均衡消費者消費。 Rebalance的過程如下：
第一步： 所有成員都向coordinator發送請求，請求入組。 一旦所有成員都發送了請求，coordinator會從中選擇一個consumer擔任leader的角色，並把組成員信息以及訂閱信息發給leader。
第二步： leader開始分配消費方案，指明具體哪個consumer負責消費哪些topic的哪些partition。 一旦完成分配，leader會將這個方案發給coordinator。 coordinator接收到分配方案之後會把方案發給各個consumer，這樣組內的所有成員就都知道自己應該消費哪些分區了。
所以對於Rebalance來說，Coordinator起著至關重要的作用
23、談談 Kafka 分區分配 策略
參見我這篇文章 Kafka分區分配策略(Partition Assignment Strategy)
24、Kafka Producer 是如何動態感知主題分區數變化的？
參見我這篇文章：Kafka Producer是如何動態感知Topic分區數變化
25、 Kafka 是如何實現高吞吐率的？
Kafka是分布式消息系統，需要處理海量的消息，Kafka的設計是把所有的消息都寫入速度低容量大的硬碟，以此來換取更強的存儲能力，但實際上，使用硬碟並沒有帶來過多的性能損失 。 kafka主要使用了以下幾個方式實現了超高的吞吐率 ：
具體參見：Kafka是如何實現高吞吐率的
26、Kafka 監控都有哪些？
參見我另外幾篇文章：Apache Kafka監控之KafkaOffsetMonitor
雅虎開源的Kafka集群管理器(Kafka Manager)
Apache Kafka監控之Kafka Web Console
還有 JMX
27、如何為Kafka集群選擇合適的Topics/Partitions數量
參見我另外幾篇文章：如何為Kafka集群選擇合適的Topics/Partitions數量
28、談談你對 Kafka 事務的了解？
參見這篇文章：http://www.jasongj.com/kafka/transaction/
29、談談你對 Kafka 冪等的了解？
參見這篇文章：https://www.jianshu.com/p/b1599f46229b
30、Kafka 缺點？
31、Kafka 新舊消費者的區別
舊的 Kafka 消費者 API 主要包括： SimpleConsumer（簡單消費者） 和 ZookeeperConsumerConnectir（高級消費者）。 SimpleConsumer 名字看起來是簡單消費者，但是其實用起來很不簡單，可以使用它從特定的分區和偏移量開始讀取消息。 高級消費者和現在新的消費者有點像，有消費者群組，有分區再均衡，不過它使用 ZK 來管理消費者群組，並不具備偏移量和再均衡的可操控性。
現在的消費者同時支持以上兩種行為，所以為啥還用舊消費者 API 呢？
3 2、Kafka 分區數可以增加或減少嗎？為什麼？
我們可以使用 bin/kafka-topics.sh 命令對 Kafka 增加 Kafka 的分區數據 ，但是 Kafka 不支持減少 分區數。
Kafka 分區數據 不支持減少 是由很多原因的，比如減少的分區 其數據放到哪裡去？ 是刪除，還是保留？ 刪除的話， 那麼這些沒消費的消息 不就丟了。 如果保留這些消息 如何放到 其他分區裡面？ 追加到 其他分區 後面的話 那麼就破壞了 Kafka 單個分區的有序性。 如果 要保證刪除分區數據插入到其他分區 保證有序性，那麼實現起來邏輯就會非常複雜。