1.1 kafka的特性:
controller在zookeeper註冊watch
zookeeper管理kakfabroker集群。所有的kafkabroker節點一起去zookeeper上註冊乙個臨時節點,只有乙個能成功,成功註冊的節點稱之為
kafkabrokercontroller,其餘的稱之為kafkabrokerfollower。
kafkabrokercontroller作用:
監聽其餘的broker的狀態,如果有broker發生宕機,那麼回去通知zookeeper，zookeeper就會通知其他的kafkabroker,進行副本恢復.
topic:
相當於佇列,同一類的訊息丟傳送到該佇列
partition:
kafka採用分割槽的思路,將topic又劃分為多個分割槽,為了提高容錯率,將分割槽打散存放在不同的broker中
partition replica:分割槽備份
consumergroup:消費分組
消費執行緒構建的分組
gourp下的某個執行緒消費,只能消費某個partition裡的一條訊息,也就是consumer跟partition是1:1的關係
一般最好將group裡的執行緒數量跟topic的partition保持一致效能最好,不浪費,也能保持良好的併發效能
partition replica
負載均衡
hash(message) % [broker數量]
num.partitions引數來配置更改topic的partition數量
1 乙個topic的partition數量大於等於broker的數量，可以提高吞吐率。
2 同乙個partition的replica盡量分散到不同的機器，高可用。
ack列表
kafka順序消費如何保證
kafka只能保證partition內是有序的，但是partition間的有序是沒辦法的。
傳送訊息的時候指定傳送到某乙個partition 同乙個partition內部有序
可以指定partition 也可以指定某個key,具有相同key的傳送到同乙個partition
kafka如何避免重複性消費:
業務端進行控制,設定快取來判斷當前訊息是否被消費
kafka如何避免訊息丟失
丟失資料的根源:
生產端aca各種屬性代表的含義
ack的三種機制
0:producer不等待broker同步完成的確認，繼續傳送下一條(批)資訊
最低的延遲。但是最弱的永續性，當伺服器發生故障時，就很可能發生資料丟失。例如leader已經死亡，producer不知情，
還會繼續傳送訊息broker接收不到資料就會資料丟失
1:producer要等待leader成功收到資料並得到確認，才傳送下一條message。此選項提供了較好的永續性較低的延遲性
partition的leader死亡，follwer尚未複製，資料就會丟失
-1:producer得到follwer確認，才傳送下一條資料
永續性最好，延時性最差。
isr:leader中記錄的與其保持同步的備份分割槽的列表目錄
如果是0 1的時候如果leader出現宕機那麼訊息將會丟失
解決方案 ack=-1
消費端offset的維護:
在kafka中，當前讀到哪條訊息的offset值是由consumer來維護的，因此，consumer可以自己決定如何讀取kafka中的資料。
kafka提供了兩種consumer api來進行offset的維護 high level api low level api
high level api:kafka自己維護offset值
high level api是consumer讀的partition的offsite是存在zookeeper上。
high level api 會啟動另外乙個執行緒去每隔一段時間，offsite自動同步到zookeeper上。
換句話說，如果使用了high level api， 每個message只能被讀一次，一旦讀了這條message之後，無論我consumer的處理是否ok
。high level api的另外乙個執行緒會自動的把offiste+1同步到zookeeper上。
如果consumer讀取資料出了問題，offsite也會在zookeeper上同步。
因此，如果consumer處理失敗了，會繼續執行下一條。這往往是不對的行為。
因此，best practice是一旦consumer處理失敗，直接讓整個conusmer group拋exception終止，
但是最後讀的這一條資料是丟失了，因為在zookeeper裡面的offsite已經+1了。
等再次啟動conusmer group的時候，已經從下一條開始讀取處理了。
low level api:人工維護offset值
low level api是consumer讀的partition的offset在consumer自己的程式中維護。
不會同步到zookeeper上。但是為了kafka manager能夠方便的監控，一般也會手動的同步到zookeeper上。
這樣的好處是一旦讀取某個message的consumer失敗了，這條message的offsite我們自己維護，我們不會+1。
下次再啟動的時候，還會從這個offsite開始讀。這樣可以做到exactly once對於資料的準確性***。
因此如果採用high levle可能會產生訊息丟失,因為他不會去管消費中是否出現異常,offset自動偏移,如果出現異常將無法進行回滾
解決方案:關閉自動提交offset，處理完之後受到移位。實際就是使用low level api
學習筆記 Kafka
kafka kafka把資料往磁碟上寫，但是在磁碟上存它的讀寫速度比記憶體快，這個依賴於預讀和後寫功能，但是這個預讀和後寫必須是按照順序的方式，若沒有順序的方式優化的話，不存在什麼預讀和後寫。特點 訊息持久化 能落到磁碟 通過o 1 的磁碟資料結構提供資料的持久化 高吞吐量 分布式 擴充套件能力強 ...
Kafka學習筆記
1.1簡介 apache kafka 是分布式發布 訂閱訊息系統 訊息中介軟體 它最初由 linkedin 公司開發，之後成為 apache 專案的一部分。kafka 是一種快速 可擴充套件的 設計內在就是分布式的，分割槽的和可複製的提交日誌服務。apache kafka 與傳統訊息系統相比，有以下...
kafka學習筆記
名詞解釋 物理儲存結構 說明segment中index data file對應關係物理結構如下 message資料結構 資料查詢過程 讀取offset 368776的message todo 定位是哪個segment檔案 通過segment檔名二分查詢，比如 當offset 368776時定位到00...