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

1、前言

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

2、消息隊列：數據流的歸宿

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

消息隊列就是爲了應對大量數據須要傳遞、分析場景所涉及的。

目前消息隊列的方式分爲如下兩種：

• 點對點（point to point，queue）：消息被任一消費者消費後即消失在點對點系統中，消息被保留在隊列中，一個或多個消費者能夠消耗隊列中的消息，可是特定消息只能由最多一個消費者消費，一旦消費者讀取隊列中的消息，它就從該隊列中消失。
• 發佈-訂閱（publish/subscribe，topic）：消息可被全部訂閱者（組）消費在發佈-訂閱系統中，消息生產者稱爲發佈者，消息消費者稱爲訂閱者。發佈者發佈的消息被保留在 Topic 中，與點對點系統不一樣，消費組能夠訂閱一個或多個主題並使用該主題中的全部消息，一樣，全部發布到Topic的消息都可被全部訂閱組消費。一個訂閱組內可能包含多個訂閱者。

爲了更好的理解消息隊列的運做方式，咱們先設想以下一個場景：數據是一份快遞，數據在不一樣開發環節之間的流轉就是快遞的配送過程。

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

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

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

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

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

隨着網絡購物的不斷髮展，爲了提升效率，如今的貨物配送方式發生了極大的改變。如今快遞員從收發點揀貨出發，將快遞配送至相應地區的快遞站，由快遞站替實際用戶進行一次代理簽收，此時視做快遞配送的過程已經完成。快遞員就能夠快速回到揀貨點，後續快遞站會以各種形式通知到具體的用戶，有相應的快遞須要簽收，在「某某時間點」前來到快遞點拿取。對於用戶而言，它只須要持續關注快遞站的狀態（訂閱），當有快遞時，及時去取就能夠。

當咱們熟悉了快遞從倉庫中存儲到配送到收件人手中的流轉過程時，咱們就可以理解消息中間件是如何在實時開發的過程當中運做的。那麼在多種消息中間件中，目前應用最普遍的就屬Apache Kafka。

3、Kafka：消息中間件

Apache Kafka是一個分佈式、支持分區的（partition）、多副本的（replica），基於zookeeper協調的分佈式消息系統，用於實時處理大量數據，經常使用於大數據，數據挖掘等場景。

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

• Zookeeper：用於將獨立的Broker配置成Kafka集羣；
• Broker：Kafka集羣包含一個或多個服務器，這種服務器被稱爲Broker；
• Topic：Kafka中的消息主題，相似於Table的概念，用於區分不一樣消息；
• Partition：Topic分區，每一個topic能夠有多個分區，分區的做用是方便拓展，提升併發。

爲了便於理解，咱們能夠簡單的將Kafka與快遞過程進行類好比下：

一、數據寫入

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

二、消費方式及分配策略

實際消費數據時Kafka中的消費者——Consumer會以Consumer Group的形式與Topic交互並分配對應的Partition。在消費過程當中一個Group內的數據不重複，但多個Group之間的數據可重複消費，這也是發佈-訂閱制的特色。

開發人員能夠利用這一特色實如今不影響主業務流程的狀況下，對業務數據進行實時監控等。

一個Group中包含至少有一個Consumer，一個Topic下也至少包含一個Partiton。一個Consumer Group中的多個Consumer能夠並行消費不一樣的Partition，以此來提升對Kafka數據消費的並行度，從而提升數據處理的速度。可是在消費的過程當中，針對於Partition和Consumer數量的不一樣，會出現各類狀況，Kafka針對於不一樣的狀況有相應的分配策略，可參考以下：

4、實時開發如何使用Kafka

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

在實時採集任務過程當中，採集數據源的數據到Kafka，經過設置不一樣的寫入併發數，能夠設置多個Producer向同一個Topic下進行數據寫入，提升併發度和數據讀取效率；一樣，當採集Kafka數據源時，經過設置不一樣的讀取併發數，能夠在一個Group內設置多個Consumer同時對Topic內的數據進行消費。

在實時開發任務中，也能夠設置Kafka數據源的並行度，從而根據實際業務需求調整並行度來知足消費需求。

5、結語

經過今天的介紹，咱們瞭解到Kafka做爲典型「發佈-訂閱」形式的消息隊列如何經過幫助用戶臨時存儲流式數據，並經過Consumer Group和Partition的機制實現多併發的讀寫以提升實時開發相關的效率。後續咱們還會繼續介紹跟實時開發相關的內容，敬請期待。

數棧是雲原生—站式數據中臺PaaS，咱們在github和gitee上有一個有趣的開源項目：FlinkX，FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，也能夠採集實時變化的數據，是全域、異構、批流一體的數據同步引擎。你們喜歡的話請給咱們點個star！star！star！

github開源項目：https://github.com/DTStack/flinkx

gitee開源項目：https://gitee.com/dtstack_dev_0/flinkx