老大讓我用Kafka+Spark Streaming搭建簡單的資料處理平臺，以下記錄我在學習中的一些要點。目前我的整理基於Kafka 0.8.22 documentation的文件。

入門指南

overview

Kafka中有幾個概念很重要：partition、topic、producer、consumer。partition要深入瞭解，因為它和msg order guarantee， fault tolerace關係很大！

簡介

Kafka is a distributed, partitioned, replicated commit log service.像官方介紹的那樣，Kafka是分散式、分割槽、可複製的提交日誌服務。它採用獨特的設計來實現訊息服務系統。

回顧一些術語

• topics...maintains feeds of messages in categories（維護目錄中的訊息源）
• producers...釋出訊息到Kafkatopic的程式
• consumers...訂閱topic中訊息與處理源（feeds）中釋出過訊息的程式
• broker...執行一個或多個服務的Kafka叢集

概念圖見下：

clients與servers端使用TCP協議通訊

Topics&Logs

Topic是目錄或訂閱源的名字，用來接受釋出過的訊息。對於每個topic，Kafka維護一個分割槽日誌，看起來如下：

每個分割槽有序，不斷附加不可變的訊息，稱之為a commit log，每個分割槽中的訊息被分配連續的數字稱之為offset，每個分割槽中訊息的offset不同

Kafka叢集維護所有已經發布的訊息。當然我們可以配置時間來決定叢集維護訊息的時間長短。在可用時間內訊息都可以被消費者消費，超過這個時間訊息會被刪除來節省時間。Kafka's performance is effectively constant with respect to data size so retaining lots of data is not a problem：Kafka的效能是一個相對高效常亮，不管資料量多少，所以它維護大量的資料不是問題。

每個消費者維護一個後設資料：它指消費者讀取的訊息在日誌中的位置，即offset。它由consumer控制。隨著讀取訊息，offset會線性遞增。consumer可以按照任意順序消費訊息。** For example a consumer can reset to an older offset to reprocess.**

以上特性的組合使得consumer的代價很小。consumer數量可以增加或減少而對整個叢集影響很小。例如在不影響consumers和消費內容的情況下從topic尾部內容讀取訊息。

分割槽 && Distribution

partitions意義重大： - First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data. - Second they act as the unit of parallelism—more on that in a bit.

Each partition is replicated across a configurable number of servers for fault tolerance.每個分割槽（內容）都是課重複的，需要在承載分割槽的伺服器上配置。這是實現容錯的一種方案。

每個分割槽都有1個server作為leader，0/多個server作為followers leader處理分割槽的讀寫請求，followers服從leader，複製leader的操作。 若leader故障，自動選取followers為新的leader

Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.

Producer

選擇傳送什麼訊息給哪個topic的哪個分割槽。[從這個角度看producer角色也很厲害] This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the message). More on the use of partitioning in a second.

Consumers

傳統上有2中處理訊息的方法：佇列和釋出/訂閱機制。 - 佇列模式下，消費者池從一臺伺服器上讀取訊息，並且每條訊息只能傳送給消費者池中的一個消費者 - 釋出/訂閱模式下，訊息廣播到所有的消費者。

consumer group，給一組consumers打標籤，標籤名即組名

Consumers label themselves with a consumer group name, and each message published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

結合這張圖理解

大致意思是：每個傳送到topic的訊息都會被髮送給訂閱這個topic的consumer group中的一個consumer。consumer例項可以在不同的程式或機器中。

當所有consumers屬於一個group，這時的釋出/訂閱模式等同於佇列模式。

當所有的consumer都屬於不同的group時，這就是典型的釋出/訂閱模式，topic的訊息傳送給所有的consumer。

更一般的情況是每個topic有少量的groups，每個group都是topic的“邏輯訂閱者”。此時每個group有多個consumer實現擴充套件性和容錯。這裡訂閱者是sonsumer叢集而不是單個程式。這裡依然符合釋出/訂閱語義。

相比傳統的訊息系統，Kafka有健壯的順序保證。

Kafka提出了分割槽的設計，將不同topics下的不同分割槽的訊息分配給sonsumer group下的consumers，確保每個分割槽都能夠被唯一一個consumer按訊息傳送的順序處理訊息資料。根據情況設計多個分割槽實現負載均衡。note：consumer數量不能超過partition數量

Kafka只保證每個分割槽內的順序，不同的分割槽間無法保證訊息的順序性。如果你需要所有的訊息都按照順序，那麼只能設定一個分割槽，一個consumer例項。這時注意負載均衡和擴充套件性就無法保證了

guarantee

• order
  • 對於1個分割槽，早傳送到分割槽的offset<後傳送到分割槽的offset
  • 對於存放在log中的內容按照儲存的先後順序讀取
• 如果replication factor為N，最多允許N-1臺server故障

Use Cases（使用案例）

• Website Activity Tracking（網站活動跟蹤）
• Metrics
• Log Aggregation（日誌聚合）
• Stream Processing

原文連線