前面說過kafka主要包括：客戶端，broker，zk，消費者四塊內容。
1. 客戶端
客戶端的作用為收集訊息，將訊息正確的傳送到客戶端。
1.1 訊息
客戶端的訊息包括：crc，版本號，key，length，屬性，value
1.2 客戶端和zk
客戶端啟動之前需要指定zk位址，客戶端需要zk來獲取broker資訊。
客戶端啟動時的步驟：
1. 客戶端向zk註冊自己，獲取所有的broker leader位址
2. watch broker的變動，broker發生變動後，會自動調整傳送的位置，重新做負載均衡
3. 傳送訊息
1.3 負載均衡
客戶端支援多種負載均衡方式。
2 消費者
消費者用來消費訊息的。和生產者一樣，消費者也是需要先和zk打交道。
2.1 訊息
消費者收到的訊息包含了：訊息實體，partition，offset，crc等資訊
2.2 和zk關係
客戶端啟動時的步驟：
1. 消費者向zk註冊自己，獲取所有的broker leader位址。
2. watch broker的變動
3. watch other consumer的加入和退出
2.3 負載均衡
消費者負載均衡由兩方面引起：
1. broker變動
2. consumer變動
負載均衡方案很簡單：n = partition count / consumer count 向下取整。每個
consumer負責n個partition。
比如partition id為：1，2，3，4，5
兩個consumer id為：a，b
則a負責1,2；b負責：3,4,5
2.4 consumer api
目前0.9版本之前，只有high consumer api和****** consumer api兩套介面。
high api比較好用，採用流式消費的方式，支援自動commit，但是不支援offset的設
置，無法手動設定offset。
****** api介面豐富，功能強大，巨難用。需要消費者自己傳送http請求獲取訊息，
自己管理offset，自己維護broker的變更。
好訊息是0.9版本之後（包括0.9）提供了kafkaclient，基本上包含了常用的一些請
求，但據說多執行緒會有問題。
3 broker
broker集群主要解決以下幾個問題：
3.1 訊息備份
kafka的每個partition包括乙個leader broker和若干個follow broker(可以為0)，那麼訊息如何進行同步就比較重要。常見的方式為：同步備份，非同步備份。
同步備份
client傳送訊息到leader之後，leader會將資料寫入cache並flush到磁碟，修改hw，之後follow去拉取訊息，將訊息寫入cache，不用等待flush到磁碟就返回ack影響，leader收到所有follow的ack後向client傳送ack，並標記訊息為commited狀態，只有commited狀態的訊息才能被消費。follow在cache積累一定量訊息或者達到一定時間後會flush到磁碟，再更新本地的hw。
流程為：
1. client傳送訊息
2. leader寫入訊息，修改hw
3. follow同步訊息到cache，傳送ack
4. leader向client傳送ack
5. client傳送下一條
6. follow flush到磁碟，更新hw
非同步備份
client可以選擇非同步傳送，不用等待leader的確認。而leader也不會等待全部follow同步資料。leader允許follow落後一些訊息(可配置)，這樣follow可以批量拉取資料，增強了訊息備份的效能。
3.2 follow失效和重啟
follow存活必須滿足兩個條件：
1. follow沒有down掉
2. follow沒有落後leader太多
leader會跟蹤乙個isr(in-sync replicas)，當發現follow沒有存活時，會自動將其從isr中刪除。follow重啟後，自動讀取本地儲存的hw，刪除hw之後的資料，再從leader進行消費，追上leader後會被加入isr。
3.3 leader失效
zk裡面動態維護了乙個isr，可以認為這個isr裡面所有的follow都跟上了leader，選擇新的leader只能從isr裡面產生，當乙個leader失效以後，zk會選擇第乙個向zk註冊並在isr裡面的follow為leader。選出leader後，其它的follow會同步新leader的hw，保持本地的hw和leader的一致，之後新leader就可以進行工作。
3.4 所有replicas失效
當只有乙個replicas還存活的時候，kafka就可以正常進行工作。如果kafka所有的replicas都失效了，有以下兩種方案：
1. 等待isr中任意乙個replicas活過來，並作為leader
2. 選擇任意乙個replicas活過來，並作為leader
目前kafka選擇了第二種方式。後續kafka可能會採取使用者可配方式。
Kafka入門 4 kafka基準測試
基準測試 benchmark testing 是一種測量和評估軟體效能指標的活動。我們可以通過基準測試，了解到軟體 硬體的效能水平。主要測試負載的執行時間 傳輸速度 吞吐量 資源佔用率等。測試步驟 啟動kafka集群 建立乙個1個分割槽1個副本的topic benchmark 同時執行生產者 消費者...
kafka學習筆記4 kafka消費者
消費者和消費者群組 kafka消費者分為消費者群組和消費者。每乙個kafka消費者都隸屬於乙個kafka消費者群組。每個消費者群組可以對應乙個或多個topic，每個topic內的分割槽只能對應消費者群組內的乙個消費者，當消費者比topic中的分割槽數多時，多餘的消費者不會接收topic中的資訊。這種...
kafka使用心得隨手記
最近手上的專案需要拉去kafka的訊息進行消費，不過以前沒使用過kafka，這兩天安裝及摸索使用了kafka，對於在乙個服務裡開啟多個kafka的消費者來提高消費速度的問題上，目前自己已摸索清楚並測試通過，故記錄下。一.專案場景 在分布式的情景下，有多個應用服務將訊息推送到kafka的topic裡，...