概要

kafka的傳統定義：kafka是一個分布式的基于發布\訂閱模式的消息隊列，主要用于大數據實時處理領域。
kafka的最新概念：kafka是一個開源的分布式事件流平臺，（80%的公司都在用），用于高性能數據管道、流分析、數據集成和關鍵任務應用。
在大數據場景主要采用Kafka作為消息隊列。在JavaEE開發中主要采用ActiveMQ、RabbitMQ、RocketMQ。

應用場景

傳統的消息隊列的主要應用場景包括：緩存/消峰、解耦和異步通信。

1. 緩沖\消峰：這時候的消息隊列相當于有一個緩沖區，將請求先寫入消息隊列，消息隊列內的請求遵循先進先出原則，從而不會因為高并發而導致系統崩潰，畢竟服務器的資源有限（場景：以前雙十一，沒有消息隊列，在高并發時可能會系統崩潰，現在有了消息隊列，會直接返回，你下單成功或者其他，然后服務器慢慢從消息隊列中處理這些任務）
2. 解耦：耦合性就是兩個模塊之間的依賴性，越高呢，維護成本越高，比如說就Producer和Consumer直接連接時，一個發生變化，另一個要做出比較大的調整，有了消息對接在中間，就能降低之間耦合性，也就是解耦
3. 異步通訊：允許用戶將消息寫入消息隊列，并不立即去處理
   

消息隊列兩種模式

kafka的基礎架構

（1）Producer：生產者（可能是flume、MySQL等），其實就是向kafka發送數據的
（2）Consumer：消費者（可能是MySQL、Hadoop、spark、flink），就是向kafka取數據的
（3）Consumer Group：就是消費者組，由一個或者多個consumer組成，在kafka中，消費者都是有組的，即使是在consumer創建時沒有沒有設置組，但是kafka會默認一個有一個組，是組直接從kafka中的leader中拉取數據，消費者組內每個消費者負責消費不同分區的數據，一個分區只能由一個組內消費者消費；消費者組之間互不影響。所有的消費者都屬于某個消費者組，即消費者組是邏輯上的一個訂閱者
（4）Broker：kafka代理，即kafka代理服務器，一個集群由多個broker組成，一個broker可以容納多個topic
（5）topic：主題，可以理解成隊列，但是和點對點隊列不同的是，不同的消費者組都可以從topic拉去相同的消息

分區

因為不同的分區分布在不同的節點上，所以便于合理使用資源，實現負載均衡，
并且在不同節點上可以提高并行度。

Kafka將消息以topic的方式進行組織和管理，一個topic包含多個分區（partition），每個分區可以理解為一個獨立的日志文件。

消息生產者可以選擇將消息發送到指定分區或讓Kafka根據一定的負載均衡策略自動選擇分區。同時，消息生產者也可以指定消息的key，這樣Kafka會根據key的hash值將消息發送到對應的分區中，確保同一key的消息被發送到同一分區中，保證消息的有序性

常見問題

1、kafka的消費者是pull(拉)還是push(推)模式，這種模式有什么好處？
Kafka 遵循了一種大部分消息系統共同的傳統的設計：producer 將消息推送到 broker，consumer 從broker 拉取消息。
優點：pull模式消費者自主決定是否批量從broker拉取數據，而push模式在無法知道消費者消費能力情況下，不易控制推送速度，太快可能造成消費者崩潰，太慢又可能造成浪費。
缺點：如果 broker 沒有可供消費的消息，將導致 consumer 不斷在循環中輪詢，直到新消息到到達。為了避免這點，Kafka 有個參數可以讓 consumer阻塞知道新消息到達(當然也可以阻塞知道消息的數量達到某個特定的量這樣就可以批量發送)。

2、kafka維護消息狀態的跟蹤方法
Kafka中的Topic 被分成了若干分區，每個分區在同一時間只被一個 consumer 消費。然后再通過offset進行消息位置標記，通過位置偏移來跟蹤消費狀態。相比其他一些消息隊列使用“一個消息被分發到consumer 后 broker 就馬上進行標記或者等待 customer 的通知后進行標記”的優點是，避免了通信消息發送后，可能出現的程序奔潰而出現消息丟失或者重復消費的情況。同時也無需維護消息的狀態，不用加鎖，提高了吞吐量。

3、zookeeper對于kafka的作用是什么?
Zookeeper 主要用于在集群中不同節點之間進行通信，在 Kafka 中，它被用于提交偏移量，因此如果節點在任何情況下都失敗了，它都可以從之前提交的偏移量中獲取，除此之外，它還執行其他活動，如: leader 檢測、分布式同步、配置管理、識別新節點何時離開或連接、集群、節點實時狀態等等。

4、kafka判斷一個節點還活著的有那兩個條件？
（1）節點必須維護和 ZooKeeper 的連接，Zookeeper 通過心跳機制檢查每個節點的連接
（2）如果節點是個 follower,他必須能及時的同步 leader 的寫操作，延時不能太久

5、講一講 kafka 的 ack 的三種機制
Kafka 生產者的 ACK 機制指的是生產者在發送消息后，對消息副本的確認機制。ACK 機制可以幫助生產者確保消息被成功寫入 Kafka 集群中的多個副本，并在需要時獲取確認信息。

request.required.acks 有三個值 0 1 -1(all)，具體如下：
0：生產者不會等待 broker 的 ack，這個延遲最低但是存儲的保證最弱當 server 掛掉的時候就會丟數據。
1：服務端會等待 ack 值 leader 副本確認接收到消息后發送 ack 但是如果 leader掛掉后他不確保是否復制完成新 leader 也會導致數據丟失。
-1(all)：服務端會等所有的 follower 的副本受到數據后才會受到 leader 發出的ack，這樣數據不會丟失。

6、kafka 分布式（不是單機）的情況下，如何保證消息的順序消費?
Kafka 中發送 1 條消息的時候，可以指定(topic, partition, key) 3 個參數，partiton 和 key 是可選的。
Kafka 分布式的單位是 partition，同一個 partition 用一個 write ahead log 組織，所以可以保證FIFO 的順序。不同 partition 之間不能保證順序。因此你可以指定 partition，將相應的消息發往同 1個 partition，并且在消費端，Kafka 保證1 個 partition 只能被1 個 consumer 消費，就可以實現這些消息的順序消費。
另外，你也可以指定 key（比如 order id），具有同 1 個 key 的所有消息，會發往同 1 個partition，那這樣也實現了消息的順序消息。

7、kafka 如何不消費重復數據？比如扣款，我們不能重復的扣。
這個問題換種問法，就是kafka如何保證消息的冪等性。對于消息隊列來說，出現重復消息的概率還是挺大的，不能完全依賴消息隊列，而是應該在業務層進行數據的一致性冪等校驗。
比如你處理的數據要寫庫（mysql，redis等），你先根據主鍵查一下，如果這數據都有了，你就別插入了，進行一些消息登記或者update等其他操作。另外，數據庫層面也可以設置唯一健，確保數據不要重復插入等 。一般這里要求生產者在發送消息的時候，攜帶全局的唯一id。
8、partition的數據文件（offffset，MessageSize，data）
partition中的每條Message包含了以下三個屬性： offset，MessageSize，data，其中offset表示Message在這個partition中的偏移量，offset不是該Message在partition數據文件中的實際存儲位置，而是邏輯上一個值，它唯一確定了partition中的一條Message，可以認為offset是partition中Message的 id； MessageSize表示消息內容data的大小；data為Message的具體內容。

9、kafka如何實現數據的高效讀取？（順序讀寫、分段命令、二分查找）
Kafka為每個分段后的數據文件建立了索引文件，文件名與數據文件的名字是一樣的，只是文件擴展名為index。 index文件中并沒有為數據文件中的每條Message建立索引，而是采用了稀疏存儲的方式，每隔一定字節的數據建立一條索引。這樣避免了索引文件占用過多的空間，從而可以將索引文件保留在內存中

10、Kafka的那些設計讓它有如此高的性能?
1.kafka是分布式的消息隊列
2.對log文件進行了segment,并對segment創建了索引
3.(對于單節點)使用了順序讀寫,速度能夠達到600M/s
4.引用了zero拷貝,在os系統就完成了讀寫操做

11、Kafka為什么不支持讀寫分離？
1、 這其實是分布式場景下的通用問題，因為我們知道CAP理論下，我們只能保證C（一致性）和A（可用性）取其一，如果支持讀寫分離，那其實對于一致性的要求可能就會有一定折扣，因為通常的場景下，副本之間都是通過同步來實現副本數據一致的，那同步過程中肯定會有時間的消耗，如果支持了讀寫分離，就意味著可能的數據不一致，或數據滯后。

2、 Leader/Follower模型并沒有規定Follower副本不可以對外提供讀服務。很多框架都是允許這么做的，只是 Kafka最初為了避免不一致性的問題，而采用了讓Leader統一提供服務的方式。

3、 不過，自Kafka 2.4之后，Kafka提供了有限度的讀寫分離，也就是說，Follower副本能夠對外提供讀服務。

12、分區Leader選舉策略有幾種？
分區的Leader副本選舉對用戶是完全透明的，它是由Controller獨立完成的。你需要回答的是，在哪些場景下，需要執行分區Leader選舉。每一種場景對應于一種選舉策略。

1、 OfflinePartition Leader選舉：每當有分區上線時，就需要執行Leader選舉。所謂的分區上線，可能是創建了新分區，也可能是之前的下線分區重新上線。這是最常見的分區Leader選舉場景。

2、 ReassignPartition Leader選舉：當你手動運行Kafka-reassign-partitions命令，或者是調用Admin的alterPartitionReassignments方法執行分區副本重分配時，可能觸發此類選舉。假設原來的AR是[1，2，3]，Leader是1，當執行副本重分配后，副本集合AR被設置成[4，5，6]，顯然，Leader必須要變更，此時會發生Reassign Partition Leader選舉。

3、 PreferredReplicaPartition Leader選舉：當你手動運行Kafka-preferred-replica-election命令，或自動觸發了Preferred Leader選舉時，該類策略被激活。所謂的Preferred Leader，指的是AR中的第一個副本。比如AR是[3，2，1]，那么，Preferred Leader就是3。

4、 ControlledShutdownPartition Leader選舉：當Broker正常關閉時，該Broker上的所有Leader副本都會下線，因此，需要為受影響的分區執行相應的Leader選舉。

這4類選舉策略的大致思想是類似的，即從AR中挑選首個在ISR中的副本，作為新Leader。

13、請簡述下你在哪些場景下會選擇 Kafka？
?日志收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一接口服務的方式開放給各種consumer，例如hadoop、HBase、Solr等。
?消息系統：解耦和生產者和消費者、緩存消息等。
?用戶活動跟蹤：Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發布到kafka的topic中，然后訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到hadoop、數據倉庫中做離線分析和挖掘。
?運營指標：Kafka也經常用來記錄運營監控數據。包括收集各種分布式應用的數據，生產各種操作的集中反饋，比如報警和報告。
?流式處理：比如spark streaming和 Flink

14、請談一談 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 參數配置，它指定了副本在復制消息時可被允許的最大延遲時間。

小結

每日一小結，進步一大節。
以上圖片均自于網絡，如有侵權，請聯系刪除。