kafka基本概念
kafka是乙個分布式的，分割槽的訊息(官方稱之為commit log)服務。它提供乙個訊息系統應該具備的功能，但是確有著獨特的設計。可以這樣來說，kafka借鑑了jms規範的思想，但是確並沒有完全遵循jms規範。首先，讓我們來看一下基礎的訊息(message)相關術語：
因此，從乙個較高的層面上來看，producer通過網路傳送訊息到kafka集群，然後consumer來進行消費，如下圖：
服務端(brokers)和客戶端(producer、consumer)之間通訊通過tcp協議來完成。
可以這麼來理解topic，partition和broker
乙個topic，代表邏輯上的乙個業務資料集，比如按資料庫裡不同表的資料操作訊息區分放入不同topic，訂單相關操作訊息放入訂單topic，使用者相關操作訊息放入使用者topic，對於大型**來說，後端資料都是海量的，訂單訊息很可能是非常巨量的，比如有幾百個g甚至達到tb級別，如果把這麼多資料都放在一台機器上可定會有容量限制問題，那麼就可以在topic內部劃分多個partition來分片儲存資料，不同的partition可以位於不同的機器上，每台機器上都執行乙個kafka的程序broker。
kafka集群，在配置的時間範圍內，維護所有的由producer生成的訊息，而不管這些訊息有沒有被消費。例如日誌保留(log retention )時間被設定為2天。kafka會維護最近2天生產的所有訊息，而2天前的訊息會被丟棄。kafka的效能與保留的資料量的大小沒有關係，因此儲存大量的資料(日誌資訊)不會有什麼影響。
每個consumer是基於自己在commit log中的消費進度(offset)來進行工作的。在kafka中，消費offset由consumer自己來維護；一般情況下我們按照順序逐條消費commit log中的訊息，當然我可以通過指定offset來重複消費某些訊息，或者跳過某些訊息。
這意味kafka中的consumer對集群的影響是非常小的，新增乙個或者減少乙個consumer，對於集群或者其他consumer來說，都是沒有影響的，因為每個consumer維護各自的offset。所以說kafka集群是無狀態的，效能不會因為consumer數量受太多影響。kafka還將很多關鍵資訊記錄在zookeeper裡，保證自己的無狀態，從而在水平擴容時非常方便。
為什麼要對topic下資料進行分割槽儲存？
1、commit log檔案會受到所在機器的檔案系統大小的限制，分割槽之後，理論上乙個topic可以處理任意數量的資料。
2、為了提高並行度。
分布式distribution
log的partitions分布在kafka集群中不同的broker上，每個broker可以請求備份其他broker上partition上的資料。kafka集群支援配置乙個partition備份的數量。
針對每個partition，都有乙個broker起到「leader」的作用，0個或多個其他的broker作為「follwers」的作用。leader處理所有的針對這個partition的讀寫請求，而followers被動複製leader的結果。如果這個leader失效了，其中的乙個follower將會自動的變成新的leader。
producers
生產者將訊息傳送到topic中去，同時負責選擇將message傳送到topic的哪乙個partition中。通過roundrobin做簡單的負載均衡。也可以根據訊息中的某乙個關鍵字來進行區分。通常第二種方式使用的更多。
consumers
傳統的訊息傳遞模式有2種：佇列( queue) 和（publish-subscribe）
queue模式：多個consumer從伺服器中讀取資料，訊息只會到達乙個consumer。
publish-subscribe模式：訊息會被廣播給所有的consumer。
kafka基於這2種模式提供了一種consumer的抽象概念：consumer group。
queue模式：所有的consumer都位於同乙個consumer group 下。
publish-subscribe模式：所有的consumer都有著自己唯一的consumer group。
上圖說明：由2個broker組成的kafka集群，總共有4個partition(p0-p3)。這個集群由2個consumer group， a有2個consumer instances ，b有四個。
通常乙個topic會有幾個consumer group，每個consumer group都是乙個邏輯上的訂閱者（logicalsubscriber ）。每個consumer group由多個consumer instance組成，從而達到可擴充套件和容災的功能
消費順序
kafka比傳統的訊息系統有著更強的順序保證。
乙個partition同乙個時刻在乙個consumer group中只有乙個consumer instance在消費，從而保證順序。consumer group中的consumer instance的數量不能比乙個topic中的partition的數量多，否則，多出來的consumer消費不到訊息。
kafka只在partition的範圍內保證訊息消費的區域性順序性，不能在同乙個topic中的多個partition中保證總的消費順序性。
如果有在總體上保證消費順序的需求，那麼我們可以通過將topic的partition數量設定為1，將consumer group中的consumer instance數量也設定為1。
從較高的層面上來說的話，kafka提供了以下的保證：
傳送到乙個topic中的message會按照傳送的順序新增到commit log中。意思是，如果訊息 m1，m2由同乙個producer傳送，m1比m2傳送的早的話，那麼在commit log中，m1的offset就會比commit 2的offset小。
乙個consumer在commit log中可以按照傳送順序來消費message。如果乙個topic的備份因子設定為n，那麼kafka可以容忍n-1個伺服器的失敗，而儲存在commit log中的訊息不會丟失。
kafka集群輸出到elk集群，分析顯示搭建
zk 3個服務分別在三個主機上，kafka服務3個同上，elasticsearch服務3個同上，以上三個服務配置檔案在三颱機器上基本一樣，只需改一下ip等資訊。logstash乙個在131，kibana1個在131 zk配置 zoo.cfg zk bin zkserver.sh start tick...
kafka學習 四 kafka集群部署
1 broker.id 1 保證每個broker唯一，第一台可以不修改預設為0，後面兩台需要修改，如改為2和3 2 num.partitions 3 分割槽數量一般與broker保持一致 3 listeners plaintext 192.168 172 129 9092 修改為本機ip 4 zoo...
kafka 集群 測試
參考資料 wget 解壓tar xvzf kafka 2.11 0.10.0.1.tgz 移動mv kafka 2.11 0.10.0.1 usr local 修改配置 cd kafka 2.11 0.10.0.1 config mv server.properties server 1.prope...