本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~
Github地址：https://github.com/Tyson0314/Java-learning
Kafka 都有哪些特點？
- 高吞吐量、低延遲：kafka每秒可以處理幾十萬條訊息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作，
- 可擴展性：kafka集群支持熱擴展
- 持久性、可靠性：訊息被持久化到本地磁盤，并且支持資料備份防止資料丟失
- 容錯性：允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）
- 高并發：支持數千個客戶端同時讀寫
請簡述下你在哪些場景下會選擇 Kafka？
- 日志收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一介面服務的方式開放給各種consumer，例如hadoop、HBase、Solr等，
- 訊息系統：解耦和生產者和消費者、快取訊息等，
- 用戶活動跟蹤：Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動資訊被各個服務器發布到kafka的topic中，然后訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到hadoop、資料倉庫中做離線分析和挖掘，
- 運營指標：Kafka也經常用來記錄運營監控資料，包括收集各種分布式應用的資料，生產各種操作的集中反饋，比如報警和報告，
- 流式處理：比如spark streaming和 Flink
Kafka 的設計架構你知道嗎？
Kafka 架構分為以下幾個部分：
- Producer ：訊息生產者，就是向 kafka broker 發訊息的客戶端，
- Consumer ：訊息消費者，向 kafka broker 取訊息的客戶端，
- Topic ：可以理解為一個佇列，一個 Topic 又分為一個或多個磁區，
- Consumer Group：這是 kafka 用來實作一個 topic 訊息的廣播（發給所有的 consumer）和單播（發給任意一個 consumer）的手段，一個 topic 可以有多個 Consumer Group，
- Broker ：一臺 kafka 服務器就是一個 broker，一個集群由多個 broker 組成，一個 broker 可以容納多個 topic，
- Partition：為了實作擴展性，一個非常大的 topic 可以分布到多個 broker上，每個 partition 是一個有序的佇列，partition 中的每條訊息都會被分配一個有序的id（offset），將訊息發給 consumer，kafka 只保證按一個 partition 中的訊息的順序，不保證一個 topic 的整體（多個 partition 間）的順序，
- Offset：kafka 的存盤檔案都是按照 offset.kafka 來命名，用 offset 做名字的好處是方便查找，例如你想找位于 2049 的位置，只要找到 2048.kafka 的檔案即可，當然 the first offset 就是 00000000000.kafka，
Kafka 磁區的目的？
磁區對于 Kafka 集群的好處是：實作負載均衡，磁區對于消費者來說，可以提高并發度，提高效率，
你知道 Kafka 是如何做到訊息的有序性？
kafka 中的每個 partition 中的訊息在寫入時都是有序的，而且單獨一個 partition 只能由一個消費者去消費，可以在里面保證訊息的順序性，但是磁區之間的訊息是不保證有序的，
Kafka Producer 的執行程序？
1，Producer生產訊息 --> 2，從Zookeeper找到Partition的Leader --> 3，推送訊息 --> 4，通過ISR串列通知給Follower --> 5， Follower從Leader拉取訊息，并發送ack --> 6，Leader收到所有副本的ack，更新Offset，并向Producer發送ack，表示訊息寫入成功，
講一下你使用 Kafka Consumer 消費訊息時的執行緒模型，為何如此設計？
Thread-Per-Consumer Model，這種多執行緒模型是利用Kafka的topic分多個partition的機制來實作并行：每個執行緒都有自己的consumer實體，負責消費若干個partition，各個執行緒之間是完全獨立的，不涉及任何執行緒同步和通信，所以實作起來非常簡單，
請談一談 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 引數配置，它指定了副本在復制訊息時可被允許的最大延遲時間，
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，
LEO、HW、LSO、LW等分別代表什么
LEO：是 LogEndOffset 的簡稱，代表當前日志檔案中下一條
HW：水位或水印（watermark）一詞，也可稱為高水位(high watermark)，通常被用在流式處理領域（比如Apache Flink、Apache Spark等），以表征元素或事件在基于時間層面上的進度，在Kafka中，水位的概念反而與時間無關，而是與位置資訊相關，嚴格來說，它表示的就是位置資訊，即位移（offset），取 partition 對應的 ISR中 最小的 LEO 作為 HW，consumer 最多只能消費到 HW 所在的位置上一條資訊，
LSO：是 LastStableOffset 的簡稱，對未完成的事務而言，LSO 的值等于事務中第一條訊息的位置(firstUnstableOffset)，對已完成的事務而言，它的值同 HW 相同
LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值，
資料傳輸的事務有幾種？
資料傳輸的事務定義通常有以下三種級別：
（1）最多一次: 訊息不會被重復發送，最多被傳輸一次，但也有可能一次不傳輸
（2）最少一次: 訊息不會被漏發送，最少被傳輸一次，但也有可能被重復傳輸.
（3）精確的一次（Exactly once）: 不會漏傳輸也不會重復傳輸,每個訊息都傳輸被
Kafka 消費者是否可以消費指定磁區訊息？
Kafa consumer消費訊息時，向broker發出fetch請求去消費特定磁區的訊息，consumer指定訊息在日志中的偏移量（offset），就可以消費從這個位置開始的訊息，customer擁有了offset的控制權，可以向后回滾去重新消費之前的訊息，這是很有意義的，
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阻塞知道新訊息到達(當然也可以阻塞知道訊息的數量達到某個特定的量這樣就可以批量發
Kafka 高效檔案存盤設計特點
Kafka把topic中一個parition大檔案分成多個小檔案段，通過多個小檔案段，就容易定期清除或洗掉已經消費完檔案，減少磁盤占用，
通過索引資訊可以快速定位message和確定response的最大大小，
通過index元資料全部映射到memory，可以避免segment file的IO磁盤操作，
通過索引檔案稀疏存盤，可以大幅降低index檔案元資料占用空間大小
Kafka創建Topic時如何將磁區放置到不同的Broker中
副本因子不能大于 Broker 的個數；
第一個磁區（編號為0）的第一個副本放置位置是隨機從 brokerList 選擇的；
其他磁區的第一個副本放置位置相對于第0個磁區依次往后移，也就是如果我們有5個 Broker，5個磁區，假設第一個磁區放在第四個 Broker 上，那么第二個磁區將會放在第五個 Broker 上；第三個磁區將會放在第一個 Broker 上；第四個磁區將會放在第二個 Broker 上，依次類推；
剩余的副本相對于第一個副本放置位置其實是由 nextReplicaShift 決定的，而這個數也是隨機產生的
談一談 Kafka 的再均衡
在Kafka中，當有新消費者加入或者訂閱的topic數發生變化時，會觸發Rebalance(再均衡：在同一個消費者組當中，磁區的所有權從一個消費者轉移到另外一個消費者)機制，Rebalance顧名思義就是重新均衡消費者消費，Rebalance的程序如下：
第一步：所有成員都向coordinator發送請求，請求入組，一旦所有成員都發送了請求，coordinator會從中選擇一個consumer擔任leader的角色，并把組成員資訊以及訂閱資訊發給leader，
第二步：leader開始分配消費方案，指明具體哪個consumer負責消費哪些topic的哪些partition，一旦完成分配，leader會將這個方案發給coordinator，coordinator接收到分配方案之后會把方案發給各個consumer，這樣組內的所有成員就都知道自己應該消費哪些磁區了，
所以對于Rebalance來說，Coordinator起著至關重要的作用
Kafka 是如何實作高吞吐率的？
Kafka是分布式訊息系統，需要處理海量的訊息，Kafka的設計是把所有的訊息都寫入速度低容量大的硬碟，以此來換取更強的存盤能力，但實際上，使用硬碟并沒有帶來過多的性能損失，kafka主要使用了以下幾個方式實作了超高的吞吐率：
- 順序讀寫；
- 零拷貝
- 檔案分段
- 批量發送
- 資料壓縮，
Kafka 缺點？
- 由于是批量發送，資料并非真正的實時；
- 對于mqtt協議不支持；
- 不支持物聯網傳感資料直接接入；
- 僅支持統一磁區內訊息有序，無法實作全域訊息有序；
- 監控不完善，需要安裝插件；
- 依賴zookeeper進行元資料管理；
Kafka 新舊消費者的區別
舊的 Kafka 消費者 API 主要包括：SimpleConsumer（簡單消費者） 和 ZookeeperConsumerConnectir（高級消費者），SimpleConsumer 名字看起來是簡單消費者，但是其實用起來很不簡單，可以使用它從特定的磁區和偏移量開始讀取訊息，高級消費者和現在新的消費者有點像，有消費者群組，有磁區再均衡，不過它使用 ZK 來管理消費者群組，并不具備偏移量和再均衡的可操控性，
現在的消費者同時支持以上兩種行為，所以為啥還用舊消費者 API 呢？
Kafka 磁區數可以增加或減少嗎？為什么？
我們可以使用 bin/kafka-topics.sh 命令對 Kafka 增加 Kafka 的磁區資料，但是 Kafka 不支持減少磁區數，
Kafka 磁區資料不支持減少是由很多原因的，比如減少的磁區其資料放到哪里去？是洗掉，還是保留？洗掉的話，那么這些沒消費的訊息不就丟了，如果保留這些訊息如何放到其他磁區里面？追加到其他磁區后面的話那么就破壞了 Kafka 單個磁區的有序性，如果要保證洗掉磁區資料插入到其他磁區保證有序性，那么實作起來邏輯就會非常復雜，
最后給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~
Github地址：https://github.com/Tyson0314/java-books
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/546275.html
標籤：Java