初識kafka對消息處理與可靠性作出的保證

1. 保證分區消息的順序。同一個生產者給同一個分區寫消息必定是有序的

2. 全部的同步副本寫入了消息時，纔會被認爲已經提交
3. 只要有一個副本是活躍的消息就不會丟失
4. 消費者只能提取已經提交的消息

broker對消息可靠性的處理

1. 複製係數。即一個消息應該有多少個副本（通常3個），這些副本在機架上如何分佈，保證不會應爲1個broker掛掉或者一個機架路由有問題而致使不可用。
2. 不徹底首領選舉。容許不一樣步的副本做爲首領。壞處是對於同一個偏移量，不一樣步的副本做爲首領以後，獲取的是新數據，而原來的副本存儲的是舊數據。

出現場景多是

1. 假設3個副本，2個副本掛了，首領副本正常運行，這時候首領副本也掛了，隨後啓動了新的副本，數據不一樣步；

2. 3個副本中，首領副本正常，可是因爲網絡延遲跟隨副本複製存在必定的延遲，若是首領副本掛了，其它副本都是不一樣步的

3. 最少同步副本。當分區同步副本數少於最少同步副本的時候，就中止接受生產者的消息，拋出異常。以免不徹底選舉所產生的數據寫入與讀出預期不一致的狀況

生產者對消息可靠性的處理

生產者對消息可靠性能夠從兩個方面引入。

• 首先是假設acks=1，可是一共有3個副本，假如首領副本這時候恰巧崩潰，而其餘的副本會被認爲是同步的，對生產者而言，這裏丟失了一個消息；
  
• 其次是假設acks=all,即3個副本都是同步的才確認，若是剛好首領副本崩潰，在選舉期間來的消息，生產者只會收到首領不可用的響應，須要生產者本身去處理消息。
  

於是須要考慮兩個方面：

1. 是acks的設置，不過須要處理吞吐量和消息丟失的關係

ack越多丟失機率越小，可是吞吐量少，得等待收到全部的

2. 是生產者的重試機制，對於可重試的採用kafka內部的重試機制，不可重試的錯誤考慮保存到其它地方，後續進入.

重試帶來的風險是消息重複

消費者對消息可靠性的處理

消費者的最大毛病在於萬一提交了消息偏移量，可是卻沒有處理完，致使這段消息將永遠不會被處理。因此最關鍵的地方在於如何處理消息偏移量。

• 自動偏移提交：保證只提交已經處理過的偏移量
• 手動偏移提交的策略:確保老是在處理日後再提交，確保提交不過於頻繁不過與少，作適當的重試，確保須要一次性語義的場景可以知足

kafka的零拷貝是什麼意思？

零拷貝依賴於操做系統。kafka中存在大量數據持久化道磁盤和磁盤文件經過網絡發送。傳統的方式來講，經歷4次拷貝。首先系統將調用文件數據讀到內存態Buffer,而後應用程序將內核態讀入到用戶態buffer,接着用戶經過socket發送數據將用戶態拷貝到內核態buffer,最後經過DMA拷貝將數據拷貝到NIC 【4次上下文切換】，在linux2.4+操做系統，sendfile系統調用經過零拷貝，數據從DMA拷貝到NIC Buffer,無需CPU拷貝

零拷貝來源，只有兩次上下文切換

數據保留時長是多少？

每一個主題能夠配置保留時長或者大小。每一個分區會有若干個片斷，當前寫入數據的片斷（活躍片斷），永遠不會被刪除，假如配置了保留5天的數據，那麼會保留5天

默認1G或者一週，以小的爲準，一個片斷數據滿了則關閉當前文件，打開新的，方便查找和刪除

數據存儲的文件格式？

儲存格式與生產者發送，發送給消費者的格式一致。消息裏不只包含建和值，同時有大小，檢驗和，版本，壓縮算法，時間戳

如何直接刪除某個鍵？

應用程序發送一個相同的鍵，可是值爲null的消息【稱爲墓碑消息】，進行常規清理時，只保留null消息，一段時間後，消費者消費時發現null的記錄，知曉應該從數據庫中刪除，這段時間後，清理線程便清理掉墓碑消息

消費者若是離線了就幹不掉了

kafka的compact策略？

適用場景：消息中存在同樣的key,可是隻須要保留最新的key的value。執行compact的時候，會早內存中構建一個map,key是消息鍵的hash，值是消息鍵的偏移量，讀取必定量的污濁消息每一個片斷後，若是當前的消息key存在且偏移量小，值過時，或者是null,就拋棄，不然保存

向kafka塞入（讀取）數據的方式？

1. 經過構建kafka客戶端，進行讀取或者寫入。這種方式代碼通常會被嵌入到應用程序
2. 使用Connect Api，面對的是市面上的存儲系統，

Connect Api怎麼處理與其它系統交互的？

connect api包含3個基本概念：worker進程，鏈接器，轉換器 1. 鏈接器：她負責決定須要運行多少的任務，按照任務來拆分數據複製，從worker獲取對應任務的配置並傳遞下去。而任務就負責將數據搬進和移出kafka,任務在初始化的時候會獲得woker進程分配的源文件上下文，裏面提供一些方法能夠對數據進行清理，重試偏移量保存等等操做 2. worker進程：處理HTTP請求【定義鏈接器和鏈接器配置】、保存鏈接器的配置、啓動鏈接器和鏈接器任務、將配置信息傳遞給任務、提交偏移量。總的來講，它負責配置管理、可靠性、高可用性、伸縮性和負載均衡 3. 數據轉換：對於每種數據有本身的schema,源連接器經過轉換器將數據保存到kafka,而目標鏈接器則使用worker指定的轉換器轉換成對應的格式