鎖屏面試題百日百刷，每個工作日堅持更新面試題。請看到最后就能獲取你想要的,接下來的是今日的面試題：

1.解釋一下，在數(shù)據(jù)制作過程中，你如何能從Kafka得到準確的信息？

在數(shù)據(jù)中，為了精確地獲得Kafka的消息，你必須遵循兩件事:?在數(shù)據(jù)消耗期間避免重復，在數(shù)據(jù)生產(chǎn)過程中避免重復。

這里有兩種方法，可以在數(shù)據(jù)生成時準確地獲得一個語義:

每個分區(qū)使用一個單獨的寫入器，每當你發(fā)現(xiàn)一個網(wǎng)絡錯誤，檢查該分區(qū)中的最后一條消息，以查看您的最后一次寫入是否成功

在消息中包含一個主鍵(UUID或其他)，并在用戶中進行反復制

2.解釋如何減少ISR中的擾動？broker什么時候離開ISR？

ISR是一組與leaders完全同步的消息副本，也就是說ISR中包含了所有提交的消息。ISR應該總是包含所有的副本，直到出現(xiàn)真正的故障。如果一個副本從leader中脫離出來，將會從ISR中刪除。

3.Kafka為什么需要復制？

Kafka的信息復制確保了任何已發(fā)布的消息不會丟失，并且可以在機器錯誤、程序錯誤或更常見些的軟件升級中使用。

4.如果副本在ISR中停留了很長時間表明什么？

如果一個副本在ISR中保留了很長一段時間，那么它就表明，跟蹤器無法像在leader收集數(shù)據(jù)那樣快速地獲取數(shù)據(jù)。

5.請說明如果首選的副本不在ISR中會發(fā)生什么？

如果首選的副本不在ISR中，控制器將無法將leadership轉(zhuǎn)移到首選的副本。

6.Kafka有可能在生產(chǎn)后發(fā)生消息偏移嗎？

在大多數(shù)隊列系統(tǒng)中，作為生產(chǎn)者的類無法做到這一點，它的作用是觸發(fā)并忘記消息。broker將完成剩下的工作，比如使用id進行適當?shù)脑獢?shù)據(jù)處理、偏移量等。

作為消息的用戶，你可以從Kafka broker中獲得補償。如果你注視SimpleConsumer類，你會注意到它會獲取包括偏移量作為列表的MultiFetchResponse對象。此外，當你對Kafka消息進行迭代時，你會擁有包括偏移量和消息發(fā)送的MessageAndOffset對象。

7.請說明Kafka?的消息投遞保證（delivery guarantee）機制以及如何實現(xiàn)？

Kafka支持三種消息投遞語義：

①?At most once?消息可能會丟，但絕不會重復傳遞

②?At least one?消息絕不會丟，但可能會重復傳遞

③?Exactly once?每條消息肯定會被傳輸一次且僅傳輸一次，很多時候這是用戶想要的

consumer在從broker讀取消息后，可以選擇commit，該操作會在Zookeeper中存下該consumer在該partition下讀取的消息的offset，該consumer下一次再讀該partition時會從下一條開始讀取。如未commit，下一次讀取的開始位置會跟上一次commit之后的開始位置相同。

可以將consumer設置為autocommit，即consumer一旦讀到數(shù)據(jù)立即自動commit。如果只討論這一讀取消息的過程，那Kafka是確保了Exactly once。但實際上實際使用中consumer并非讀取完數(shù)據(jù)就結(jié)束了，而是要進行進一步處理，而數(shù)據(jù)處理與commit的順序在很大程度上決定了消息從broker和consumer的delivery guarantee semantic。

·讀完消息先commit再處理消息。這種模式下，如果consumer在commit后還沒來得及處理消息就crash了，下次重新開始工作后就無法讀到剛剛已提交而未處理的消息，這就對應于At most once。

·讀完消息先處理再commit消費狀態(tài)(保存offset)。這種模式下，如果在處理完消息之后commit之前Consumer?crash了，下次重新開始工作時還會處理剛剛未commit的消息，實際上該消息已經(jīng)被處理過了，這就對應于At least?once。

·如果一定要做到Exactly once，就需要協(xié)調(diào)offset和實際操作的輸出。經(jīng)典的做法是引入兩階段提交，但由于許多輸出系統(tǒng)不支持兩階段提交，更為通用的方式是將offset和操作輸入存在同一個地方。比如，consumer拿到數(shù)據(jù)后可能把數(shù)據(jù)放到HDFS，如果把最新的offset和數(shù)據(jù)本身一起寫到HDFS，那就可以保證數(shù)據(jù)的輸出和offset的更新要么都完成，要么都不完成，間接實現(xiàn)Exactly once。（目前就high level API而言，offset是存于Zookeeper中的，

無法存于HDFS，而low level API的offset是由自己去維護的，可以將之存于HDFS中）。

總之，Kafka默認保證At least once，并且允許通過設置producer異步提交來實現(xiàn)At most once，而Exactly once要求與目標存儲系統(tǒng)協(xié)作，Kafka提供的offset可以較為容易地實現(xiàn)這種方式。