KAFKA官方教程筆記-introduction

介紹

 apache kafka是一個分佈式流式處理平臺，一個流式平臺該有的三個關鍵能力：

1. 發佈、訂閱流式數據。從這個角度講相似消息隊列或者企業消息系統；
2. 容錯的數據存儲機制；
3. 實時處理數據。

kafka的優勢:

1. 在系統、應用之間建立可靠的實時流式數據管道；
2. 建立實時流式數據處理應用。

爲了解kafka如何實現以上幾點，咱們深刻探討kafka能力。

首先是瞭解一些概念:

• kafka做爲集羣運行在一臺或者多臺服務器上
• kafka按分類存儲數據（被稱爲topic）
• 每條數據由key，value，時間戳組成.

一些術語

Broker
　　Kafka集羣包含一個或多個服務器，這種服務器被稱爲broker

• Topic
  　　每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲Topic。（物理上不一樣Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic便可生產或消費數據而沒必要關心數據存於何處）Topic在邏輯上能夠被認爲是一個queue，每條消費都必須指定它的Topic，能夠簡單理解爲必須指明把這條消息放進哪一個queue裏。爲了使得Kafka的吞吐率能夠線性提升，物理上把Topic分紅一個或多個Partition，每一個Partition在物理上對應一個文件夾，該文件夾下存儲這個Partition的全部消息和索引文件。
• Partition
  　　Parition是物理上的概念，每一個Topic包含一個或多個Partition.每一個Partition在物理上對應一個文件夾，該文件夾下存儲這個Partition的全部消息和索引文件。對於一個topic，3個分區，則同一組消費者數量應當<=3，不然有消費者接受不到數據；
• Producer
  　　負責發佈消息到Kafka broker
• Consumer
  　　消息消費者，向Kafka broker讀取消息的客戶端。
• Consumer Group
  　　每一個Consumer屬於一個特定的Consumer Group（可爲每一個Consumer指定group name，若不指定group name則屬於默認的group）。

kafka的四個核心api

• 生產者api
• 消費者api
• 流式處理api
• 鏈接api，將topic鏈接到現有的應用程序或數據系統。

 在kafka中連通服務器和客戶端使用的是簡單、高效、語言無關的tcp協議。目前的協議和舊版本協議兼容，咱們提供java等多語言客戶端。

Topics和Logs

 topic就是消息分類，一個topic能夠有0-n個消息訂閱者。

如圖，每一個分區是有序的數據接二連三的追加到日誌文件結構末尾。分區中的記錄被賦予一個分區內惟一的值，這個值被稱做offset。

在kafka集羣中保留全部發布的數據-不管是否被消費過-經過配置設置保留時間。好比，保留策略設置爲兩天，那麼等記錄分佈兩天內，這條數據是可消費的，以後數據將被刪除以用來釋放空間。kafka讀寫性能穩定和數據大小無關（這個是kafka牛逼的地方）。

實際上，消費者保留的惟一元數據就是offset，一般offset由0線性增加，可是實際上由於這個值是消費者可控的，因此能夠從0開始，也能夠從最新一條數據的offset開始。

分佈式

數據的分區被集羣分佈在kafka的多個服務器上，每一個服務器處理它分到的分區，並向共同的分區請求數據。分區數經過配置文件設置，每一個分區複製數據。（這就是所謂的容錯機制，和hadoop優勢像）

每一個分區中有個服務器做爲leader,其他0-n個服務器做爲followers。leader處理全部的讀寫請求，其他的follow被動的複製leader的數據。若是leader服務器掛了，followers 中的一臺服務器會被選舉成新leader。一臺服務器可能同時是一個分區的leader，另外一個分區的follower。這樣作到負載均衡，避免全部的請求都只讓一臺或少數幾臺服務器處理。

若是leader不掛，followers沒有存在的意義。但lead掛了時，咱們須要從followers節點中選出一個主。

note：一個topic能夠有多個複製版本（replication-factor 指定具體broker數目），一個broker多個分區（partitions  數目），broker之間數據應該是相同的，而同一個broker每一個分區數據應該是不同的

broker-0

broker-1

brokerid=2

------------------------------------------------------------------------------------

 

生產者

生產者向本身指定的topic寫數據，生產者的主要職責是選擇發佈到topic的哪一個分區。最簡單的方式從分區列表中輪流選擇。也能夠根據某種算法依照權重選擇分區。開發者負責如何選擇分區的算法。
消費者

消費者以組名被標記，若是全部消費者共有一個消費者組名，那麼記錄將在消費者中高效平衡的均勻發佈。若是全部消費者都使用不一樣的組名，那就是一個消息廣播。

2個kafka集羣託管4個分區（P0-P3），2個消費者組，消費組A有2個消費者實例，消費組B有4個。

正像傳統的消息系統同樣，Kafka保證消息的順序不變。 再詳細扯幾句。傳統的隊列模型保持消息，而且保證它們的前後順序不變。可是， 儘管服務器保證了消息的順序，消息仍是異步的發送給各個消費者，消費者收到消息的前後順序不能保證了。這也意味着並行消費將不能保證消息的前後順序。用過傳統的消息系統的同窗確定清楚，消息的順序處理很讓人頭痛。若是隻讓一個消費者處理消息，又違背了並行處理的初衷。 在這一點上Kafka作的更好，儘管並無徹底解決上述問題。 Kafka採用了一種分而治之的策略：分區。 由於Topic分區中消息只能由消費者組中的惟一一個消費者處理，因此消息確定是按照前後順序進行處理的。可是它也僅僅是保證Topic的一個分區順序處理，不能保證跨分區的消息前後處理順序。 因此，若是你想要順序的處理Topic的全部消息，那就只提供一個分區。

保證

消息的發送順序就是消息的保存順序，也就是消費者接收消息的順序。一個topic的 replication factor若是設置爲n，那麼即便n-1臺服務器掛了，數據也不會丟失。

• 以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間的訪問性能.一個持久化的隊列能夠構建在對一個文件的讀和追加上，就像通常狀況下的日誌解決方案。儘管和B樹相比，這種結構不能支持豐富的語義，可是它有一個優勢，全部的操做都是常數時間，而且讀寫之間不會相互阻塞。這種設計具備極大的性能優點：最終系統性能和數據大小徹底無關，服務器能夠充分利用廉價的硬盤來提供高效的消息服務。 
• 高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條消息的傳輸
• 支持Kafka Server間的消息分區，及分佈式消費，同時保證每一個partition內的消息順序傳輸
• 同時支持離線數據處理和實時數據處理

kefka能夠做爲消息系統，存儲系統，流式處理系統。也能夠把它們整合起來。