Apach Kafka 是一款分布式流處理框架，用于實時構建流處理應用。它有一個核心 的功能廣為人知，即 作為企業級的消息引擎被廣泛使用

kafka設計

Kafka 將消息以 topic 為單位進行歸納 將向 Kafka topic 發布消息的程序成為 producers. 將預訂 topics 并消費消息的程序成為 consumer. Kafka 以集群的方式運行，可以由一個或多個服務組成，每個服務叫做一個 broker. producers 通過網絡將消息發送到 Kafka 集群，集群向消費者提供消息

為什么使用MQ？MQ的優點？

主要是：解耦、異步、削峰。

1、解耦：A 系統發送數據到 BCD 三個系統，通過接口調用發送。如果 E 系統也要這個數據呢？那如果 C 系統現在不需要了呢？A 系統負責人幾乎崩潰…A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統產 生一條比較關鍵的數據，很多系統都需要 A 系統將這個數據發送過來。如果使用 MQ，A 系統產生一條 數據，發送到 MQ 里面去，哪個系統需要數據自己去 MQ 里面消費。如果新系統需要數據，直接從 MQ 里消費即可；如果某個系統不需要這條數據了，就取消對 MQ 消息的消費即可。這樣下來，A 系統 壓根兒不需要去考慮要給誰發送數據，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗超 時等情況。 就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很復雜，維護起來很麻煩。但 是其實這個調用是不需要直接同步調用接口的，如果用 MQ 給它異步化解耦。

2、異步：A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、450ms、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms，接近 1s，用戶感覺搞個什么東西，慢死了慢死了。用戶通過瀏覽器發起請求。如果使用 MQ，那么 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到返回響應 給用戶，總時長是 3 + 5 = 8ms。

削峰：減少高峰時期對服務器壓力。

但是引入MQ以后要注意一下三個問題

3、系統可用性降低

本來系統運行好好的，現在你非要加入個消息隊列進去，那消息隊列掛了，你的系統不是呵呵了。

1、系統可用性會降低

?系統復雜度提高 加入了消息隊列，要多考慮很多方面的問題，比如：一致性問題、如何保證消息不被重復消費、如何保 證消息可靠性傳輸等。因此，需要考慮的東西更多，復雜性增大。

2、一致性問題

A 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那 里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。 所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額 外的技術方案和架構來規避掉，做好之后，你會發現，媽呀，系統復雜度提升了一個數量級，也許是復 雜了 10 倍。但是關鍵時刻，用，還是得用的。

什么是消費組？

1、定義：即消費者組是 Kafka 提供的可擴展且具有容錯性的消費者機制。 2、原理：在 Kafka 中，消費者組是一個由多個消費者實例 構成的組。多個實例共同訂閱若干個主題， 實現共同消費。同一個組下的每個實例都配置有 相同的組 ID，被分配不同的訂閱分區。當某個實例掛 掉的時候，其他實例會自動地承擔起 它負責消費的分區。

在 Kafka 中，ZooKeeper 的作用是什么?

Kafka 使用 ZooKeeper 存放集群元數據、成員管理、Controller 選舉，以及其他一些管理類任 務。之后，等 KIP-500 提案完成后，Kafka 將完全不再依賴 于 ZooKeeper。

“存放元數據”是指主題 分區的所有數據 都保存在 ZooKeeper 中，且以它保存的數據為權威，其他“人”都要與它 保持對齊。

“成員管理”是指 Broker 節點的注冊、注銷以及屬性變更，等 等。“Controller 選舉”是指選舉集群 Controller，而其他管 理類任務包括但不限于主題 刪除、參數配置等。

解釋下 Kafka 中位移(offset)的作用?

在 Kafka 中，每個 主題分區下的每條消息都被賦予了一個唯一的 ID 數值，用于標識它在分區中的位 置。這個 ID 數值，就被稱為位移，或者叫偏移量。一旦消息被寫入到分區日志，它的位移值將不能 被 修改。

__consumer_offsets 是做什么用的?

它的主要作用是負責注冊消費者以及保存位移值。可能你對保存位移值的功能很熟悉， 但其實該主題也 是保存消費者元數據的地方。千萬記得把這一點也回答上。另外，這里 的消費者泛指消費者組和獨立消 費者，而不僅僅是消費者組。 Kafka 的 GroupCoordinator 組件提供對該主題完整的管理功能，包括該主題的創建、 寫入、讀取和 Leader 維護等。

Kafka 為什么不支持讀寫分離?

場景不適用。讀寫分離適用于那種讀負載很大，而寫操作相對不頻繁的場景，可 Kafka 不屬于這 樣的場景。

同步機制。Kafka 采用 PULL 方式實現 Follower 的同步，因此，Follower 與 Leader 存 在不一致 性窗口。如果允許讀 Follower 副本，就勢必要處理消息滯后(Lagging)的問題。

Kafka 能手動刪除消息嗎?

其實，Kafka 不需要用戶手動刪除消息。它本身提供了留存策略，能夠自動刪除過期消息。

對于設置了 Key 且參數 cleanup.policy=compact 的主題而言，我們可以構造一條 的 消息發送給 Broker，依靠 Log Cleaner 組件提供的功能刪除掉該 Key 的消息。 對于普通主題而言，我們可以使用 kafka-delete-records 命令，或編寫程序調用 Admin.deleteRecords 方法來刪除消息。這兩種方法殊途同歸，底層都是調用 Admin 的 deleteRecords 方法，通過將分區 Log Start Offset 值抬高的方式間接刪除消息。

LEO、LSO、AR、ISR、HW 都表示什么含義?

LEO:Log End Offset。日志末端位移值或末端偏移量，表示日志下一條待插入消息的 位移值。舉 個例子，如果日志有 10 條消息，位移值從 0 開始，那么，第 10 條消息的位 移值就是 9。此時， LEO = 10。

LSO:Log Stable Offset。這是 Kafka 事務的概念。如果你沒有使用到事務，那么這個 值不存在(其 實也不是不存在，只是設置成一個無意義的值)。該值控制了事務型消費 者能夠看到的消息范圍。 它經常與 Log Start Offset，即日志起始位移值相混淆，因為 有些人將后者縮寫成 LSO，這是不對 的。在 Kafka 中，LSO 就是指代 Log Stable Offset。 AR:Assigned Replicas。AR 是主題被創建后，分區創建時被分配的副本集合，副本個 數由副本因 子決定。

ISR:In-Sync Replicas。Kafka 中特別重要的概念，指代的是 AR 中那些與 Leader 保 持同步的副本 集合。在 AR 中的副本可能不在 ISR 中，但 Leader 副本天然就包含在 ISR 中。關于 ISR，還有一 個常見的面試題目是如何判斷副本是否應該屬于 ISR。目前的判斷 依據是:Follower 副本的 LEO 落后 Leader LEO 的時間，是否超過了 Broker 端參數 replica.lag.time.max.ms 值。如果超過 了，副本就會被從 ISR 中移除。

HW:高水位值(High watermark)。這是控制消費者可讀取消息范圍的重要字段。一 個普通消費者 只能“看到”Leader 副本上介于 Log Start Offset 和 HW(不含)之間的 所有消息。水位以上的消息是 對消費者不可見的。關于 HW，問法有很多，我能想到的 最高級的問法，就是讓你完整地梳理下 Follower 副本拉取 Leader 副本、執行同步機制 的詳細步驟。

分區 Leader 選舉策略有幾種?

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

OfflinePartition Leader 選舉:每當有分區上線時，就需要執行 Leader 選舉。所謂的分區上線， 可能是創建了新分區，也可能是之前的下線分區重新上線。這是最常見的分區 Leader 選舉場景。 ReassignPartition Leader 選舉:當你手動運行 kafka-reassign-partitions 命令，或者是調用 Admin 的 alterPartitionReassignments 方法執行分區副本重分配時，可能觸發此類選舉。假設原 來的 AR 是[1，2，3]，Leader 是 1，當執行副本重分配后，副本集 合 AR 被設置成[4，5，6]，顯 然，Leader 必須要變更，此時會發生 Reassign Partition Leader 選舉。

PreferredReplicaPartition Leader 選舉:當你手動運行 kafka-preferred-replica- election 命 令，或自動觸發了 Preferred Leader 選舉時，該類策略被激活。所謂的 Preferred Leader，指的 是 AR 中的第一個副本。比如 AR 是[3，2，1]，那么， Preferred Leader 就是 3。 ControlledShutdownPartition Leader 選舉:當 Broker 正常關閉時，該 Broker 上 的所有 Leader 副本都會下線，因此，需要為受影響的分區執行相應的 Leader 選舉。

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 阻塞知道新消息到達 (當然也可以阻塞知道消息的數量達到某個特定的量這樣就可以批量Pull)

Kafka 存儲在硬盤上的消息格式是什么？

消息由一個固定長度的頭部和可變長度的字節數組組成。頭部包含了一個版本號和 CRC32 校驗碼。

kafka 的 ack 機制

acks=0：此模式下，生產者在發送消息后不會等待任何來自Broker的確認響應。這意味著一旦消息被發送出去，即使Broker沒有成功寫入磁盤，生產者也會繼續處理其他任務。這種模式適用于對延遲要求極高且可以容忍一定數據丟失的場景，但如果Broker發生故障，可能會導致消息丟失。

acks=1：在此模式下，生產者需要等待Leader副本成功將消息寫入本地日志文件后才返回確認。這種模式提供了一定的可靠性保證，因為至少有一個副本已經保存了消息。如果Leader副本在follower副本同步之前崩潰，消息可能會丟失。這種模式適用于大多數應用場景，能夠在可接受的延遲范圍內提供較好的消息可靠性。

acks=all或acks=-1：在此模式下，生產者需要等待所有在ISR（In-Sync Replicas）中的副本都成功寫入消息后才返回確認。這種模式提供了最高的消息可靠性保證，因為只有當所有副本都成功寫入消息時，生產者才認為消息已經成功發送。這種模式適用于對消息可靠性要求極高的場景，但相應的延遲也會增加。這確保了消息的可靠性，但會導致更長的延遲。

Kafka 的消費者如何消費數據

消費者每次消費數據的時候，消費者都會記錄消費的物理偏移量（offset）的位置 等到下次消費時，他會接著上次位置繼續消費.

partition 的數據如何保存到硬盤

topic 中的多個 partition 以文件夾的形式保存到 broker，每個分區序號從 0 遞增， 且消息有序 Partition 文件下有多個 segment（xxx.index，xxx.log） segment 文件里的 大小和配置文件大小一致可以根據要求修改 默認為 1g 如果大小大于 1g 時，會滾動一個新的 segment 并且以上一個 segment 最后一條消息的偏移量命名.

Kafka 新建的分區會在哪個目錄下創建

在啟動 Kafka 集群之前，我們需要配置好 log.dirs 參數，其值是 Kafka 數據的存放目錄， 這個參數可以配置多個目錄，目錄之間使用逗號分隔，通常這些目錄是分布在不同的磁盤 上用于提高讀寫性能。 當然我們也可以配置 log.dir 參數，含義一樣。只需要設置其中一個即可。 如果 log.dirs 參數只配置了一個目錄，那么分配到各個 Broker 上的分區肯定只能在這個 目錄下創建文件夾用于存放數據。

但是如果 log.dirs 參數配置了多個目錄，那么 Kafka 會在哪個文件夾中創建分區目錄呢？

答案是：Kafka 會在含有分區目錄最少的文件夾中創建新的分區目錄，分區目錄名為 Topic 名+分區 ID。注意，是分區文件夾總數最少的目錄，而不是磁盤使用量最少的目錄！也就 是說，如果你給 log.dirs 參數新增了一個新的磁盤，新的分區目錄肯定是先在這個新的磁 盤上創建直到這個新的磁盤目錄擁有的分區目錄不是最少為止。

Kafka 創建 Topic 時如何將分區放置到不同的 Broker中

副本因子不能大于 Broker 的個數；

第一個分區（編號為 0）的第一個副本放置位置是隨機從 brokerList 選擇的；

其他分區的第一個副本放置位置相對于第 0 個分區依次往后移。也就是如果我們有 5 個 Broker，5 個分區，假設第一個分區放在第四個 Broker 上，那么第二個分區將會放在第五 個 Broker 上；第三個分區將會放在第一個 Broker 上；第四個分區將會放在第二個 Broker 上，依次類推；

剩余的副本相對于第一個副本放置位置其實是由 nextReplicaShift 決定的，而這個數也是 隨機產生的.剩余的副本相對于第一個副本放置位置其實是由 nextReplicaShift 決定的，而這個數也是 隨機產生的

Kafka的數據有序

一個消費者組里它的內部是有序的，消費者組與消費者組之間是無序的。

Kafka數據傳輸的事務定義有哪三種？

數據傳輸的事務定義通常有以下三種級別：

（1）最多一次: 消息不會被重復發送，最多被傳輸一次，但也有可能一次不傳輸

（2）最少一次: 消息不會被漏發送，最少被傳輸一次，但也有可能被重復傳輸.

（3）精確的一次（Exactly once）: 不會漏傳輸也不會重復傳輸,每個消息都傳輸被一次而 且僅僅被傳輸一次，這是大家所期望的。

Kafka 判斷一個節點是否還活著有那兩個條件？

（1）節點必須可以維護和 ZooKeeper 的連接，Zookeeper 通過心跳機制檢查每個節點的連接。（2）如果節點是個 follower,他必須能及時的同步 leader 的寫操作，延時不能太久。

監控 Kafka 的框架都有哪些?

?1. Kafka Manager:應該算是最有名的專屬 Kafka 監控框架了，是獨立的監控系統。

?2. Kafka Monitor:LinkedIn 開源的免費框架，支持對集群進行系統測試，并實時監控測 試結果。? ?3. CruiseControl:也是 LinkedIn 公司開源的監控框架，用于實時監測資源使用率，以及 提供常用運 維操作等。無 UI 界面，只提供 REST API。

?4. JMX 監控:由于 Kafka 提供的監控指標都是基于 JMX 的，因此，市面上任何能夠集成 JMX 的框架 都可以使用，比如 Zabbix 和 Prometheus。

?5. 已有大數據平臺自己的監控體系:像 Cloudera 提供的 CDH 這類大數據平臺，天然就提 供 Kafka 監 控方案。

6. JMXTool:社區提供的命令行工具，能夠實時監控 JMX 指標。答上這一條，屬于絕對 的加分項，因 為知道的人很少，而且會給人一種你對 Kafka 工具非常熟悉的感覺。如果 你暫時不了解它的用 法，可以在命令行以無參數方式執行一下kafka-run-class.sh kafka.tools.JmxTool，學習下它的用 法。

通過Kafka的AdminClient的監控消費堆積情況.

如何設置 Kafka 能接收的最大消息的大小？

如 果 Producer 都不能向 Broker 端發送數據很大的消息，又何來消費一說呢? 因此，你需要同時設置 Broker 端參數和 Consumer 端參數。

Broker 端參數:message.max.bytes、max.message.bytes(主題級別)和 replica.fetch.max.bytes。 Consumer 端參數:fetch.message.max.bytes。 Broker 端的最后一個參數比較容易遺漏。我們必須調整 Follower 副本能夠接收的最大消 息的大小，否 則，副本同步就會失敗。

Kafka分區分配策略

在Kafka內部存在兩種默認的分區分配策略：Range和RoundRobin。
Range是默認策略。Range是對每個Topic而言的（即一個Topic一個Topic分），首先對同一個Topic里面的分區按序號進行排序，并對消費者按照字母順序進行排序。然后用Partition分區的個數除以消費者總線程數來決定每個消費者線程消費幾個分區的數據。如果除不盡，那前幾個消費者線程會多消費一個分區。