1.Kafka 的設計時什麼樣的呢?面試
Kafka 將消息以 topic 爲單位進行概括數組
將向 Kafka topic 發佈消息的程序成爲 producers.緩存
將預訂 topics 並消費消息的程序成爲 consumer.網絡
Kafka 以集羣的方式運行,能夠由一個或多個服務組成,每一個服務叫作一個 broker.負載均衡
producers 經過網絡將消息發送到 Kafka 集羣,集羣向消費者提供消息分佈式
2.數據傳輸的事物定義有哪三種?性能
數據傳輸的事務定義一般有如下三種級別:fetch
(1)最多一次: 消息不會被重複發送,最多被傳輸一次,但也有可能一次不傳輸ui
(2)最少一次: 消息不會被漏發送,最少被傳輸一次,但也有可能被重複傳輸.設計
(3)精確的一次(Exactly once): 不會漏傳輸也不會重複傳輸,每一個消息都傳輸被一次而
且僅僅被傳輸一次,這是你們所指望的
3.Kafka 判斷一個節點是否還活着有那兩個條件?
(1)節點必須能夠維護和 ZooKeeper 的鏈接,Zookeeper 經過心跳機制檢查每一個節點的連
接
(2)若是節點是個 follower,他必須能及時的同步 leader 的寫操做,延時不能過久
4.producer 是否直接將數據發送到 broker 的 leader(主節點)?
producer 直接將數據發送到 broker 的 leader(主節點),不須要在多個節點進行分發,爲了
幫助 producer 作到這點,全部的 Kafka 節點均可以及時的告知:哪些節點是活動的,目標
topic 目標分區的 leader 在哪。這樣 producer 就能夠直接將消息發送到目的地了
五、Kafa consumer 是否能夠消費指定分區消息?
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 阻塞知道新消息到達
(固然也能夠阻塞知道消息的數量達到某個特定的量這樣就能夠批量發
7.Kafka 存儲在硬盤上的消息格式是什麼?
消息由一個固定長度的頭部和可變長度的字節數組組成。頭部包含了一個版本號和 CRC32
校驗碼。
消息長度: 4 bytes (value: 1+4+n)
版本號: 1 byte
CRC 校驗碼: 4 bytes
具體的消息: n bytes
8.Kafka 高效文件存儲設計特色:
(1).Kafka 把 topic 中一個 parition 大文件分紅多個小文件段,經過多個小文件段,就容易定
期清除或刪除已經消費完文件,減小磁盤佔用。
(2).經過索引信息能夠快速定位 message 和肯定 response 的最大大小。
(3).經過 index 元數據所有映射到 memory,能夠避免 segment file 的 IO 磁盤操做。
(4).經過索引文件稀疏存儲,能夠大幅下降 index 文件元數據佔用空間大小。
9.Kafka 與傳統消息系統之間有三個關鍵區別
(1).Kafka 持久化日誌,這些日誌能夠被重複讀取和無限期保留
(2).Kafka 是一個分佈式系統:它以集羣的方式運行,能夠靈活伸縮,在內部經過複製數據
提高容錯能力和高可用性
(3).Kafka 支持實時的流式處理
10.Kafka 建立 Topic 時如何將分區放置到不一樣的 Broker 中
副本因子不能大於 Broker 的個數;
第一個分區(編號爲 0)的第一個副本放置位置是隨機從 brokerList 選擇的;
其餘分區的第一個副本放置位置相對於第 0 個分區依次日後移。也就是若是咱們有 5 個
Broker,5 個分區,假設第一個分區放在第四個 Broker 上,那麼第二個分區將會放在第五
個 Broker 上;第三個分區將會放在第一個 Broker 上;第四個分區將會放在第二個
Broker 上,依次類推;
剩餘的副本相對於第一個副本放置位置實際上是由 nextReplicaShift 決定的,而這個數也是
隨機產生的
11.Kafka 新建的分區會在哪一個目錄下建立
在啓動 Kafka 集羣以前,咱們須要配置好 log.dirs 參數,其值是 Kafka 數據的存放目錄,
這個參數能夠配置多個目錄,目錄之間使用逗號分隔,一般這些目錄是分佈在不一樣的磁盤
上用於提升讀寫性能。
固然咱們也能夠配置 log.dir 參數,含義同樣。只須要設置其中一個便可。
若是 log.dirs 參數只配置了一個目錄,那麼分配到各個 Broker 上的分區確定只能在這個
目錄下建立文件夾用於存放數據。
可是若是 log.dirs 參數配置了多個目錄,那麼 Kafka 會在哪一個文件夾中建立分區目錄呢?
答案是:Kafka 會在含有分區目錄最少的文件夾中建立新的分區目錄,分區目錄名爲 Topic
名+分區 ID。注意,是分區文件夾總數最少的目錄,而不是磁盤使用量最少的目錄!也就
是說,若是你給 log.dirs 參數新增了一個新的磁盤,新的分區目錄確定是先在這個新的磁
盤上建立直到這個新的磁盤目錄擁有的分區目錄不是最少爲止。
12.partition 的數據如何保存到硬盤
topic 中的多個 partition 以文件夾的形式保存到 broker,每一個分區序號從 0 遞增,
且消息有序
Partition 文件下有多個 segment(xxx.index,xxx.log)
segment 文件裏的 大小和配置文件大小一致能夠根據要求修改 默認爲 1g
若是大小大於 1g 時,會滾動一個新的 segment 而且以上一個 segment 最後一條消息的偏移
量命名
13.kafka 的 ack 機制
request.required.acks 有三個值 0 1 -1
0:生產者不會等待 broker 的 ack,這個延遲最低可是存儲的保證最弱當 server 掛掉的時候
就會丟數據
1:服務端會等待 ack 值 leader 副本確認接收到消息後發送 ack 可是若是 leader 掛掉後他
不確保是否複製完成新 leader 也會致使數據丟失
-1:一樣在 1 的基礎上 服務端會等全部的 follower 的副本受到數據後纔會受到 leader 發出
的 ack,這樣數據不會丟失
14.Kafka 的消費者如何消費數據
消費者每次消費數據的時候,消費者都會記錄消費的物理偏移量(offset)的位置
等到下次消費時,他會接着上次位置繼續消費
15.消費者負載均衡策略
一個消費者組中的一個分片對應一個消費者成員,他能保證每一個消費者成員都能訪問,如
果組中成員太多會有空閒的成員
16.數據有序
一個消費者組裏它的內部是有序的
消費者組與消費者組之間是無序的
17.kafaka 生產數據時數據的分組策略
生產者決定數據產生到集羣的哪一個 partition 中
每一條消息都是以(key,value)格式
Key 是由生產者發送數據傳入
因此生產者(key)決定了數據產生到集羣的哪一個 partition