kafka是乙個分布式訊息發布訂閱系統，kafka系統快速、可擴充套件並且可持久化。它的分割槽特性，可複製和可容錯都是其不錯的特性。topic
topic資訊被儲存在不同分割槽中，其中每乙個分割槽內部的訊息都是有序的且同時只能夠被乙個消費者組中的乙個消費者消費。乙個消費者可以對應一到多個分割槽，若消費者比分區多則必然會有消費者閒置。
每乙個分割槽中的訊息都被分配了乙個序列號（offset）也就是偏移量，偏移量由消費者控制，消費者可以將偏移量重置為更老的乙個偏移量，重新讀取訊息，消費者基於偏移量消費topic中的訊息，kafka預設儲存訊息的時間為7天。
topic分割槽儲存能夠加大kafka的吞吐量。
我們資料存在不同的partition上，那kafka就把這些partition做備份。比如，現在我們有三個partition，分別存在三颱broker上。每個partition都會備份，這些備份散落在不同的broker上。
順序性因為topic分割槽中訊息只能由消費者組中的唯一乙個消費者處理，所以訊息肯定是按照先後順序進行處理的。但是它也僅僅是保證topic的乙個分割槽順序處理，不能保證跨分割槽的訊息先後處理順序。
所以，如果你想要順序的處理topic的所有訊息，那就只提供乙個分割槽。
生產者在往topic的partition儲存中先寫入快取，等一定時間或者一定資料量之後才批量的寫入到磁碟中。
消費者在讀取partition中的資料時，通過zerocopy方式直接讀取核心層中的資料，避免了一層拷貝，提高了效率。
offset
在以前版本的kafka，這個offset是由zookeeper來管理的，後來kafka開發者認為zookeeper不合適大量的刪改操作，於是把offset在broker以內部topic(__consumer_offsets)的方式來儲存起來。
但是在sparkstreaming與kafka的使用中 偏移量還是自己儲存的由spark自己儲存 儲存在checkpoint中但是會影響到kafka監控工具的使用，因此手動更新偏移量到zookepper中。
ack確認機制 確保資料可靠性
kafka的ack確認機制分為三種，分別為0,1，-1（all）
為0時 意味著producer不等待broker同步完成的確認，繼續傳送下一條(批)資訊
提供了最低的延遲。但是最弱的永續性，當伺服器發生故障時，就很可能發生資料丟失。例如leader已經死亡，producer不知情，還會繼續傳送訊息broker接收不到資料就會資料丟失
為1時 意味著producer要等待leader成功收到資料並得到確認，才傳送下一條message。此選項提供了較好的永續性較低的延遲性。
partition的leader死亡，follwer尚未複製，資料就會丟失
為-1（all） 意味著producer要等待leader成功並且follower同時收到資料並得到確認，才傳送下一條message。
isr機制 確保資料的一致性
當訊息寫入leader後，假設 replica.lag.max.messages 設定為4，這意味著只要 follower 落後 leader 的訊息不超過3條，它就不會從 isr 中刪除。我們把 replica.lag.time.max.ms 設定為500毫秒，這意味著只要 follower 每隔500毫秒或更早地向 leader 傳送乙個 fetch 請求，它們就不會被標記為死亡並且不會從 isr 中刪除當leader宕機發生故障後就會從isr列表中選出新的leader。
kafka的三種消費方式
如何保證正好一次消費
producer如果傳送訊息失敗，則可以通過重試解決，若broker端的應答未成功傳送給producer（如網路抖動），producer此時也會進行重試，再次傳送原來的訊息。這就是kafka預設提供訊息至少一次性的原因，不過這可能會導致訊息重**送。
如果需要保證訊息消費的「最多一次」，那麼禁止producer的重試即可。但是寫入失敗的訊息如果不重試則會永遠丟失。是否有其他方法來保證訊息的傳送既不丟失，也不重複消費？或者說即使producer重**送了某些訊息，broker端也能夠自動去重。
冪等性所謂的冪等，簡單說就是對介面的多次呼叫所產生的結果和呼叫一次是一致的。在kafka中，producer預設不是冪等性的，kafka於0.11.0.0版本引入該特性。設定引數enable.idempotence為true即可指定producer的冪等性。開啟冪等生產者後，kafka會自動進行訊息的去重傳送。為了實現生產者的冪等性，kafka引入了producer id（後簡稱pid）和序列號（sequence number）兩個概念。
生產者例項在被建立的時候，會分配乙個pid，這個pid對使用者完全透明。對於每個pid，訊息傳送到的每乙個分割槽都有對應的序列號，這些序列號從0開始單調遞增。生產者每傳送一條訊息就會將 sn_old + 1，說明中間有資料尚未寫入，出現了訊息亂序，可能存在訊息丟失的現象，對應的生產者會丟擲outofordersequenceexception。
注意：序列號針對事務
冪等性並不能跨多個分割槽運作，而kafka事務則可以彌補這個缺陷。kafka從0.11版本開始提供了對事務的支援，主要在read committed隔離級別。它能保證多條訊息原子性地寫入到目標分割槽，同時也能保證consumer只能看到事務成功提交的訊息。
producer端配置
事務型producer能保證訊息原子性地寫入多個分割槽。批量的訊息要麼全部寫入成功，要麼全部失敗。並且，事務型producer在重啟後，kafka依然保證它們傳送訊息的精確一次處理。開啟事務型producer的配置如下：
冪等性producer一樣，開啟enable.idempotence = true。
設定producer端引數transcational.id。最好為其設定乙個有意義的名字。
設定了事務型的producer可以呼叫一些事務api，如下：inittransaction、begintransaction、committransaction和aborttransaction，分別對應事務的初始化、事務開啟、事務提交和事務終止。
producer.inittransactions();
try
catch (kafkaexecption e)
consumer端配置
讀取事務型producer傳送的訊息時，consumer端的isolation.level引數表徵著事務的隔離級別，即決定了consumer以怎樣的級別去讀取訊息。該引數有以下兩個取值：
read_uncommitted：預設值，表面consumer能夠讀到kafka寫入的任何訊息，不論事務型producer是否正常提交了事務。顯然，如果啟用了事務型的producer，則consumer端引數就不要使用該值，否則事務是無效的。
read_committed：表面consumer只會讀取事務型producer成功提交的事務中寫入的訊息，同時，非事務型producer寫入的所有訊息對consumer也是可見的。
總結kafka所提供的訊息精確一次消費的手段有兩個：冪等性producer和事務型producer。
冪等性producer只能保證單會話、單分割槽上的訊息冪等性；
事務型producer可以保證跨分割槽、跨會話間的冪等性；
事務型producer功能更為強大，但是同時，其效率也會比較低下
spark使用kafka的兩種方式
同步非同步模式的區別
producer 傳送訊息還可以選擇同步（預設，通過 producer.type=sync 配置） 或者（producer.type=async）模式。如果設定成非同步，雖然會極大的提高訊息傳送的效能，但是這樣會增加丟失資料的風險。如果需要確保訊息的可靠性，必須將 producer.type 設定為 sync。
資料可靠性的保證
kafka如何實現高吞吐率
kafka分割槽數量可以修改嗎
kafka的分割槽數量可以增加但是不可以減少，因為kafka的分割槽若是減少的話那麼分割槽裡面的資料就不好處理，刪除的話就會丟失資料，保留的話儲存到其他分割槽就會破壞其他分割槽的資料一致性所以kafka的分割槽數量不能減少。
kafka保證資料一致性和可靠性？
一致性定義 若某條訊息對client可見，那麼即使leader掛了，在新leader上資料依然可以被讀到。hw highwatermark client可以從leader讀到的最大msg offset，即對外可見的最大offset，hw max replica.offset 對於leader新收到的...
Kafka 可靠性和一致性
為了保證資料的可靠性，我們最少需要配置一下幾個引數 1.producer 級別 acks all 或者 request.required.acks 1 同時發生模式為同步 producer.type sync leader 在返回確認或錯誤響應之前，會等待所有同步副本都收到悄息 2.topic 級別...
kafka如何保證資料可靠性和資料一致性
在只考慮 kafka 本身使用方式的前提下如何最大程度地提高可靠性。1.就 kafka 而言，越多的副本數越能夠保證資料的可靠性，副本數可以在建立主題時配置，也可以在後期修改，不過副本數越多也會引起磁碟 網路頻寬的浪費，同時會引起效能的下降。一般而言，設定副本數為 3 即可滿足絕大多數場景對可靠性的...