kafka是乙個分布式的基於發布/訂閱模式的訊息佇列，主要用於大資料實時處理領域。
要理解kafka首先要有分布式的概念，要有訊息佇列的概念。分布式系統最大的優勢就是解耦和削峰，這種情況下，a系統生成了乙個訊息，b系統非同步獲取，那麼就需要乙個存放訊息的訊息佇列(mq)。
相比較傳統的訊息佇列，訊息被消費確認後會刪除，而kafka有持久化功能，b系統消費完，c系統還可以再次消費。kafka預設訊息儲存168小時，即7天，可配置。
kafka的核心概念有：broker、topic、partition、leader、follower、isr、acks、offset、leo和hw，下面分別理解一下。
不管使用哪一種構造器，最終實現如下：
public producerrecord(string topic, integer partition, long timestamp, k key, v value, iterable headers) else if (timestamp != null && timestamp < 0l) else if (partition != null && partition < 0) else
}
1)指定partition值，訊息直接放入指定的分割槽；
2)既沒有partition也沒有key，採用round-robin演算法，隨機生成乙個整數，與topic的partition數取餘得到partition值，後續在這個整數上自增；
3)沒有指定partition但有key，將key的hash值與topic的partition數進行取餘得到partition值；
4)既有partition又有key，以partition為準，key失效。
每乙個broker都有乙個leader和多個follower，leader和ollower不能在同乙個節點上，否則服務故障，主從都會失效。
思考：producer向kafka傳送訊息，如何保障訊息的可靠性？有兩種方案：
1)為了保障訊息不丟失，至少要半數以follower上同步完成，broker發確認。
半數以上同步完成，有且只有乙個follower才有可能獲得半數以上投票，這樣就不會存在選出來多個leader了，而且這半數以上的follower都完成了同步，能保證參與選舉的follower(自己本身也是候選人)都滿足成為leader的資格。
比如有7個follower，半數以上即4個follower同步完成，全部投選1號為leader，leader唯一可確定。如果選舉是2，2,的結果，則沒有任何乙個follower有資格成為leader。
2)等待所有follower全部同步完成發確認，此時可以隨便選舉乙個follower作為leader。
第一種方案，n個副本掛掉了，需要2n+1個副本才能恢復資料；
第二種方案，n個副本掛掉了，只需要n+1個副本就能恢復資料；
優選第二種方案：第一種方案當n+1個同步完成，n個掛掉，需要2n+1個副本，而每個partition的資料量都很大，會造成資料冗餘。
但是第二種方案存在萬一某個follower遲遲無法同步完成，會造成嚴重延遲，為了解決這個問題，kafka維護了乙個動態follower集合——isr：
isr初始集合是所有follower，如果某個follower故障，在指定時間內無法同步，會被踢出isr，這樣只要保證isr中的剩餘follower同步完成就可以傳送確認。
replica.lag.time.ms引數用來指定超時的時間閥值。
acks用來指定broker什麼時候發收到訊息的確認：
kafka的儲存訊息有兩個檔案，.log和.index；offset指定消費者要消費訊息的位置，如下圖，根據offset=3先定位.index檔案，找到3對應的索引值，然後根據索引值756找到.log中對應的具體訊息：
思考：offset是儲存在**？kafka0.9版本之前是儲存在zookeeper上，0.9之後儲存在kafka內建的乙個topic上。
leo：log end offset；
hw：high watermark，hw是所有follower中最小的leo。
這兩個概念主要用於follower同步中，每個follower都有自己的leo，因為每個follower同步有快有慢，所有出現了hw，類似木桶的最短板，如下圖：
比如說leader掛掉了，下圖中的follower3成為leader，那follower1和follower2需要同步資料，各自從hw位截斷，從hw=10開始同步，最終一致，leader和follower都是13；
假設follower2成為leader，follower1和follower3從從hw=10截斷，發現和follower2已經一致，此時不需要額外同步，最終一致，leader和follower都是10。
leo之前的訊息是完全一致的，而hw之後的資料不一致，所以kafka設計上hw之後資料對於消費者是不可見的。
follower故障被踢出之後，重新連線是從hw開始同步資料。
hw只能保證資料一致性，不能保證重複或者丟失，重複或者丟失由acks來定。
訊息佇列 Kafka學習
kafka是乙個分布式的訊息佇列，學習見apache kafka文件，中文翻譯見kafka分享，乙個簡單的入門例子見kafka 入門例項。本文只針對自己感興趣的點記錄下。producer consumer 訊息的生成者和使用者。broker kafka server充當broker角色，起到訊息佇列...
訊息佇列 Kafka學習
kafka是乙個分布式的訊息佇列，學習見apache kafka文件，中文翻譯見kafka分享，乙個簡單的入門例子見kafka 入門例項。本文只針對自己感興趣的點記錄下。producer consumer 訊息的生成者和使用者。broker kafka server充當broker角色，起到訊息佇列...
訊息佇列與Kafka
2019 04 09 本篇文章系本人就當前所掌握的知識關於 訊息佇列 與 kafka 知識點的一些簡要介紹，不保證文章所述內容的絕對 完全正確性。筆者這裡所提到的 訊息系統 可不是那些社交 上用於站內交流的訊息系統。在網際網路中，但凡涉及到訊息傳遞的過程，都可以稱之為是乙個訊息系統，規模或大或小而已...