目錄
- 1.kafka數據可靠性怎么保證？ack
- 2.Kafka 中的 ISR是什么？AR是什么？
- 3.Kafka中數據一致性怎么保證？HW、LEO 等分別代表什么？
- 4.Kafka中的分區器、序列化器、攔截器是否了解？它們之間的處理順序是什么？
- 5.Kafka生產者客戶端的整體結構是什么樣子的？使用了幾個線程來處理？分別是什么？
- 6.“消費者組中的消費者個數如果超過 topic 的分區，那么就會有消費者消費不到數據”這句話是否正確？Kafka消費能力不足怎么處理？
- 7.消費者提交消費位移時提交的是當前消費到的最新消息的 offset 還是 offset+1？
- 8.有哪些情況會造成重復消費消息？
- 9.有哪些情況會造成消息漏消費？
- 10.當你使用 kafka-topics.sh 創建（刪除）了一個 topic 之后，Kafka 背后會執行什么邏輯？
- 11.topic 的分區數可不可以增加？如果可以怎么增加？如果不可以，那又是為什么？
- 12.topic 的分區數可不可以減少？如果可以怎么減少？如果不可以，那又是為什么？
- 13.Kafka 有內部的 topic 嗎？如果有是什么？有什么所用？offset維護
- 14.Kafka 分區分配的概念？
- 15.簡述 Kafka 的日志目錄結構？
- 16.如果我指定了一個 offset，Kafka Controller 怎么查找到對應的消息？
- 17.聊一聊 Kafka Controller 的作用？
- 18.Kafka 中有那些地方需要選舉？這些地方的選舉策略又有哪些？
- 19.失效副本是指什么？有那些應對措施？
- 20.Kafka 的哪些設計讓它有如此高的性能？
- 21.kafka可以脫離zookeeper單獨使用嗎？為什么?
- 22.kafka有幾種數據保留的策略？
- 23.什么情況會導致kafka運行變慢？
- 24.為什么要用消息隊列？
- 25.為什么選擇kafka？不選擇RabbitMQ?
- 26.kafka為什么要分區？
- 27.Kafka中是怎么體現消息順序性的？
- 28.kafka如何增加單條日志傳輸大小？
- 29.Exactly Once(既不重復也不丟失)語義?啟動冪等性？
1.kafka數據可靠性怎么保證？ack
topic的每個partition收到producer發送的數據后，都需要向producer發送ack（acknowledgement確認收到),如果producer收到ack，就會進行下一輪的發送，否則重新發送數據。所以引出ack機制
acks:大白話
0:生產者不接收返回值(leader掛或不掛都可能丟失數據)
1:leader收到消息后，返回ack（leader掛了會丟失數據）
-1:等待ISR集合中全部收到數據，返回ack。（leader掛了，可能重復數據）
2.Kafka 中的 ISR是什么？AR是什么？
ISR：與leader保持同步的follower集合
AR：分區的所有副本
當ack=-1時，kafka全部完成同步才發送ack：
設想以下情景：leader收到數據，所有follower都開始同步數據，但有一個follower，因為某種故障，遲遲不能與leader進行同步，那leader就要一直等下去，直到它完成同步，才能發送ack。這個問題怎么解決呢？
Leader維護了一個動態的in-sync replica set (ISR)，意為和leader保持同步的follower集合。當ISR中的follower完成數據的同步之后，leader就會給follower發送ack。如果follower長時間未向leader同步數據，則該follower將被踢出ISR，該時間閾值由
replica.lag.time.max.ms參數設定。Leader發生故障之后，就會從ISR中選舉新的leader。
3.Kafka中數據一致性怎么保證？HW、LEO 等分別代表什么？
LEO：每個副本的最后條消息的offset
HW：一個分區中所有副本最小的offset
HW作用：控制所有副本數據一致性
注意：這只能保證副本之間的數據一致性，並不能保證數據不丟失或者不重復。
eg:
比如leader掛了，此時選了其中一個follower當leader。此時hw=12,通知其他的副本以新的leader的offset開始同步，多退少補。實現所有副本數據一致性。
4.Kafka中的分區器、序列化器、攔截器是否了解？它們之間的處理順序是什么？
處理順序：攔截器-->序列化器-->分區器
分區器:hash計算分區分區號，決定寫入的分區
序列化器:生產者把對象轉換成字節數組才能通過網絡發送給Kafka，消費者需要反序列化
攔截器:在消息發送前做一些准備工作，比如按照某個規則過濾不符合要求的消息、修改消息的內容等
5.Kafka生產者客戶端的整體結構是什么樣子的？使用了幾個線程來處理？分別是什么？
2個線程，一個mian線程處理數據,走攔截器，序列化器，分區器。一個send線程，真正的發送數據
6.“消費者組中的消費者個數如果超過 topic 的分區，那么就會有消費者消費不到數據”這句話是否正確？Kafka消費能力不足怎么處理？
正確。
一個分區只能被同一個消費組的一個消費者消費，如果想要一個分區被多個消費者消費，可以使用多個消費者組
經測試：一個消費者組下的消費者數量<=topic分區數
Kafka消費能力不足怎么處理：
如果是消費能力不足：
1.增加分區數，提升消費者數量。消費者數=分區數
如果是下游數據處理能力不足：
1.提高每批次拉取的數量
2.提升消息處理能力，業務優化，代碼優化
7.消費者提交消費位移時提交的是當前消費到的最新消息的 offset 還是 offset+1？
offset+1
終端測試：創建一個topic，一個生產者，一個消費者。生產一條數據，查看zookeeper數據:
命令：get /consumers/console-consumer-11235/offsets/topicName/0
結果：offset=1。
結論：沒有消費數據之前，分區offset都是0,消費一條數據offset變為1。說明是offset+1
8.有哪些情況會造成重復消費消息？
1.第一步先處理數據，第二步在再提交offset，有肯能重復消費。因為第一步處理完數據，第二步可能沒有提交offset
2.不同消費者組的消費者，消費相同的topic
9.有哪些情況會造成消息漏消費？
和上面問題相反。
1.第一步先提交offset，第二步再處理數據。因為提交了offset可能未處理數據。
10.當你使用 kafka-topics.sh 創建（刪除）了一個 topic 之后，Kafka 背后會執行什么邏輯？
1)會在 zookeeper 中的/brokers/topics 節點下創建一個新的 topic 節點， 如：/brokers/topics/jeffTopic
2)觸發 Controller 的監聽程序
3)kafka Controller 負責 topic 的創建工作，並更新 metadata cache
11.topic 的分區數可不可以增加？如果可以怎么增加？如果不可以，那又是為什么？
分區數可以增加
--alter參數修改
[root@sg-15 bin]# ./kafka-topics.sh --zookeeper 192.168.0.215:2181 --topic topic_name --alter --partitions 4
12.topic 的分區數可不可以減少？如果可以怎么減少？如果不可以，那又是為什么？
分區數不可以減少，因為產生的數據沒法處理。
我們可以使用 bin/kafka-topics.sh 命令對 Kafka 增加 Kafka 的分區數據，但是 Kafka 不支持減少分區數。 Kafka 分區數據不支持減少是由很多原因的，比如減少的分區其數據放到哪里去？是刪除，還是保留？刪除的話，那么這些沒消費的消息不就丟了。如果保留這些消息如何放到其他分區里面？追加到其他分區后面的話那么就破壞了 Kafka 單個分區的有序性。如果要保證刪除分區數據插入到其他分區保證有序性，那么實現起來邏輯就會非常復雜。
13.Kafka 有內部的 topic 嗎？如果有是什么？有什么所用？offset維護
有__consumer_offsets。0.11版本之后可以不依賴於zookeeper寫入offset。
作用：給消費者寫入offset，寫入內入的topic中
14.Kafka 分區分配的概念？
一個消費者組中有多個消費者，一個topic有多個分區，所以必然會涉及到partition的分配問題，即確定那個partition 由哪個consumer來消費。
兩種方式：1）RoundRobin 2）Range
Range:面向topic處理，分配給訂閱了該主題的人
RoundRobin：面向消費者組處理，分配給某個消費者組
15.簡述 Kafka 的日志目錄結構？
每個分區對應一個文件夾，文件夾的命名為topic-0，topic-1，內部為.log和.index文件
.log:存放數據的文件
.index:存放索引信息文件，索引文件中的元數據指向對應數據文件中message的物理偏移地址。
通過index文件快速定位到消費的位置：
第一步：通過二分查找發定位到.index文件
第二步：掃描index文件，找到數據在.log文件中具體的物理偏移量
16.如果我指定了一個 offset，Kafka Controller 怎么查找到對應的消息？
通過index文件快速定位到消費的位置：
第一步：通過二分查找發定位到.index文件
第二步：掃描index文件，找到數據在.log文件中具體的物理偏移量
17.聊一聊 Kafka Controller 的作用？
Controller:
1.負責管理集群Broker的上下線，所有Topic的分區副本分配和leader選舉等工作
2.直接跟zookeeper打交道，元數據更新都由Controller獲取，並通知其他的kafka節點保持一致
18.Kafka 中有那些地方需要選舉？這些地方的選舉策略又有哪些？
1.Controller:通過搶資源方式，誰先搶到誰就是Controller。
2.ISR中的leader:通過isr選舉：
0.9版本之前(老版本):2個條件，與之前leader同步時間最短，同步消息數最多的就是新leader。
0.9版本之后(新版本):1個條件，與之前leader同步時間最短的就是新leader。
19.失效副本是指什么？有那些應對措施？
ISR中的follower長時間未向leader同步數據，則該follower將被踢出ISR。
Leader發生故障之后，就會從ISR中選舉新的leader。
20.Kafka 的哪些設計讓它有如此高的性能？
kafka高效的原因有：
1.分布式的（有分區概率，可以並發讀寫，但是單機器效率也很高）
2.順序讀寫磁盤
3.零復制技術（零拷貝技術）
21.kafka可以脫離zookeeper單獨使用嗎？為什么?
2.8版本以后可以脫離zookeeper單獨使用。
2.8版本以前kafka不能脫離zookeeper單獨使用，因為kafka使用zookeeper管理和協調kafka的節點服務器。
22.kafka有幾種數據保留的策略？
兩種：
1.按照過期時間保留：log.retention.hours=168 //超過168小時就清理數據
2.按照存儲的消息大小保留：忘記了，不常用
23.什么情況會導致kafka運行變慢？
1.cpu性能瓶頸
2.磁盤讀寫瓶頸
3.網絡瓶頸
24.為什么要用消息隊列？
消息隊列主要作用：
1.解偶
2.削峰，緩沖
3.異步
4.暫存數據
25.為什么選擇kafka？不選擇RabbitMQ?
根據業務場景選擇：
RabbitMQ：
1.交易數據,金融場景。具有較高的嚴謹性，數據丟失的可能性更小，同時具備更高的實時性；
2.消息應當盡可能的小，處理關鍵且可靠消息
kafka：
1.高吞吐量，雖然可以通過策略實現數據不丟失，但從嚴謹性角度來講，大不如rabbitmq；
26.kafka為什么要分區？
方便在集群中擴展，每個Partition可以通過調整以適應它所在的機器，而一個topic又可以有多個Partition組成，因此整個集群就可以適應任意大小的數據了。
可以提高並發，因為可以以Partition為單位讀寫。
27.Kafka中是怎么體現消息順序性的？
分區內消息是有序的。
每個分區內，每條消息都有一個offset，故只能保證分區內有序
28.kafka如何增加單條日志傳輸大小？
修改配置文件：server.properties
replica.fetch.max.bytes: 1048576 broker可復制的消息的最大字節數, 默認為1M
message.max.bytes: 1000012 kafka 會接收單個消息size的最大限制， 默認為1M左右
message.max.bytes必須小於等於replica.fetch.max.bytes，否則就會導致replica之間數據同步失敗
29.Exactly Once(既不重復也不丟失)語義?啟動冪等性？
acks:0 At Most Once(最多一次)，生產者發送數據最多發送一次，不接受ack。可以保證數據不重復，但是不能保證數據不丟失。
acks:-1 At least Once(最少一次)，生產者發送數據最少一次，接受到ack為止，可能多次發送，造成數據重復。可以保證不丟數據，但是不能保證數據不重復。
Exactly Once(既不重復也不丟失)語義：0.11版本以前kafka對此無能為力，只能保證數據不丟失，然后在下游(消費者)對數據做全局去重，對性能造成很大的影響。
0.11 版本的 Kafka，引入了一項重大特性：冪等性。所謂的冪等性就是指Producer 不論向 Server 發送多少次重復數據，Server 端都只會持久化一條。冪等性結合 At Least Once 語義，就構成了Kafka 的Exactly Once 語義。
即：At Least Once + 冪等性 = Exactly Once
啟動冪等性：將 Producer 的參數中 enable.idompotence 設置為 true 即可