介紹下 Kafka，Kafka 的作用、組件、適用場(chǎng)景分別是什么？作為消息隊(duì)列，它可解決什么樣的問(wèn)題？

Kafka 是一個(gè) 分布式流處理平臺(tái)，最初由 LinkedIn 開(kāi)發(fā)，后成為 Apache 頂級(jí)項(xiàng)目。它以 高吞吐量、低延遲、可擴(kuò)展性 為核心優(yōu)勢(shì)，專(zhuān)為處理實(shí)時(shí)數(shù)據(jù)流而設(shè)計(jì)。

核心作用

1. 消息系統(tǒng)：作為 消息中間件，支持生產(chǎn)者和消費(fèi)者之間的異步通信。
2. 數(shù)據(jù)管道：用于構(gòu)建 實(shí)時(shí)數(shù)據(jù)集成管道，例如將數(shù)據(jù)從數(shù)據(jù)庫(kù)同步到數(shù)據(jù)倉(cāng)庫(kù)。
3. 流處理：結(jié)合流處理框架（如 Kafka Streams、Flink），實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理和分析。

核心組件

適用場(chǎng)景

• 日志收集：集中收集分布式系統(tǒng)的日志數(shù)據(jù)（如 ELK 架構(gòu)）。
• 實(shí)時(shí)指標(biāo)：監(jiān)控系統(tǒng)實(shí)時(shí)生成指標(biāo)（如用戶(hù)行為跟蹤）。
• 事件溯源：記錄系統(tǒng)狀態(tài)變更事件（如電商訂單狀態(tài)流轉(zhuǎn)）。
• 流處理：實(shí)時(shí)處理點(diǎn)擊流、傳感器數(shù)據(jù)等。

解決的問(wèn)題

• 系統(tǒng)解耦：生產(chǎn)者和消費(fèi)者無(wú)需直接通信，降低依賴(lài)性。
• 削峰填谷：緩沖突發(fā)流量，避免下游系統(tǒng)過(guò)載。
• 順序保證：通過(guò) Partition 內(nèi)消息順序性，支持需要嚴(yán)格順序的業(yè)務(wù)場(chǎng)景。
• 水平擴(kuò)展：通過(guò)增加 Partition 和 Broker，輕松應(yīng)對(duì)數(shù)據(jù)量增長(zhǎng)。

說(shuō)下 Kafka 架構(gòu)、特點(diǎn)、優(yōu)缺點(diǎn)，與其它消息組件相比有什么好處？

架構(gòu)概覽

Kafka 采用 分布式發(fā)布-訂閱模型，核心架構(gòu)包括：

1. 生產(chǎn)者集群：向多個(gè) Topic 推送數(shù)據(jù)。
2. Broker 集群：每個(gè) Broker 存儲(chǔ)部分 Partition 數(shù)據(jù)，通過(guò)副本機(jī)制保障高可用。
3. 消費(fèi)者集群：以 Consumer Group 形式消費(fèi)數(shù)據(jù)，支持水平擴(kuò)展。

核心特點(diǎn)

• 高吞吐：?jiǎn)螜C(jī)可支持每秒百萬(wàn)級(jí)消息寫(xiě)入（依賴(lài)硬件配置）。
• 持久化存儲(chǔ)：數(shù)據(jù)按需保留到磁盤(pán)，支持 TB 級(jí)數(shù)據(jù)累積。
• 水平擴(kuò)展：通過(guò)增加 Partition 和 Broker 實(shí)現(xiàn)擴(kuò)容。
• 多副本機(jī)制：每個(gè) Partition 有多個(gè)副本，確保數(shù)據(jù)不丟失。

優(yōu)缺點(diǎn)對(duì)比

與其他消息組件的對(duì)比

核心優(yōu)勢(shì)：

• 持久化與吞吐量：適合需要長(zhǎng)期存儲(chǔ)、高吞吐的場(chǎng)景。
• 流式處理生態(tài)：與 Flink、Spark Streaming 等深度集成。

闡述 Kafka 生產(chǎn)者與消費(fèi)者相關(guān)概念，如分區(qū)容錯(cuò)性、消費(fèi)端的數(shù)據(jù)一致性、leader 掛掉之后處理方法

生產(chǎn)者相關(guān)

• 分區(qū)策略：生產(chǎn)者決定將消息發(fā)送到 Topic 的哪個(gè) Partition。常見(jiàn)策略包括：輪詢(xún)（默認(rèn)）：均勻分配消息。Key Hash：按消息 Key 的哈希值分配到固定 Partition，保證相同 Key 的消息順序性。
• 容錯(cuò)性：通過(guò) 多副本機(jī)制 實(shí)現(xiàn)。每個(gè) Partition 有多個(gè)副本（Leader 和 Follower），Leader 負(fù)責(zé)讀寫(xiě)，F(xiàn)ollower 同步數(shù)據(jù)。

消費(fèi)者相關(guān)

• 數(shù)據(jù)一致性：At Most Once：消息可能丟失，但不會(huì)重復(fù)。At Least Once：消息可能重復(fù)，但不會(huì)丟失（默認(rèn)模式）。Exactly Once：通過(guò)事務(wù)機(jī)制保證消息僅處理一次（需 Kafka 0.11+）。
• Offset 管理：消費(fèi)者需定期提交 Offset（消費(fèi)位置），若提交失敗可能導(dǎo)致重復(fù)消費(fèi)。

Leader 故障處理

1. 檢測(cè)故障：Zookeeper 或 Controller 監(jiān)控 Broker 狀態(tài)。
2. 選舉新 Leader：從 ISR（同步副本列表）中選擇新的 Leader。
3. 恢復(fù)服務(wù)：生產(chǎn)者/消費(fèi)者自動(dòng)切換到新 Leader，短暫不可用（通常毫秒級(jí)）。

說(shuō)下 Kafka 的 ISR 機(jī)制、選舉機(jī)制，ISR、OSR 和 ACK 分別是什么，ACK 有幾種值？

ISR 機(jī)制

• ISR（In-Sync Replicas）：與 Leader 數(shù)據(jù)同步的副本集合。
• OSR（Out-of-Sync Replicas）：滯后于 Leader 的副本，可能因網(wǎng)絡(luò)或宕機(jī)脫離 ISR。
• AR（Assigned Replicas）：所有副本（ISR + OSR）。

觸發(fā)條件：

• Follower 副本與 Leader 的 消息差值 或 時(shí)間差值 超過(guò)閾值時(shí)，移出 ISR。

選舉機(jī)制

• Controller 角色：某個(gè) Broker 被選舉為 Controller，負(fù)責(zé) Partition 的 Leader 選舉。
• 優(yōu)先副本選舉：優(yōu)先選擇 ISR 中的第一個(gè)副本作為 Leader，減少數(shù)據(jù)不一致風(fēng)險(xiǎn)。

ACK 參數(shù)

ACK 表示生產(chǎn)者需要收到的確認(rèn)信號(hào)：

• 0：無(wú)需確認(rèn)，可能丟失數(shù)據(jù)。
• 1：Leader 寫(xiě)入成功即確認(rèn)（默認(rèn)）。
• all（-1）：所有 ISR 副本寫(xiě)入成功才確認(rèn)，數(shù)據(jù)最安全。

Kafka 的工作原理是什么？如何保證數(shù)據(jù)不丟失、不重復(fù)？

工作原理

1. 生產(chǎn)者推送：消息按分區(qū)策略發(fā)送到 Broker 的 Leader Partition。
2. 副本同步：Leader 將數(shù)據(jù)復(fù)制到 Follower（ISR 內(nèi)）。
3. 消費(fèi)者拉取：消費(fèi)者從 Broker 拉取消息，按 Offset 順序處理。

數(shù)據(jù)不丟失

• 生產(chǎn)者端： 設(shè)置 acks=all，確保所有 ISR 副本寫(xiě)入成功。啟用重試機(jī)制（retries=MAX_VALUE）。
• Broker 端： 多副本機(jī)制，避免單點(diǎn)故障。定期刷盤(pán)（flush.messages 和 flush.ms 參數(shù)）。
• 消費(fèi)者端： 關(guān)閉自動(dòng)提交 Offset，處理完消息再手動(dòng)提交。

數(shù)據(jù)不重復(fù)

• 生產(chǎn)者冪等性： 啟用 enable.idempotence=true，通過(guò)唯一 ID 和序列號(hào)去重。
• 消費(fèi)者端： 實(shí)現(xiàn)業(yè)務(wù)邏輯冪等（如數(shù)據(jù)庫(kù)唯一鍵）。使用 Kafka 事務(wù)（需配合 isolation.level=read_committed）。

Kafka 分區(qū)策略有哪些？如何盡可能保證數(shù)據(jù)可靠性？數(shù)據(jù)丟失怎么處理？如何保證全局有序？

分區(qū)策略是生產(chǎn)者決定將消息寫(xiě)入哪個(gè)分區(qū)的核心邏輯，直接影響數(shù)據(jù)分布和系統(tǒng)性能。常見(jiàn)的策略包括：

• 輪詢(xún)策略：默認(rèn)策略，消息依次分配到不同分區(qū)，確保負(fù)載均衡。
• 哈希策略：根據(jù)消息 Key 的哈希值分配到特定分區(qū)，保證相同 Key 的消息進(jìn)入同一分區(qū)。
• 自定義策略：業(yè)務(wù)可自行實(shí)現(xiàn)分區(qū)邏輯（如按地理位置分配）。

保證數(shù)據(jù)可靠性

1. 多副本機(jī)制：每個(gè)分區(qū)設(shè)置多個(gè)副本（如 replication factor=3），數(shù)據(jù)寫(xiě)入 Leader 后同步到 Follower。
2. ACK 確認(rèn)機(jī)制：生產(chǎn)者設(shè)置 acks=all，確保所有 ISR 副本寫(xiě)入成功后才返回確認(rèn)。
3. 最小同步副本數(shù)：通過(guò) min.insync.replicas 參數(shù)控制 ISR 最小副本數(shù)，避免單點(diǎn)故障導(dǎo)致數(shù)據(jù)丟失。

數(shù)據(jù)丟失處理

• 生產(chǎn)者端： 啟用重試機(jī)制（retries=Integer.MAX_VALUE），避免因網(wǎng)絡(luò)抖動(dòng)導(dǎo)致消息未發(fā)送。使用冪等生產(chǎn)者（enable.idempotence=true），防止重復(fù)發(fā)送。
• Broker 端： 定期檢查副本同步狀態(tài)，及時(shí)剔除故障副本并重新選舉 Leader。配置 unclean.leader.election.enable=false，禁止非 ISR 副本成為 Leader。
• 消費(fèi)者端： 手動(dòng)提交 Offset，確保消息處理完成后再提交，避免消息丟失。

全局有序性

Kafka 僅保證分區(qū)內(nèi)有序，全局有序需通過(guò)以下方式實(shí)現(xiàn)：

• 單分區(qū)寫(xiě)入：所有消息寫(xiě)入同一分區(qū)，犧牲并行性。
• 業(yè)務(wù)層排序：消費(fèi)者拉取多個(gè)分區(qū)數(shù)據(jù)后按時(shí)間戳或序列號(hào)排序（可能引入延遲）。

生產(chǎn)者消費(fèi)者模式與發(fā)布訂閱模式在 Kafka 中的異同點(diǎn)是什么？Kafka 的消費(fèi)者組是如何消費(fèi)數(shù)據(jù)的？

模式對(duì)比

核心差異：

• 消費(fèi)者組的存在使得 Kafka 可以靈活切換模式： 單消費(fèi)者組 → 隊(duì)列模式（競(jìng)爭(zhēng)消費(fèi)）。多消費(fèi)者組 → 發(fā)布訂閱模式（廣播消費(fèi)）。

消費(fèi)者組工作機(jī)制

1. 分區(qū)分配：消費(fèi)者加入組時(shí)，由 Coordinator 分配 Partition（策略包括 Range、RoundRobin、Sticky）。
2. 負(fù)載均衡：組內(nèi)消費(fèi)者數(shù)量與 Partition 數(shù)量匹配時(shí)，每個(gè)消費(fèi)者處理固定 Partition。
3. 再平衡（Rebalance）：消費(fèi)者增減或故障時(shí)，重新分配 Partition，期間服務(wù)短暫不可用。

Kafka 的 offset 管理是怎樣的？為什么同一個(gè)消費(fèi)者組的消費(fèi)者不能消費(fèi)相同的分區(qū)？

Offset 管理機(jī)制

• 存儲(chǔ)位置： 舊版本依賴(lài) Zookeeper，新版本使用內(nèi)部 Topic __consumer_offsets，按 Group ID 和 Partition 存儲(chǔ) Offset。
• 提交方式： 自動(dòng)提交：定期提交（可能重復(fù)或丟失數(shù)據(jù)）。手動(dòng)提交：業(yè)務(wù)處理完成后調(diào)用 commitSync() 或 commitAsync()。

同組消費(fèi)者禁止消費(fèi)相同分區(qū)

• 設(shè)計(jì)目標(biāo)：避免重復(fù)消費(fèi)，保證消息處理的并行性和順序性。
• 分配原則：每個(gè) Partition 只能被組內(nèi)一個(gè)消費(fèi)者獨(dú)占消費(fèi)。
• 例外場(chǎng)景：若消費(fèi)者數(shù)量超過(guò) Partition 數(shù)，多余消費(fèi)者將處于閑置狀態(tài)。

如果有一條 offset 對(duì)應(yīng)的數(shù)據(jù)，消費(fèi)完成之后，手動(dòng)提交失敗，如何處理？正在消費(fèi)一條數(shù)據(jù)時(shí) Kafka 掛了，重啟以后，消費(fèi)的 offset 是哪一個(gè)？

手動(dòng)提交失敗處理

1. 重試提交：在代碼中捕獲提交異常，加入重試邏輯（如指數(shù)退避）。
2. 業(yè)務(wù)補(bǔ)償：若消息處理是冪等的，可允許重復(fù)消費(fèi)。
3. 記錄狀態(tài)：將 Offset 與業(yè)務(wù)結(jié)果一起存儲(chǔ)到數(shù)據(jù)庫(kù)，通過(guò)事務(wù)保證一致性。

Kafka 重啟后的 Offset 恢復(fù)

• 提交策略決定 Offset： 若手動(dòng)提交失敗，消費(fèi)者重啟后會(huì)從最后一次成功提交的 Offset 開(kāi)始消費(fèi)，導(dǎo)致已處理但未提交的消息被重復(fù)消費(fèi)。若使用自動(dòng)提交，可能因提交周期未到而丟失部分 Offset。

Kafka 支持什么語(yǔ)義，怎么實(shí)現(xiàn) Exactly Once？消費(fèi)者和消費(fèi)者組有什么區(qū)別，為什么需要消費(fèi)者組？

消息語(yǔ)義

• At Most Once：消息可能丟失，但不會(huì)重復(fù)（ACK=0）。
• At Least Once：消息可能重復(fù)，但不會(huì)丟失（ACK=1 或 all，默認(rèn)模式）。
• Exactly Once：消息僅處理一次，需結(jié)合以下機(jī)制： 生產(chǎn)者冪等性：通過(guò)唯一 PID 和序列號(hào)去重。事務(wù)機(jī)制：跨生產(chǎn)者和消費(fèi)者的原子操作（isolation.level=read_committed）。

消費(fèi)者 vs 消費(fèi)者組

• 消費(fèi)者：?jiǎn)蝹€(gè)進(jìn)程或線(xiàn)程，負(fù)責(zé)從指定 Partition 拉取數(shù)據(jù)。
• 消費(fèi)者組：多個(gè)消費(fèi)者組成的邏輯單元，實(shí)現(xiàn)： 并行消費(fèi)：組內(nèi)消費(fèi)者共同處理一個(gè) Topic 的多個(gè) Partition。負(fù)載均衡：動(dòng)態(tài)分配 Partition 以應(yīng)對(duì)消費(fèi)者增減。容錯(cuò)性：某個(gè)消費(fèi)者故障時(shí)，其處理的 Partition 會(huì)被重新分配。

需要消費(fèi)者組的原因：

• 橫向擴(kuò)展消費(fèi)能力，適應(yīng)高吞吐場(chǎng)景。
• 支持多種消費(fèi)模式（隊(duì)列或發(fā)布訂閱）。

Kafka producer 的寫(xiě)入數(shù)據(jù)過(guò)程是怎樣的？ack 設(shè)置有哪些，ack 機(jī)制解決了什么問(wèn)題？

Producer 寫(xiě)入流程可以拆解為幾個(gè)關(guān)鍵步驟：

1. 數(shù)據(jù)序列化：將消息 Key 和 Value 按配置的序列化方式（如 Avro、JSON）轉(zhuǎn)換為字節(jié)流。
2. 選擇分區(qū)：根據(jù)分區(qū)策略（輪詢(xún)、哈希、自定義）確定目標(biāo) Partition。
3. 批次聚合：消息不會(huì)立即發(fā)送，而是按 linger.ms（等待時(shí)間）和 batch.size（批次大?。﹨?shù)累積成批次，提升吞吐量。
4. 發(fā)送至 Broker：批次數(shù)據(jù)通過(guò)網(wǎng)絡(luò)發(fā)送到對(duì)應(yīng) Partition 的 Leader Broker。
5. ACK 確認(rèn)：Broker 根據(jù) ACK 配置返回確認(rèn)信號(hào)，生產(chǎn)者決定是否重試。

ACK 參數(shù)類(lèi)型

ACK 機(jī)制解決的問(wèn)題：

• 數(shù)據(jù)丟失風(fēng)險(xiǎn)：通過(guò)副本寫(xiě)入確認(rèn)降低消息丟失概率。
• 一致性保障：控制數(shù)據(jù)在集群中的副本同步級(jí)別。

Kafka 讀取消息是推還是拉的模式，有什么好處？如何實(shí)現(xiàn)高吞吐？

Kafka 采用 消費(fèi)者主動(dòng)拉?。≒ull） 模式，而非服務(wù)端推送（Push）。

拉模式的優(yōu)勢(shì)

• 消費(fèi)速率可控：消費(fèi)者根據(jù)自身處理能力拉取數(shù)據(jù)，避免被壓垮。
• 批量處理：通過(guò) max.poll.records 配置單次拉取消息數(shù)量，提升處理效率。
• 減少無(wú)效推送：消費(fèi)者離線(xiàn)時(shí)，服務(wù)端無(wú)需維護(hù)推送狀態(tài)。

實(shí)現(xiàn)高吞吐的關(guān)鍵手段

1. 分區(qū)并行：多個(gè)消費(fèi)者同時(shí)讀取不同 Partition，橫向擴(kuò)展消費(fèi)能力。
2. 零拷貝技術(shù)：使用 sendfile 系統(tǒng)調(diào)用，減少內(nèi)核態(tài)與用戶(hù)態(tài)數(shù)據(jù)拷貝。
3. 批量壓縮：生產(chǎn)者端對(duì)批次數(shù)據(jù)壓縮（如 Snappy、GZIP），降低網(wǎng)絡(luò)傳輸量。
4. 高效存儲(chǔ)：消息按順序追加到磁盤(pán)，利用頁(yè)緩存加速讀寫(xiě)。

說(shuō)下 Kafka 中的 Partition？數(shù)據(jù)是如何備份的？存的數(shù)據(jù)格式是什么樣的？

Partition 核心概念

• 物理分片：每個(gè) Topic 被劃分為多個(gè) Partition，分布在不同 Broker。
• 有序性保證：Partition 內(nèi)部消息嚴(yán)格按寫(xiě)入順序存儲(chǔ)，支持順序讀寫(xiě)。
• 擴(kuò)展性基礎(chǔ)：通過(guò)增加 Partition 數(shù)量提升 Topic 的吞吐能力。

數(shù)據(jù)備份機(jī)制

1. 副本（Replica）：每個(gè) Partition 配置多個(gè)副本（如 replication factor=3）。
2. Leader-Follower 模型： Leader：處理所有讀寫(xiě)請(qǐng)求。Follower：從 Leader 異步或同步拉取數(shù)據(jù)，保持?jǐn)?shù)據(jù)同步。
3. ISR 列表：僅處于同步狀態(tài)的副本可被選為 Leader。

數(shù)據(jù)存儲(chǔ)格式

• 日志分段：Partition 對(duì)應(yīng)一個(gè)目錄，數(shù)據(jù)按 segment.bytes 切分為多個(gè)日志文件（如 0000000000.log）。
• 索引文件：每個(gè)日志段附帶 .index（偏移量索引）和 .timeindex（時(shí)間戳索引）文件，加速消息查找。