數棧產品分享：Kafka—實時離不開的那個TA

一、 前言

隨著技術不斷的成熟及市場需求的日益旺盛，實時開發已經成為當前大資料開發不可或缺的一部分。在整個實時開發的鏈路中，資料採集需要寫入到Kafka，資料處理也需要使用到Kafka。今天我們就針對Kafka這個時下主流的訊息中介軟體進行簡單的介紹。

二、訊息佇列：資料流的歸宿

在實時開發的場景中，來源於各類行為、事件的資料是隨著發生時間源源不斷如同河流一般進入實時任務並不斷產出結果的。傳統的異構資料來源，資料以結構化的形式儲存在對應的庫表內。那麼除了資料本身包含的業務時間屬性，要如何找到一個穩定的時間維度來描述這些資料的先後呢？又要將流式的資料放在哪裡去進行處理？

訊息佇列就是為了應對大量資料需要傳遞、分析場景所涉及的。

目前訊息佇列的方式分為以下兩種：

• 點對點（point to point，queue）：訊息被任一消費者消費後即消失在點對點系統中，訊息被保留在佇列中，一個或多個消費者可以消耗佇列中的訊息，但是特定訊息只能由最多一個消費者消費，一旦消費者讀取佇列中的訊息，它就從該佇列中消失。
• 釋出-訂閱（publish/subscribe，topic）：訊息可被所有訂閱者（組）消費在釋出-訂閱系統中，訊息生產者稱為釋出者，訊息消費者稱為訂閱者。釋出者釋出的訊息被保留在 Topic 中，與點對點系統不同，消費組可以訂閱一個或多個主題並使用該主題中的所有訊息，同樣，所有釋出到Topic的訊息均可被所有訂閱組消費。一個訂閱組內可能包含多個訂閱者。

為了更好的理解訊息佇列的運作方式，我們先設想如下一個場景：資料是一份快遞，資料在不同開發環節之間的流轉就是快遞的配送過程。

1、電視購物：上門配送，客戶簽收

在10年前電視購物還比較盛行的時代，多數貨物是透過郵政等快遞公司進行上門配送，往往快遞員上門後，會讓客戶在運單上簽字驗收。這時候的快遞員，只有每一份快遞被客戶簽字驗收後，才會再開始下一件貨品的運輸（此為極端情況下的舉例）。

當一個客戶存在多個快遞，並且多個快遞是陸續到達的時候，就會出現快遞員配送-等待簽收-客戶簽收-快遞員回到收發點發現新的快遞-快遞員配送這樣一個反覆鏈路，如果存在客戶反應慢，簽字速度慢的情況，則會花費更多時間。

同樣，在傳統的資料開發場景中，資料傳輸也遵循這樣的規律。上下游的兩個服務之間對資料進行傳輸等同於快遞配送的過程，如果一次資料傳輸需要等到下游服務給到的回執來保證資料正常寫入，再開始下一次的進行，那麼下游服務處理速度及響應速度會嚴重影響這一環節的資料從而導致資料延遲；如果整條資料傳輸的鏈路包含了多個這樣的程式，整體資料的時效性就無法得到保證。

2、快遞物流：統一快遞站

隨著網路購物的不斷髮展，為了提高效率，現在的貨物配送方式發生了極大的改變。現在快遞員從收發點揀貨出發，將快遞配送至相應地區的快遞站，由快遞站替實際使用者進行一次代理簽收，此時視作快遞配送的過程已經完成。快遞員就可以快速回到揀貨點，後續快遞站會以各類形式通知到具體的使用者，有相應的快遞需要簽收，在“某某時間點”前來到快遞點拿取。對於使用者而言，它只需要持續關注快遞站的狀態（訂閱），當有快遞時，及時去取就可以。

當我們熟悉了快遞從倉庫中儲存到配送到收件人手中的流轉過程時，我們就能夠理解訊息中介軟體是如何在實時開發的過程中運作的。那麼在多種訊息中介軟體中，目前應用最廣泛的就屬Apache Kafka。

三、Kafka：訊息中介軟體

Apache Kafka是一個分散式、支援分割槽的（partition）、多副本的（replica），基於zookeeper協調的分散式訊息系統，用於實時處理大量資料，常用於大資料，資料探勘等場景。

Kafka中經常會涉及到如下基本概念：

• Zookeeper：用於將獨立的Broker配置成Kafka叢集；
• Broker：Kafka叢集包含一個或多個伺服器，這種伺服器被稱為Broker；
• Topic：Kafka中的訊息主題，類似於Table的概念，用於區分不同訊息；
• Partition：Topic分割槽，每個topic可以有多個分割槽，分割槽的作用是方便擴充，提高併發。

為了便於理解，我們可以簡單的將Kafka與快遞過程進行類比如下：

1、資料寫入

1）確定Topic及Partition

一個Topic下可能存在多個Partition，在向Kafka寫入資料時需要先確定Topic及對應的Partition。

2）找到Partition通訊地址

由於Kafka實現了高可用，確定寫入Partition後，Producer會從ZK中獲取到對應Partition的Leader並與其通訊。

3）資料傳輸

• Leader接收到Producer的資訊並寫入本地Log
• 其他Follower從Leader Pull資訊，並寫入本地log，完成後向Leader傳送ACK
• Leader接收到所有Follower資訊，並設定一個HW（High Watermark），然後向Producer傳送ACK

2、消費方式及分配策略

實際消費資料時Kafka中的消費者——Consumer會以Consumer Group的形式與Topic互動並分配對應的Partition。在消費過程中一個Group內的資料不重複，但多個Group之間的資料可重複消費，這也是釋出-訂閱制的特點。

開發人員可以利用這一特點實現在不影響主業務流程的情況下，對業務資料進行實時監控等。

一個Group中包含至少有一個Consumer，一個Topic下也至少包含一個Partiton。一個Consumer Group中的多個Consumer可以並行消費不同的Partition，以此來提高對Kafka資料消費的並行度，從而提高資料處理的速度。但是在消費的過程中，針對於Partition和Consumer數量的不同，會出現各種情況，Kafka針對於不同的情況有相應的分配策略，可參考如下：

四、實時開發如何使用Kafka

在實際生產中，實時開發也是以一個消費者組或生產者組的方式去Kafka中消費相應的資料。

在實時採集任務過程中，採集資料來源的資料到Kafka，透過設定不同的寫入併發數，可以設定多個Producer向同一個Topic下進行資料寫入，提高併發度和資料讀取效率；同樣，當採集Kafka資料來源時，透過設定不同的讀取併發數，可以在一個Group內設定多個Consumer同時對Topic內的資料進行消費。

在實時開發任務中，也可以設定Kafka資料來源的並行度，從而根據實際業務需求調整並行度來滿足消費需求。

五、結語

透過今天的介紹，我們瞭解到Kafka作為典型“釋出-訂閱”形式的訊息佇列如何透過幫助使用者臨時儲存流式資料，並透過Consumer Group和Partition的機制實現多併發的讀寫以提高實時開發相關的效率。後續我們還會繼續介紹跟實時開發相關的內容，敬請期待。