Kafka文檔閱讀筆記（一）

老大讓我用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

原文鏈接