Kafka是由Apache軟件基金會開發的一個開源流處理平臺，是一種高吞吐量的分佈式發佈訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。這種動作已經成為現代網絡上的許多社會功能的一個關鍵因素。為了讓大家進一步瞭解kafka,飛馬網於5月29日晚，邀請到遊戲公司資深大數據SRE工程師，數據中心基礎服務負責人劉鎮硯老師為大家分享該領域的內容。
以下是這次線上直播的分享實錄：
今天分享的主要分為四個內容：第一部分是kafka基礎，包括為什麼需要分佈式消息隊列系統，kafka相關概念與基礎原理；第二部分主要是程序常用的設計方法，一些需要注意的地方；第三部分介紹典型的應用場景，方便大家以後上線業務的時候作為參考；第四部分是總結。
一、Kafka基礎
在介紹Kafka基礎之前，先介紹一些經常遇到的業務場景，比如說線上有許多生產服務器，這些服務器都運行著不一樣的服務，如web系統，還有各種管理的平臺，還有APP的系統，如何對每個服務產生的大量日誌和消息進行處理和分析是值得考慮的問題。
首先，可以看一下傳統的處理方法，如圖，線上有許多業務的前端，都需要將業務產生的線上日誌和消息分到後端的業務分析平臺，比如說web系統的負責人，他實現了多套系統的的技術方案，然後把數據分別傳送到Hadoop集群還有監控系統等等。一個APP系統，它需要走同樣的流程，就能發現我們的產品一直在做實現分析對接這樣的一個事情，帶來的問題也很明顯，比如說我們的數據流程太過複雜，對於產品部門來說，他們重複實現數據的一個收集還要考慮框架的一系列複雜的場景。而且這個複雜的場景完全是用於給用戶老實現，所以這個用戶體驗就比較差。
基於上述，我們就可以得出我們需要引入一個消息的中間件，對於這個中間件而已，他屏蔽了用戶與客戶端分析平臺的直接交互，對於用戶來說，他們只要考慮如何將這個數據分發到這個數據中間件就可以了，後面的操作我們會統一在後面的環節來進行處理。
回到剛才的問題，我們為何要引入消息隊列。我們就要看下它給我們帶來的一些好處：
1、解耦：需求是變化的，比如說，我們會有不同的產品都需要接入分析平臺，另一個就是說我們分析平臺自身也需要不斷就調整我們的技術框架。
1、冗餘：在我們線上的生產環境當中，機器故障幾乎是不可避免的，如何去避免數據丟失是我們主要考慮的一個方向。
2、擴展性：消息解耦擴大了我們，所以我們增大消息入隊速度和處理頻率都是非常容易去實現的，增加額外的處理過程就可以，不需要改變代碼。
3、靈活性與峰值處理能力：消息隊列是一個分佈式的架構，比較容易橫向擴展
，滿足業務的線上的一個壓力。
如果把我們的消息隊列換成我們的Kafka組件，那對於我們的整個系統來說，進入kafka頁面，我們的業務前端是可以多種多樣的，比如說一個web系統或者是遊戲的一個服務器或者是一個管理平臺的後端，同樣的在kafak以後，我們後端的一個組件也要比較靈活，比如我們的監控平臺、APP系統等。
Kafka介紹：
首先，kafka是一個Linkedln開源的分佈式發佈-訂閱消息系統，數據發佈到kafka的集群當中，用戶可以集群的訂閱這些消息並及時處理，kafka有以下的特點：
1、高吞吐率，低延遲：可以每秒處理幾十萬條消息，但延遲最低幾毫秒
2、可擴展性：支持動態擴展節點
3、持久性與可靠性：數據被持久化到磁盤上，並且能支持多個副本並防止數據丟失。
4、高容錯：某些節點失敗後不會影響整個執行，允許節點失敗
5、高併發：支持上千個客戶端同時讀寫
Kafak架構圖
1、生產者producer:
生產者可以向broker發送消息，然後一般會批量發送多條消息，另外它會通過一個任意一個broker去發現其他broker的位置信息。比如說對應的topic和所在的partition。消息組成的話，會有以下幾個部分，第一個是topic，每條發送到kafka集群的消息都是有一個類別的，這個類別就被稱之為topic，物理上這個topic 的消息分開存儲，存在一個或者多個broker，但用戶只需指定消費，而不需要關注數據儲存在何處;第二是key，在發送一條消息的時候，我們會指定key,根據這個key，也就是partition來將這條消息發送到哪條partition；第三個部分是value，是我們發送信息的一個主體；最後是timestamp的一個參數，它允許producer去指定時間，如果不指定的話就默認當前時間。
2、節點broker:
是producer和consumer的一箇中間橋樑，從producer端去接收消息並保存下來，並且把消息發送給訂閱的consumer，另外的話，他可以將消息可靠的緩存一段時間，比如說我們每個消息都可以保存為多個副本，默認是3個，另外我們可以設置保存時間，比如一週，一週過後，這個數據就會從本地磁盤上面刪除。
然後看producer是如何生產數據到broker上的，首先producer調用了一個線的方法，並且指定了topic、value的參數，然後經過partition的一個處理，然後確定把數據寫到對應的kafka集群的partition之中，然後數據是按順序的方式寫入的。
Partition和topic的關係：topic在邏輯上就可以認為是一個cue,每條消費都必須指定它的topic，簡單理解為我們必須指定把這條消息放到哪個cue裡面，而partition則是物理上的概念，每個topic包含一條或者多條partition，為了將kafka的吞吐量可以先行的提高，物理上可能把topic分成一個活多個partition，每個partition在物理上對應一個文件夾，然後該文件夾為存儲該partition的所有消息與所應文件。Partition是橫向擴展和一切並行化的基礎，每個topic至少被切成一個partition，消息在partition中是有編號的，稱為offset，kafka以partition為單位對消息進行備份，每個partition可以至少有一個replic（副本）。
3、消費者consumer：
它的基本職責就是用戶應用程序，負責從kafka中讀取數據，並進行處理，另外它有一個重要的概念，就是consumer group，多個consumer可以組成一個邏輯group，然後同時去讀取某個topic，然後每個consumer都可以讀取一個或多個partition。對於同一個topic來說，我們可以取多個consumer group分別去訂閱他的消息，用於不同的作用。還有一個概念就是consumer position，每個consumer可以自己維護讀取的位置offset，一旦掛掉後，重啟後可繼續讀取，
4、協調組件zookeeper
接下來介紹kafka的其他一些特點：
服務保證的特性：
順序保證（同一個producer發送到某個topic的同一個partition中的消息是順序的，consumer按照消息在日誌中的寫入順序讀取消息）順序寫順序讀
Producer產生的數據由consumer消費
容錯性：我們的數據是有副本的話，那我們能永遠n-1臺機器宕掉後不會導致數據丟失，因為我們還有最後的一個數據節點來保證數據的可用性
Kafka應用場景：
監控場景，監控message的變化指標
消息隊列，用於我們消息的一個緩存
用戶活動追蹤
流處理
日誌聚合
二、kafka程序設計
kafaka程序設計方法：
內核實現語言是Scala，推薦程序設計語言是Java，當然其他語言也是可以的，比如c/c++，php，python等，但是遇到一些比較高級的功能的時候，比如我們的kafka集群是經過Kerberos認證的，數據要基於壓縮格式，那麼對應的支持可能沒有那麼完善。
程序設計流程
1.kafak在整個數據流中的角色
2.producer設計（考慮partition、數據格式等）
考慮點：基本需求（有哪些topic、如何對消息進行分區、消息數據格式-字符串，json，protobuf）
具體實現：（同步或是異步、是否是批發送、單線程還是多線程）
案例：
初始化配置對象，創建producer；
創建消息併發送，默認是異步發送；同步發送比較少用，效率低
重要參數：
Bootstrap.servers（用作初始化broker列表，指定一個或多個，多個需分割）
Key和value序列化器
Acks
Buffer.memory（存滿自動發送到broker）
Compression.type（指定數據壓縮方式，默認不壓縮，如果選擇壓縮，除了可以節省broker節點存儲外還可以節省數據的傳輸的網絡帶寬，但是代價是額外消耗CPU）
Max.request.size/batch.size（指定batch數據量大小）
Client.id(唯一標示，默認為空)
Partitioner.class（默認是輪詢的方式）
3.consumer設計（取決於應用需求）
考慮點：
基本需求（需要處理哪個topic中的數據，如何處理這些topic）
具體實現（是否啟動多個consumer，形成一個group；是否是批處理；單線程還是多線程）
程序示例
初始化並創建kafka consumer
讀取數據
重要參數
Bootstrap（引導程序）.servers（初始化broker自動列表）
Key.deserializer(並行器)/value.deserializer（反序列化器）
Fetch.min.bytes（每次請求至少返回的數據大小，默認1k）
Group.id(重要概念)
Session.timeout.ms（超時，移除）
Enable.auto.commit（是否自動提交offset，默認自動，多久自動提交）
相關程序說明：
1、如果某個topic的分區數小於接收線程數，則部分線程空閒
2、如果topic的分區數大於接收線程，則部分接收線程會同時讀取多個分區中的數據
3、同一個線程收到的數據可能來自多個partition，不保證數據的順序性
對於同一個consumer group來說，partition同時只能給一個consumer來消費，說明partition的數據只能被一個consumer來消費。
三、kafka應用場景
1、在線與離線的一個連接件
實時的數據中心：主要是對於實時數據的一個分析或者監控系統的一些業務，對於數據的延遲是有比較高的要求
離線數據中心：是對於離線數據的計算，每天固定的指標，對數據的延遲要求相對沒有那麼高，但是讀取的數據量會相對較大。
（不會互相受影響）
2、跨數據中心的數據備份與集成
基於業務和機房物理性質來劃分多個kafka業務集群，基於數據備份和聚合的需求，會部署一個彙總的kafka集群，然後把數據都同步到這裡，然後統一的消費分析和處理。，比如說可以把兩個不同集群的業流攥起來統一做分析
3、實時計算
常用的話是在數據源端來部署我們的一個數據ession，常用的一般是……或者自定義實現的一些生產者，如果是……，我們會使用kafka，然後把數據發佈到kafka集群，對應的話，實時計算這部分。
四、總結
基礎介紹、程序設計介紹、應用場景介紹
這四大部分就是關於kafka的介紹。下面我們一起來看看在最後的答疑過程中，都有些什麼問題呢？
1、最大的區別是什麼？
劉老師：區別是比較多的， 比如架構、協議、吞吐量對我們業務來說 更看重的是大數據的一個處理能力以及跟分析框架的兼容性
劉老師：不是很瞭解微信內部的情況 因為業務部門比較多 但是kafka的場景一定會有的
3、問producer可以多線程嗎？
劉老師:可以的。每次發送數據都是一個獨立的過程，數據會自動分區到不同的partiton去，同樣也可以使用多個客戶端來發送數據。
4、問kafka可以發佈多大數據？
劉老師：需要看你kafka集群的配置，幾百M都是沒有問題的，但主要用途還是消息數據為主，大數據體的話效率是很慢的，數據在集群內還要做備份。
5、問請問在現在mq種類繁多的情況下，通過哪些指標來衡量是否適合自己的應用場景。謝謝。
劉老師：我們主要是考慮大數據的業務場景以及與實時計算框架的融合，比如說storm spark flink等。另外，還要考慮集群的管理。
6、請問老師你們項目中消息模快流程是怎樣？
劉老師我們回去埋點收集數據,然後通過代理層來接受數據,屏蔽用戶直接訪問kafka 後續就是數據分發到各種業務平臺了。
7、請問老師,broke是不是可以對應實際中的一臺服務器,多個broke就可以組成了一個kafka集群嗎?
劉老師：broker就是我們的kafka節點 一般一個服務器部署一個就夠了 因為kafka對磁盤io以及網絡帶款要求還挺高的
8、業務層直接推到Kafka呢還是先推到中間表，再定時掃描中間表推到Kafka？
劉老師:都可以 看你業務的需求 就看你是分佈式推送還是先聚合再推送了。
9、我們最近就用到了kafka,我們是負責收集各個業務系統的處理數據,他們把處理數據發送給我們,我們把數據彙總後再發送給集團的kafka.？
劉老師:這樣處理也是可以的，如果後續需要做實時分析就不行了。
10、分佈式推送和先聚合再推送的優缺點是什麼呢？
劉老師:感覺可以考慮數據量的大小，數據量大的話，先聚合處理效率很快就會有性能瓶頸。另外一方面，埋點多少的問題。
11、老師,下次直播能直接視頻嗎?就是可以直接看到分享桌面,類似於直播,這樣總覺得不太適應!
劉老師:今天第一次分，以後可以考慮一下，謝謝支持。
以上就是本次線上直播的主要內容，相信你對kafka有了一定的認識。想了解更多更詳細內容的小夥伴們，可以關注服務號：FMI飛馬網，點擊菜單欄飛馬直播，即可進行學習。
閱讀更多 飛馬網FMI 的文章
