訊息傳送時都被傳送到乙個topic，其本質就是乙個目錄，而topic是由一些partition logs(分割槽日誌)組成，其組織結構如下圖所示：
我們可以看到，每個partition中的訊息都是有序的，生產的訊息被不斷追加到partition log上，其中的每乙個訊息都被賦予了乙個唯一的offset值。
1）分割槽的原因
（1）方便在集群中擴充套件，每個partition可以通過調整以適應它所在的機器，而乙個topic又可以有多個partition組成，因此整個集群就可以適應任意大小的資料了；
（2）可以提高併發，因為可以以partition為單位讀寫了。
2）分割槽的原則
（1）指定了patition，則直接使用；
（2）未指定patition但指定key，通過對key的value進行hash出乙個patition
（3）patition和key都未指定，使用輪詢選出乙個patition。
同乙個partition可能會有多個replication（對應 server.properties 配置中的 default.replication.factor=n）。
沒有replication的情況下，一旦broker 宕機，其上所有 patition 的資料都不可被消費，同時producer也不能再將資料存於其上的patition。
引入replication之後，同乙個partition可能會有多個replication，而這時需要在這些replication之間選出乙個leader，producer和consumer只與這個leader互動，其它replication作為follower從leader 中複製資料。
1）producer先從zookeeper的 "/brokers/.../state"節點找到該partition的leader
2）producer將訊息傳送給該leader
3）leader將訊息寫入本地log
4）followers從leader pull訊息，寫入本地log後向leader傳送ack
5）leader收到所有isr中的replication的ack後，增加hw（high watermark，最後commit 的offset）並向producer傳送ack
物理上把topic分成乙個或多個patition（對應 server.properties 中的num.partitions=3配置），每個patition物理上對應乙個資料夾（該資料夾儲存該patition的所有訊息和索引檔案），如下：
[test@ip101 logs]$ ll
drwxrwxr-x. 2 test test 4096 8月 6 14:37 first-0
drwxrwxr-x. 2 test test 4096 8月 6 14:35 first-1
drwxrwxr-x. 2 test test 4096 8月 6 14:37 first-2
[test@ip101 logs]$ cd first-0
[test@ip101 first-0]$ ll
-rw-rw-r--. 1 test test 10485760 8月 6 14:33 00000000000000000000.index
-rw-rw-r--. 1 test test 219 8月 6 15:07 00000000000000000000.log
-rw-rw-r--. 1 test test 10485756 8月 6 14:33 00000000000000000000.timeindex
-rw-rw-r--. 1 test test 8 8月 6 14:37 leader-epoch-checkpoint
無論訊息是否被消費，kafka都會保留所有訊息。
高階api
1）高階api優點
高階api 寫起來簡單
不需要自行去管理offset，系統通過zookeeper自行管理。
不需要管理分割槽，副本等情況，.系統自動管理。
消費者斷線會自動根據上一次記錄在zookeeper中的offset去接著獲取資料（預設設定1分鐘更新一下zookeeper中存的offset）
可以使用group來區分對同乙個topic 的不同程式訪問分離開來（不同的group記錄不同的offset，這樣不同程式讀取同乙個topic才不會因為offset互相影響）
2）高階api缺點
不能自行控制offset（對於某些特殊需求來說）
不能細化控制如分割槽、副本、zk等
低階api
1）低階 api 優點
能夠讓開發者自己控制offset，想從**讀取就從**讀取。
自行控制連線分割槽，對分割槽自定義進行負載均衡
對zookeeper的依賴性降低（如：offset不一定非要靠zk儲存，自行儲存offset即可，比如存在檔案或者記憶體中）
2）低階api缺點
太過複雜，需要自行控制offset，連線哪個分割槽，找到分割槽leader 等。
消費者是以consumer group消費者組的方式工作，由乙個或者多個消費者組成乙個組，共同消費乙個topic。
每個分割槽在同一時間只能由group中的乙個消費者讀取，但是多個group可以同時消費這個partition。
在圖中，有乙個由三個消費者組成的group，有乙個消費者讀取主題中的兩個分割槽，另外兩個分別讀取乙個分割槽。
某個消費者讀取某個分割槽，也可以叫做某個消費者是某個分割槽的擁有者。
在這種情況下，消費者可以通過水平擴充套件的方式同時讀取大量的訊息。
另外，如果乙個消費者失敗了，那麼其他的group成員會自動負載均衡讀取之前失敗的消費者讀取的分割槽。
consumer採用pull（拉）模式從broker中讀取資料。
push（推）模式很難適應消費速率不同的消費者，因為訊息傳送速率是由broker決定的。
它的目標是盡可能以最快速度傳遞訊息，但是這樣很容易造成consumer來不及處理訊息，典型的表現就是拒絕服務以及網路擁塞。
而pull模式則可以根據consumer的消費能力以適當的速率消費訊息。
對於kafka而言，pull模式更合適，它可簡化broker的設計，consumer可自主控制消費訊息的速率，同時consumer可以自己控制消費方式——即可批量消費也可逐條消費，同時還能選擇不同的提交方式從而實現不同的傳輸語義。
pull模式不足之處是，如果kafka沒有資料，消費者可能會陷入迴圈中，一直等待資料到達。
為了避免這種情況，我們在我們的拉請求中有引數，允許消費者請求在等待資料到達的「長輪詢」中進行阻塞（並且可選地等待到給定的位元組數，以確保大的傳輸大小）。
hello world（4）檢視ip101和ip102的接收者。
同一時刻只有乙個消費者接收到訊息。
Kafka 生產過程分析
傳送訊息的主要步驟 我們從建立乙個 producerrecord 物件開始，producerrecord 物件需要包含目標主題和要傳送的內容。我們還可以指定鍵或分割槽。在傳送 producerrecord 物件時，生產者要先把鍵和值物件序列化成位元組陣列，這樣它們才能夠在網路上傳輸。然後資料被傳給分...
Kafka生產過程
1.寫入方式 寫磁碟效率比隨機寫記憶體要高，保障kafka吞吐率 2.分割槽 partition kafka集群有多個訊息 伺服器 broker server 組成，發布到kafka集群的每條訊息都有乙個類別，用主題 topic 來表示。通常，不同應用產生不同型別的資料，可以設定不同的主題。乙個主題...
火力電廠生產過程
發電廠是把各種動力能源的能量轉變成電能的工廠。根據所利用的能源形式可分為火力發電廠 水利發電廠 原子能發電廠 地熱發電廠 風力發電廠等。火力發電廠簡稱火電廠，是利用煤 石油 天然氣等燃料的化學能產生出電能的工廠。按其功用可分為兩類，即凝汽式電廠和熱電廠。前者僅向使用者 電能，而熱電廠除供給使用者電量...