目錄
一、kafka是什麼
二、kafka的詳細架構圖
0. kafka的儲存結構和原理
1. producera
2. producerb
3. kafka分割槽的優勢
三、kafka依賴於zookeeper，體現在三個方面
kafka是乙個分布式的訊息佇列，類似於flume中的channel，用於資料的快取；
儲存資料框架，減緩大量流式資料儲存的壓力
傳送訊息者稱為producer，訊息接受者稱為consumer，consumer接收資料稱為對訊息的消費。
在hadoop的分層體系中，kafka橫跨傳輸層和儲存層，它既可以傳輸資料，又可以儲存資料。
broker：乙個kafka節點（一台物理機）就是乙個broker，乙個或多個broker組成乙個kafka集群；
topic：邏輯概念，kafka根據topic主題對訊息進行分類，發布到kafka集群的每條訊息都需要指定乙個topic；
partition：物理概念，乙個topic可以分成多個partition，且可分別存在於多個不同broker中，乙個partition就是乙個有序的訊息佇列，對應乙個物理的資料夾；
kafka會往zookeeper中傳送topics、partitions等元資料；consumer會往zookeeper或本地（0.9版本以後）儲存offset；
乙個broker可以有多個topic，乙個topic分為多個partition，同一topic下不同的partition儲存在不同的broker中，訊息資料依據topic進行歸類後，儲存在partition中。
eg：broker、topic和partition分別用b、t、p表示，儲存位置：（1）producer生產的資料，b1：儲存ta-p0、tb-p0、tc-p0
b2：儲存ta-p1、tb-p1、tc-p1
b3：儲存ta-p2、tb-p2、tc-p2
然後在b1、b2和b3中又分別備份ta~tb - p0~p2的備份，分別從中選舉出乙個leader，其餘為follower。
brokerid、topics、partitions這些元資料資訊儲存在zookeeper節點中；
生產出來的資料，按照broker的topic分類，存放在partition中；
而partition分割槽的資料，分為index和資料本身，兩者物理存放在logs目錄下，不同的topic-數字資料夾中；
（2）consumer消費的資料：0.9版本以後，儲存在本地的kafka/logs目錄下
offset偏移量，存放在logs目錄下，__consumer_offsets主題的分割槽資料夾中（預設50個分割槽）
offset是乙個long型別的整數。
ps：在0.9版本以前kafka的offset儲存在zookeeper上，0.9版本之後存在本地，避免了消費者頻繁與zookeeper進行互動，提高效率，消費者直接與本地的logs資料夾資料互動，速度得到提高。
原理：
（1）producer生產的資料，元資料存放在zookeeper中，資料存放在本地logs資料夾下，
consumer就從kafka/logs目錄下，按照topic和partition去相應的topic-數字（分割槽）資料夾下讀取資料，然後輸出。
ps：任意partition在某乙個時刻只能被乙個consumer group內的乙個consumer消費(反過來乙個consumer則可以同時消費多個partition)。
（2）conusmer讀取的資料，可以輸出到kafka封裝的控制台中，也可以輸出到spark、flume、hbase中。
（3）之所以有offset這個設定，因為kafka處理的是流式資料，
乙個狀態點產生的實時資料，被消費後，會在分割槽中產生乙個offset標記當前消費位置；
下乙個狀態點，又生成乙個新的訊息，consumer會從當前offset往後繼續消費新訊息，消費完後再產生乙個新的offset，
避免重複消費之前已經消費完的資料。
（4）消費完畢的資料，整體無序，分區內有序。
流程示意：
由於是流式資料，消費完當前實時資料產生乙個offset標記
offset存放在本地logs目錄下
producer生產流式資料 - >
kafka的broker中
- >
consumer從logs目錄下讀取資料
- > 輸出資料 - >
spark 、 flume 、hbase
按照topic歸類並分割槽，分割槽中存放資料，
分割槽物理存放在logs目錄下
（1）producera生產出訊息後，根據topic進行分類，儲存在broker1的topica中；
（2）此時若topic訊息太多，以至於broker1記憶體不夠裝不下，這樣kafka儲存能力受到broker1儲存能力的限制，為了解決這個問題，把同一topic分為多個儲存資料的partition（分割槽），
（3）這樣，同乙個topic、不同partation分布到多個broker中，實現同乙個topic資料的分布式儲存；
（4）為了資料安全，對broker1中的topica-partition0在broker2中進行備份，防止broker1掛掉後儲存在partition0中的資料丟失；
（5）同理，topica-partition1儲存在broker2中，在broker1中完成備份；
（6）kafka會在多份partition0和1的副本中選舉出乙個leader，進行讀寫資料操作；其餘的是follower，僅用於備份（這裡leader和follower的選舉是依託zookeeper的選舉機制實現的）；
（7）最後，consumera和consumerb邏輯組成乙個consumer group，去消費同乙個主題topica的資料，
consumera去消費topica-partition0的資料，
consumerb去消費topica-partition1的資料，
這樣消費同一主題不同分割槽的資料，就實現了併發，乙個consumer group可以看作乙個大的consumer，大大提高消費效率
ps：同乙個consumer group中不同consumer不能消費同乙個partition的資料，這樣會造成資料的重複消費，不合理。
ps：同乙個consumer group的不同consumer消費不同分割槽的資料，是併發的，
單個consumer消費不同分割槽，是消費完乙個分割槽的資料後，再消費下乙個分割槽的資料。
producerb生產出訊息後，全部放入broker3的乙個訊息佇列partition0中，只有乙個consumerc去獲取。
對比producera和producerb的生產—消費模式，可以看出kafka中對topic進行分割槽的優勢：
（1）擴充套件kafka儲存訊息的能力，避免乙個主題的訊息全部堆在同一臺物理機上；
（2）同乙個consumer group中的不同consumer能按照分割槽，去消費同乙個topic下不同partition的訊息，獲取資料效率更高，提高消費能力。
（1）broker依賴於zookeeper，每個broker的id和topic、partition這些元資料資訊都會寫入zookeeper的znode節點中；
（2）consumer依賴於zookeeper，consumer在消費訊息時，每消費完一條訊息，會將產生的offset儲存到zookeeper中，下次消費在當前offset往後繼續消費；
ps：kafka0.9之前consumer的offset儲存在zookeeper中，kafka0,9以後offset儲存在本地。
（3）partition依賴於zookeeper，partition完成replication備份後，選舉出乙個leader，這個是依託於zookeeper的選舉機制實現的；
所以，在啟動kafka之前，需要先啟動zookeeper。
Spark核心架構深度剖析
driver 就是我們用來提交編寫的spark程式的一台機器，在driver中最重要的一件事 建立sparkcontext sparkcontext 我們在建立sparkcontext的過程中,最重要的3件事，其一建立dagsechedule 有向無迴圈圖排程者 其二建立taskscheduler ...
Spark核心架構深度剖析
1，通過spark submit提交編寫好的spark程式，這時候spark會通過反射的方式，建立和構造乙個driveractor程序出來。3，應用程式每執行到乙個action就會建立乙個job，job會提交給dagscheduler，dagscheduler會通過stage劃分演算法 5，mast...
深入剖析MongoDB架構（資料儲存架構）
近日，軟體工程師ricky ho的在 他的部落格 裡發表了一篇關於mongodb架構 mongodb architecture 的博文，雖然這是乙個聽起來感覺很寬泛的話題，但是作者在文章中確實對mongodb由內至外的架構進行了剖析。本文擷取了其文章中的幾張重點架構示意圖進行簡要描述。1 mongo...