Kafka 已落伍，轉角碰見 Pulsar！

自 LinkedIn 2011 年建立了 Apache Kafka 後，這款消息系統一度成爲大規模消息系統的惟一選擇。爲何呢？由於這些消息系統天天須要傳遞數百萬條消息，消息規模確實很龐大（2018 年 Twitter 推文平均天天 500 萬條，用戶數平均天天爲 1 億）。那時，咱們沒有 MOM 系統來處理基於大量訂閱的流數據能力。因此，不少大牌公司，像 LinkedIn、Yahoo、Twitter、Netflix 和 Uber，只能選擇 Kafka。

現在到了 2019 年，世界發生了鉅變，天天的消息增量高達數十億，支持平臺也須要相應擴展，以知足持續增加的須要。所以，消息系統須要在不影響客戶的狀況下持續地無縫擴展。Kafka 在擴展方面存在諸多問題，系統也難以管理。Kafka 的粉絲對此說法可能很有微詞，然而這並不是我的偏見，我自己也是 Kafka 的粉絲。客觀的說，隨着世界的發展和創新，新工具比舊工具更加方便易用，咱們天然會感受原來的工具漏洞百出，很難使用。天然發展，一直如此。

這時，一款新的產品應運而生——它就是「Apache Pulsar」！

2013 年雅虎建立了 Pulsar，並於 2016 年把 Pulsar 捐給了 Apache 基金會。Pulsar 現已成爲 Apache 的頂級項目，得到舉世矚目的承認。雅虎和 Twitter 都在使用 Pulsar，雅虎天天發送 1000 億條消息，兩百多萬個主題。這樣的消息量，聽起來很難以想象吧，但確實是真的！

接下來咱們瞭解下 Kafka 痛點以及 Pulsar 對應的解決方案。

• Kafka 很難進行擴展，由於 Kafka 把消息持久化在 broker 中，遷移主題分區時，須要把分區的數據徹底複製到其餘 broker 中，這個操做很是耗時。

• 當須要經過更改分區大小以得到更多的存儲空間時，會與消息索引產生衝突，打亂消息順序。所以，若是用戶須要保證消息的順序，Kafka 就變得很是棘手了。

• 若是分區副本不處於 ISR（同步）狀態，那麼 leader 選取可能會紊亂。通常地，當原始主分區出現故障時，應該有一個 ISR 副本被徵用，可是這點並不能徹底保證。若在設置中並未規定只有 ISR 副本可被選爲 leader 時，選出一個處於非同步狀態的副本作 leader，這比沒有 broker 服務該 partition 的狀況更糟糕。

• 使用 Kafka 時，你須要根據現有的狀況並充分考慮將來的增量計劃，規劃 broker、主題、分區和副本的數量，才能避免 Kafka 擴展致使的問題。這是理想情況，實際狀況很難規劃，不可避免會出現擴展需求。

• Kafka 集羣的分區再均衡會影響相關生產者和消費者的性能。

• 發生故障時，Kafka 主題沒法保證消息的完整性（特別是遇到第 3 點中的狀況，須要擴展時極有可能丟失消息）。

• 使用 Kafka 須要和 offset 打交道，這點讓人很頭痛，由於 broker 並不維護 consumer 的消費狀態。

• 若是使用率很高，則必須儘快刪除舊消息，不然就會出現磁盤空間不夠用的問題。

• 衆所周知，Kafka 原生的跨地域複製機制（MirrorMaker）有問題，即便只在兩個數據中心也沒法正常使用跨地域複製。所以，甚至 Uber 都不得不建立另外一套解決方案來解決這個問題，並將其稱爲 uReplicator 。

• 要想進行實時數據分析，就不得不選用第三方工具，如 Apache Storm、Apache Heron 或 Apache Spark。同時，你須要確保這些第三方工具足以支撐傳入的流量。

• Kafka 沒有原生的多租戶功能來實現租戶的徹底隔離，它是經過使用主題受權等安全功能來完成的。

  
  

固然，在生產環境中，架構師和工程師有辦法解決上述問題；可是在平臺/解決方案或站點可靠性上，這是個讓人頭疼的問題，這並不像在代碼中修復邏輯，而後將打包的二進制文件部署到生產環境中那麼簡單。

如今，咱們來聊聊 Pulsar，這個競爭領域中的領跑者。

什麼是 Apache Pulsar？

Apache Pulsar 是一個開源分佈式發佈-訂閱消息系統，最初由雅虎建立。若是你瞭解 Kafka，能夠認爲 Pulsar 在本質上和 Kafka 相似。

Pulsar 性能

Pulsar 表現最出色的就是性能，Pulsar 的速度比 Kafka 快得多，美國德克薩斯州一家名爲 GigaOm 的技術研究和分析公司對 Kafka 和 Pulsar 的性能作了比較，並證明了這一點。

與 Kafka 相比，Pulsar 的速度提高了 2.5 倍，延遲下降了 40％。（來源在這裏）。

請注意，該性能比較是針對 1 個分區的 1 個主題，其中包含 100 字節消息。而 Pulsar 每秒可發送 220,000+ 條消息，以下所示。

 

這點 Pulsar 作的確實很棒！

就衝這一點，放棄 Kafka 而轉向 Pulsar 絕對很值，接下來，我會詳細剖析 Pulsar 的優點和特色。

Apache Pulsar 的優點和特色

Pulsar 既支持做爲消息隊列以 Pub-Sub 模式使用，又支持按序訪問（相似 Kafka 基於 Offset 的閱讀），這給用戶提供了極大的靈活性。

針對數據持久化，Pulsar 的系統架構和 Kafka 不一樣。Kafka 在本地 broker 中使用日誌文件，而 Pulsar 把全部主題數據存儲在 Apache BookKeeper 的專用數據層中。簡單地說，BookKeeper 是一種高可擴展、強容災和低延時的存儲服務，而且針對實時持久的數據工做負載進行了優化。所以，BookKeeper 保證了數據的可用性。而 Kafka 日誌文件駐留在各個 broker 以及災難性服務器故障中，因此 Kafka 日誌文件可能出現問題，不能徹底確保數據的可用性。這個有保證的持久層（guaranteed persistence layer）給 Pulsar 帶來了另外一個優點，即「broker 是無狀態的」。這與 Kafka 有本質的區別。Pulsar 的優點在於 broker 能夠無縫地水平擴展以知足不斷增加的需求，由於它在擴展時不須要移動實際數據。

若是一個 Pulsar broker 宕機了怎麼辦？主題會被當即從新分配給另外一個 broker。因爲 broker 的磁盤中沒有主題數據，服務發現會自行處理 producer 和 consumer。

Kafka 須要清除舊數據才能使用磁盤空間；與 Kafka 不一樣，Pulsar 把主題數據存儲在一個分層結構中，該結構能夠鏈接其餘磁盤或 Amazon S3，這樣就能夠無限擴展和卸載主題數據的存儲量。更酷的是，Pulsar 向消費者無縫地顯示數據，就好像這些數據在同一個驅動器上。因爲不須要清除舊數據，你能夠把這些組織好的 Pulsar 主題用做「數據湖（Data Lake）」，這個用戶場景仍是頗有價值的。固然，須要的時候，你也能夠經過設置，清除 Pulsar 中的舊數據。

Pulsar 原生支持在主題命名空間級別使用數據隔離的多租戶；而 Kafka 沒法實現這種隔離。此外，Pulsar 還支持細粒度訪問控制功能，這讓 Pulsar 的應用程序更加安全、可靠。

Pulsar 有多個客戶端庫，可用於 Java、Go、Python、C++ 和 WebSocket 語言。

Pulsar 原生支持功能即服務（FaaS），這個功能很酷，就和 Amazon Lambda 同樣，能夠實時分析、聚合或彙總實時數據流。使用 Kafka，還須要配套使用像 Apache Storm 這樣的流處理系統，這會額外增長成本，維護起來也很麻煩。在這點上，Pulsar 就遠遠賽過 Kafka。截至目前，Pulsar Functions 支持 Java、 Python 和 Go 語言，其餘語言將在之後的版本中陸續獲得支持。

Pulsar Functions 的用戶案例包括基於內容的路由（content based routing）、聚合、消息格式化、消息清洗等。

以下是字數計算示例。

package org.example.functions;import org.apache.pulsar.functions.api.Context;import org.apache.pulsar.functions.api.Function;import java.util.Arrays;public class WordCountFunction implements Function<String, Void> {    // This is invoked every time messages published to the topic    @Override    public Void process(String input, Context context)         throws Exception {        Arrays.asList(input.split(" ")).forEach(word -> {            String counterKey = word.toLowerCase();            context.incrCounter(counterKey, 1);        });        return null;    }}

Pulsar 支持多個數據接收器（data sink），用於爲主要產品（如 Pulsar 主題自己、Cassandra、Kafka、AWS Kinesis、彈性搜索、Redis、Mongo DB、Influx DB 等）路由處理過的消息。

此外，還能夠把處理過的消息流持久化到磁盤文件。

Pulsar 使用 Pulsar SQL 查詢歷史消息，使用 Presto 引擎高效查詢 BookKeeper 中的數據。Presto 是用於大數據解決方案的高性能分佈式 SQL 查詢引擎，能夠在單個查詢中查詢多個數據源的數據。以下是使用 Pulsar SQL 查詢的示例。

show tables in pulsar."public/default"

Pulsar 內置強大的跨地域複製機制，可在不一樣區域的不一樣集羣之間即時同步消息，以維護消息的完整性。在 Pulsar 主題上生成消息時，消息首先保留在本地集羣中，而後異步轉發到遠程集羣。在 Pulsar 中，啓用跨地域複製是基於租戶的。只有建立的租戶能夠同時訪問兩個集羣時，這兩個集羣之間才能啓用跨地域複製。

對於消息傳遞通道安全，Pulsar 原生支持基於 TLS 和基於 JWT token 的受權機制。所以，你能夠指定誰能夠發佈或使用哪些主題的消息。此外，爲了提升安全性，Pulsar Encryption 容許應用程序在生產者端加密全部消息，並在 Pulsar 傳遞加密消息到消費者端時解密。Pulsar 使用應用程序配置的公鑰/私鑰對執行加密。具備有效密鑰的消費者才能解密加密消息。但這會帶來性能損失，由於每條消息都須要加密和解密才能進行處理。

目前在使用 Kafka 而且但願遷移到 Pulsar 的用戶大可放心，Pulsar 原生支持經過鏈接器（connector）直接使用 Kafka 數據，或者你能夠把現有的 Kafka 應用程序數據導入到 Pulsar，這個過程也至關容易。

總結

這篇文章並非說大規模消息處理平臺不能使用 Kafka，只能選擇 Pulsar。我要強調的是，Kafka 的痛點 Pulsar 已經有了很好的解決方案，這對任何工程師或架構師來講都是一件好事。另外，在體系架構方面 Pulsar 在大型消息傳遞解決方案中的速度要快得多，隨着雅虎和 Twitter（以及許多其餘公司）把 Pulsar 部署到生產環境，說明 Pulsar 穩定性足以支撐任何生產環境。雖然從 Kafka 轉到 Pulsar，會經歷一個小小的學習曲線，但相應的投資回報率仍是很客觀的！

— THE END —