Apache Kafka 是一個快速、可擴展的、高吞吐的、可容錯的分布式“發布-訂閱”消息系統， 使用 Scala 與 Java 語言編寫，能夠將消息從一個端點傳遞到另一個端點。

較之傳統的消息中間件(例如 ActiveMQ、RabbitMQ)，Kafka 具有高吞吐量、內置分區、支持消息副本和高容錯的特性，非常適合大規模消息處理應用程序。

Kafka 官網：

Kafka 主要設計目標如下：

以時間復雜度為 O(1) 的方式提供消息持久化能力，即使對 TB 級以上數據也能保證常數時間的訪問性能。

高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒 100K 條消息的傳輸。

支持 Kafka Server 間的消息分區，及分布式消費，同時保證每個 Partition 內的消息順序傳輸。

同時支持離線數據處理和實時數據處理。

支持在線水平擴展。

Kafka 通常用于兩大類應用程序：

建立實時流數據管道，以可靠地在系統或應用程序之間獲取數據。

構建實時流應用程序，以轉換或響應數據流。

要了解 Kafka 如何執行這些操作，讓我們從頭開始深入研究 Kafka 的功能。

首先幾個概念：

Kafka 在一個或多個可以跨越多個數據中心的服務器上作為集群運行。

Kafka 集群將記錄流存儲在稱為主題的類別中。

每個記錄由一個鍵，一個值和一個時間戳組成。

Kafka 的應用場景非常多, 下面我們就來舉幾個我們最常見的場景：

①用戶的活動跟蹤：用戶在網站的不同活動消息發布到不同的主題中心，然后可以對這些消息進行實時監測、實時處理。

當然，也可以加載到 Hadoop 或離線處理數據倉庫，對用戶進行畫像。像淘寶、天貓、京東這些大型電商平臺，用戶的所有活動都要進行追蹤的。

②日志收集：

③限流削峰如下圖：

④高吞吐率實現：Kafka 與其他 MQ 相比，最大的特點就是高吞吐率。為了增加存儲能力，Kafka 將所有的消息都寫入到了低速大容量的硬盤。

按理說，這將導致性能損失，但實際上，Kafka 仍然可以保持超高的吞吐率，并且其性能并未受到影響。

其主要采用如下方式實現了高吞吐率：

順序讀寫：Kafka 將消息寫入到了分區 Partition 中，而分區中的消息又是順序讀寫的。順序讀寫要快于隨機讀寫。

零拷貝：生產者、消費者對于 Kafka 中的消息是采用零拷貝實現的。

批量發送：Kafka 允許批量發送模式。

消息壓縮：Kafka 允許對消息集合進行壓縮。

Kafka的優點如下：

①解耦：在項目啟動之初來預測將來項目會碰到什么需求，是極其困難的。

消息系統在處理過程中間插入了一個隱含的、基于數據的接口層，兩邊的處理過程都要實現這一接口。

這允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

②冗余(副本)：有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。

消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。

許多消息隊列所采用的"插入-獲取-刪除"范式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

③擴展性：因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴展就像調大電力按鈕一樣簡單。

④靈活性&峰值處理能力：在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量并不常見;如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。

使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

⑤可恢復性：系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復后被處理。

⑥順序保證：在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數據會按照特定的順序來處理。Kafka 保證一個 Partition 內的消息的有序性。

⑦緩沖：在任何重要的系統中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應用過濾器花費更少的時間。

消息隊列通過一個緩沖層來幫助任務最高效率的執行，寫入隊列的處理會盡可能的快速。該緩沖有助于控制和優化數據流經過系統的速度。

⑧異步通信：很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

Kafka 于其他 MQ 對比如下：

①RabbitMQ：RabbitMQ 是使用 Erlang 編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP，SMTP，STOMP，也正因如此，它非常重量級，更適合于企業級的開發。

同時實現了 Broker 構架，這意味著消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

②Redis：Redis 是一個基于 Key-Value 對的 NoSQL 數據庫，開發維護很活躍。

雖然它是一個 Key-Value 數據庫存儲系統，但它本身支持 MQ 功能，所以完全可以當做一個輕量級的隊列服務來使用。

對于 RabbitMQ 和 Redis 的入隊和出隊操作，各執行 100 萬次，每 10 萬次記錄一次執行時間。測試數據分為 128Bytes、512Bytes、1K 和 10K 四個不同大小的數據。

（編輯：武林網）