Kafka各組件
Broker(一個kafka節點)
每個kafka節點稱爲一個Broker，一個服務器上可以部署一個或者多個kafka的節點（示例圖中只部署了一個），然後這些節點連接到註冊中心上，就形成了一個kafka的集羣。
Topic
即主題，在kafka中消息是分類型的，比如用戶行爲日誌類型，支付訂單類型，結算數據類型等，不同類別的消息在生產的時候可以指定發送到不同的Topic裏。
一個Broker上可以創建一個或者多個Topic。同一個topic可以在同一集羣下的多個Broker中分佈。
Partition
每個Topic分爲一個或多個Partition，每個分區會映射到一個邏輯的日誌（log）文件，是kafka中真正存儲消息的單元。
每當一個message被髮布到一個topic上的一個partition，broker應會將該message追加到這個邏輯log文件的最後一個segment上。這些segments 會被flush到磁盤上。Flush時可以按照時間來進行，也可以按照message 數來執行。
每個partition都是一個有序的、不可變的結構化的提交日誌記錄的序列。在每個partition中每一條日誌記錄都會被分配一個序號——通常稱爲offset，offset在partition內是唯一的。論點邏輯文件會被化分爲多個文件segment（每個segment的大小一樣的）。
也就是說在kafka中雖然消息是無序的，但是發送到同一個partition上的消息是有序的。
看到這裏，你可能會以爲服務器1上的topic2和服務器2上的topic2和服務器3上的topic2包含的Partition是一樣的，但其實並不如此。
假設一個topic分爲4個Partition，**kafka內部會根據一定的算法把這4個Partition儘可能均勻分佈到不同的服務器上。同一個Partition會分配到同一個topic所在的多個服務器上。這樣做是爲了容災。具體會複製幾份，會複製到哪些broker上，都是可以配置的。**比如：
服務器1負責topic2的Partition1、Partition2，Partition4
服務器2負責topic2的Partition1、Partition3，Partition4
服務器3負責topic2的Partition2、Partition3
爲了方便，我在每個broker中只畫了一個topic。
那麼對於每一個Partition實際上都有2個備份。
Kafka的架構優點
看了上面，相信你已經對kafka的架構有所瞭解了，其實這種奇妙的架構，筆者也是第一次遇見。那麼爲什麼稱爲奇妙，而不叫奇怪呢？是因爲這種架構是有很大的優點的。kafka是不支持讀寫分離的，也就是說，不管是寫還是讀，都是發送到主節點。只不過在kafka中的主節點，並不是我們傳統意義上的實體服務器，而是一個Partition。前面講過了，生產者生產數據和消費者接收數據，實際上都是和topic裏面的Partition打交道。
我們假設上圖中標紅的Partition爲主節點，那麼這個時候生產者生產數據和消費者消費數據是怎樣的流程圖呢？
在kafka中，生產者生產的數據會採用一定的算法分配到不同的Partition上，當數據量足夠大的時候，每個Partition的負載壓力是差不多的，對於上圖，可能服務器2的負載壓力會大一點，那是因爲 我懶的畫圖 有兩個主節點在在這臺服務器上，在實際環境中，我們可以儘可能的均勻分配主節點，這樣每一臺服務器的壓力就差不多了。
總結
可以看出kafka的奇妙架構以及這種架構帶來的優勢，當然在某些情況下可能會帶來負載不均衡，但我們也可以通過調整來避免這些情況，詳細可以看這篇文章
總的來說，Kafka 只支持主寫主讀有幾個優點：
可以簡化代碼的實現邏輯，減少出錯的可能;將負載粒度細化均攤，與主寫從讀相比，不僅負載效能更好，而且對用戶可控;沒有延時的影響；
在副本穩定的情況下，不會出現數據不一致的情況。爲此，Kafka 又何必再去實現對它而言毫無收益的主寫從讀的功能呢？這一切都得益於 Kafka 優秀的架構設計，從某種意義上來說，主寫從讀是由於設計上的缺陷而形成的權宜之計。