Kafka是linkedin使用Scala編寫具有高水平擴充套件和高吞吐量的分散式訊息系統。

Kafka對訊息儲存時根據Topic進行歸類，傳送訊息者成為Producer，訊息接受者成為Consumer，此外kafka叢集有多個kafka例項組成，每個例項(server)稱為broker。

無論是Kafka叢集,還是producer和consumer都依賴於zookeeper來保證系統可用性，為叢集儲存一些meta資訊。

• 主流MQ對比
  

Apache Kafka是訊息引擎系統，也是一個分散式流處理平臺（Distributed Streaming Platform）

Kafka是LinkedIn公司內部孵化的專案。LinkedIn最開始有強烈的資料強實時處理方面的需求，其內部的諸多子系統要執行多種型別的資料處理與分析，主要包括業務系統和應用程式效能監控，以及使用者行為資料處理等。

1 Kafka主要特性

1.1 Kafka是一個流處理平臺，流平臺需如下特性:

• 可釋出和訂閱流資料，類似於訊息佇列或者企業級訊息系統
• 以容錯的方式儲存流資料
• 可以在流資料產生時就進行處理(Kafka Stream)

1.2 Kafka適合什麼樣的場景?

● 基於Kafka ,構造實時流資料管道,讓系統或應用之間可靠地獲取資料。
● 構建實時流式應用程式，處理流資料或基於資料做出反應。

2 相關概念 - AMQP協議

AMQP (Advanced Message Queuing Protocol)，是一個提供統一訊息服務的標準高階訊息佇列協議,是應用層協議的一個開放標準，為面向訊息的中介軟體而設計。

• Server
  AMQP服務端，接受客戶端連線，實現AMQP訊息佇列和路由功能的程式。
• Producer
  生產者，向broker釋出訊息的客戶端應用程式。
• Consumer
  消費者，向訊息佇列請求訊息的客戶端應用程式

遇到的主要問題：

• 資料正確性不足
  資料的收集主要採用輪詢（Polling），確定輪詢間隔時間就成了高度經驗化的難題。雖然可以採用一些啟發式演算法（Heuristic）來幫助評估，但一旦指定不當，還是會造成較大的資料偏差。
• 系統高度定製化，維護成本高
  各子系統都需要對接資料收集模組，引入了大量的定製開銷和人工成本

LinkedIn工程師嘗試過使用ActiveMQ解決這些問題，但並不理想
顯然需要有一個“大一統”的系統來取代現有的工作方式，而這個系統就是Kafka。

Kafka自誕生伊始是以訊息引擎系統的面目出現在大眾視野中的
如果翻看0.10.0.0之前的官網說明

Kafka社群將其清晰地定位為一個分散式、分割槽化且帶備份功能的日誌提交（Commit Log）服務。

Kafka作者之一Jay Kreps曾經談及過命名的原因。
因為Kafka系統的寫效能很強，所以找了個作家的名字來命名似乎是一個好主意。大學期間我上了很多文學課，非常喜歡Franz Kafka這個作家，另外為開源軟體起這個名字聽上去很酷。

Kafka旨在提供三個方面的特性：

• 提供一套API實現生產者和消費者
• 降低網路傳輸和磁碟儲存開銷
• 實現高伸縮性架構。

隨著Kafka的不斷完善，Jay等大神們終於意識到將其開源惠及更多的人是一個非常棒的主意，因此在2011年Kafka正式進入到Apache基金會孵化並於次年10月順利畢業成為Apache頂級專案。

特別在大資料領域，Kafka在承接上下游、串聯資料流管道方面發揮了重要的作用：
所有的資料幾乎都要從一個系統流入Kafka然後再流向下游的另一個系統中
這引發了Kafka社群的思考：與其我把資料從一個系統傳遞到下一個系統中做處理，何不自己實現一套流處理框架？
Kafka社群於0.10.0.0版本正式推出了流處理元件Kafka Streams，也正是從這個版本開始，Kafka正式“變身”為分散式的流處理平臺，而不僅僅是訊息引擎系統了
今天Apache Kafka是和Storm/Spark/Flink同等級的實時流處理平臺。

國內對Kafka是流處理平臺的認知還尚不普及，其核心的流處理元件Kafka Streams更是少有大廠在使用
隨著在Kafka峰會上各路大神們的鼎力宣傳，如今利用Kafka構建流處理平臺的案例層出不窮，而瞭解並有意願使用Kafka Streams的廠商也是越來越多

優勢

更易實現端到端的正確性（Correctness）

Google大神Tyler曾經說過，流處理要最終替代它的“兄弟”批處理需要具備兩點核心優勢

• 實現正確性
• 提供能夠推導時間的工具

實現正確性是流處理能夠匹敵批處理的基石
正確性一直是批處理的強項，而實現正確性的基石則是要求框架能提供精確一次處理語義，即處理一條訊息有且只有一次機會能夠影響系統狀態
目前主流的大資料流處理框架都宣稱實現了精確一次處理語義，但這是有限定條件的，即它們只能實現框架內的精確一次處理語義，無法實現端到端
因為當這些框架與外部訊息引擎系統結合時，無法影響到外部系統的處理語義，所以Spark/Flink從Kafka讀取訊息之後進行有狀態的資料計算，最後再寫回Kafka，只能保證在Spark/Flink內部，這條訊息對於狀態的影響只有一次
但是計算結果有可能多次寫入到Kafka，因為它們不能控制Kafka的語義處理
相反地，Kafka則不是這樣，因為所有的資料流轉和計算都在Kafka內部完成，故Kafka可以實現端到端的精確一次處理語義

舉個例子，使用Kafka計算某網頁的PV——我們將每次網頁訪問都作為一個訊息傳送的Kafka
PV的計算就是我們統計Kafka總共接收了多少條這樣的訊息即可
精確一次處理語義表示每次網頁訪問都會產生且只會產生一條訊息，否則有可能產生多條訊息或壓根不產生訊息。

流式計算的定位

官網上明確Kafka Streams是一個用於搭建實時流處理的客戶端庫而非是一個完整的功能系統
不能期望著Kafka提供類似於叢集排程、彈性部署等開箱即用的運維特性，需要自己選擇適合的工具或系統來幫助Kafka流處理應用實現這些功能。
這的確是一個“雙刃劍”的設計，也是Kafka社群“劍走偏鋒”不正面PK其他流計算框架的特意考量
大型公司的流處理平臺一定是大規模部署的，因此具備叢集排程功能以及靈活的部署方案是不可或缺的要素
但畢竟這世界上還存在著很多中小企業，它們的流處理資料量並不巨大，邏輯也並不複雜，部署幾臺或十幾臺機器足以應付。在這樣的需求之下，搭建重量級的完整性平臺實在是“殺雞焉用牛刀”，而這正是Kafka流處理元件的用武之地
因此從這個角度來說，未來在流處理框架中，Kafka應該是有一席之地的。

Kafka能夠被用作分散式儲存系統
Kafka作者之一Jay Kreps曾經專門寫過一篇文章闡述為什麼能把Kafka用作分散式儲存。不過我覺得你姑且瞭解下就好了，我從沒有見過在實際生產環境中，有人把Kafka當作持久化儲存來用 。

參考

• Apache Kafka實戰