一、Kafka存在哪些方面的優勢

1. 多生產者

可以無縫地支持多個生產者，不管客戶端在使用單個主題還是多個主題。

2. 多消費者

支持多個消費者從一個單獨的消息流上讀取數據，而且消費者之間互不影響。

3. 基於磁碟的數據存儲

支持消費者非實時地讀取消息，由於消息被提交到磁碟，根據設置的規則進行保存。當消費者發生異常時候，意外離線，由於有持久化的數據保證，可以實現聯機後從上次中斷的地方繼續處理消息。

4. 伸縮性

用戶在開發階段可以先試用單個broker，再擴展到包含3個broker的小型開發集群，然後隨著數據量不斷增長，部署到生產環境的集群可能包含上百個broker。

5. 高性能

Kafka可以輕鬆處理巨大的消息流，在處理大量數據的同事，它還能保證亞秒級的消息延遲。

二、Kafka常見的使用場景

1. 消息

kafka更好的替換傳統的消息系統，消息系統被用於各種場景（解耦數據生產者，緩存未處理的消息等），與大多數消息系統比較，kafka有更好的吞吐量，內置分區，副本和故障轉移，這有利於處理大規模的消息。

根據我們的經驗，消息往往用於較低的吞吐量，但需要低的端到端延遲，並需要提供強大的耐用性的保證。

在這一領域的kafka比得上傳統的消息系統，如ActiveMQ或RabbitMQ等。

2. 網站活動追蹤

kafka原本的使用場景是用戶的活動追蹤，網站的活動（網頁游覽，搜索或其他用戶的操作信息）發佈到不同的話題中心，這些消息可實時處理，實時監測，也可載入到Hadoop或離線處理數據倉庫。

3. 指標

kafka也常常用於監測數據。分散式應用程式生成的統計數據集中聚合。

4. 日誌聚合

許多人使用Kafka作為日誌聚合解決方案的替代品。日誌聚合通常從伺服器中收集物理日誌文件，並將它們放在中央位置（可能是文件伺服器或HDFS）進行處理。Kafka抽象出文件的細節，並將日誌或事件數據更清晰地抽象為消息流。這允許更低延遲的處理並更容易支持多個數據源和分散式數據消費。

5. 流處理

kafka中消息處理一般包含多個階段。其中原始輸入數據是從kafka主題消費的，然後彙總，豐富，或者以其他的方式處理轉化為新主題，例如，一個推薦新聞文章，文章內容可能從“articles”主題獲取；然後進一步處理內容，得到一個處理後的新內容，最後推薦給用戶。這種處理是基於單個主題的實時數據流。從0.10.0.0開始，輕量，但功能強大的流處理，就可以這樣進行數據處理了。

除了Kafka Streams，還有Apache Storm和Apache Samza可選擇。

6. 事件採集

事件採集是一種應用程式的設計風格，其中狀態的變化根據時間的順序記錄下來，kafka支持這種非常大的存儲日誌數據的場景。

7. 提交日誌

kafka可以作為一種分散式的外部日誌，可幫助節點之間複製數據，並作為失敗的節點來恢複數據重新同步，kafka的日誌壓縮功能很好的支持這種用法，這種用法類似於Apacha BookKeeper項目。

三、Kafka架構深度剖析

1. Kafka數據處理步驟

1.1 Producer產生消息，發送到Broker中

1.2 Leader狀態的Broker接收消息，寫入到相應topic中

1.3 Leader狀態的Broker接收完畢以後，傳給Follow狀態的Broker作為副本備份

1.4 Consumer消費Broker中的消息

2. Kafka 核心組件

2.1 Producer：消息生產者，產生的消息將會被髮送到某個topic

2.2 Consumer：消息消費者，消費的消息內容來自某個topic

2.3 Topic：消息根據topic進行歸類，topic其本質是一個目錄，即將同一主題消息歸類到同一個目錄

2.4 Broker：每一個kafka實例（或者說每台kafka伺服器節點）就是一個broker，一個broker可以有多個topic

2.5 Zookeeper： Zookeeper集群不屬於kafka內的組件，但kafka依賴 Zookeeper集群保存meta信息，所以在此做聲明其重要性。

3. broker和集群

一個獨立的Kafka伺服器稱為broker，broker接收來自生產者的消息，為消息設置偏移量，並提交消息到磁碟保存。broker為消費者提供服務，對讀取分區的請求作出響應，返回已經提交到磁碟上的消息。根據特定的硬體及其性能特征，單個broker可以輕鬆處理數千個分區以及每秒百萬級的消息量。

broker是集群的組成部分。每個集群都有一個broker同時充當了集群控制器的角色（自動從集群的活躍成員中選舉出來）。控制器負責管理工作，包括將分區分配給broker和監控broker。在集群中，一個分區從屬於一個broker，該broker被稱為分區的首領。一個分區可以分配多個broker，這個時候會發生分區複製。這種複製機製為分區提供了消息冗餘，如果一個broker失效，其他broker可以接管領導權。不過，相關的消費者和生產者都要重新連接到新的首領。

4. Consumer與topic關係

kafka只支持Topic

• 每個group中可以有多個consumer，每個consumer屬於一個consumer group；通常情況下，一個group中會包含多個consumer，這樣不僅可以提高topic中消息的併發消費能力，而且還能提高”故障容錯”性，如果group中的某個consumer失效那麼其消費的partitions將會由其它consumer自動接管。

• 對於Topic中的一條特定的消息，只會被訂閱此Topic的每個group中的其中一個consumer消費，此消息不會發送給一個group的多個consumer；那麼一個group中所有的consumer將會交錯的消費整個Topic，每個group中consumer消息消費互相獨立，我們可以認為一個group是一個”訂閱”者。

• 在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻)；
一個Topic中的每個partions，只會被一個”訂閱者”中的一個consumer消費，不過一個consumer可以同時消費多個partitions中的消息。

• kafka的設計原理決定,對於一個topic，同一個group中不能有多於partitions個數的consumer同時消費，否則將意味著某些consumer將無法得到消息，而處於空閑狀態。

kafka只能保證一個partition中的消息被某個consumer消費時是順序的；事實上，從Topic角度來說,當有多個partitions時,****消息仍不是全局有序的。

5. Kafka消息的分發

• Producer客戶端負責消息的分發

• kafka集群中的任何一個broker都可以向producer提供metadata信息,這些metadata中包含”集群中存活的servers列表”、“partitions leader**列表”等信息；

• 當producer獲取到metadata信息之後, producer將會和Topic下所有partition leader保持socket連接；

• 消息由producer直接通過socket發送到broker，中間不會經過任何”路由層”。事實上，消息被路由到哪個partition上由producer客戶端決定，比如可以採用”random””key-hash””輪詢”等。

• 如果一個topic中有多個partitions,那麼在producer端實現”消息均衡分發”**是必要的。

• 在producer端的配置文件中,開發者可以指定partition路由的方式。

• Producer消息發送的應答機制

設置發送數據是否需要服務端的反饋,有三個值0,1,-1

0: producer不會等待broker發送ack

1: 當leader接收到消息之後發送ack

2: 當所有的follower都同步消息成功後發送ack

request.required.acks=0

6. Consumer的負載均衡

當一個group中,有consumer加入或者離開時,會觸發partitions均衡.均衡的最終目的,是提升topic的併發消費能力，步驟如下：

1. 假如topic1,具有如下partitions: P0,P1,P2,P3

2. 加入group A 中,有如下consumer: C0,C1

3. 首先根據partition索引號對partitions排序: P0,P1,P2,P3

4. 根據consumer.id排序: C0,C1

5. 計算倍數: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)

6. 然後依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]
   

本文由傳智教育博學谷教研團隊發佈。

如果本文對您有幫助，歡迎關註和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力。

轉載請註明出處！