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 對應的解決方案。

 

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

什麼是 Apache Pulsar？

 

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

 

Pulsar 性能

 

 

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

 

與 Kafka 相比，Pulsar 的速度提高了 2.5 倍，延遲下降了 40％。（來源：https://streaml.io/pdf/Gigaom-Benchmarking-Streaming-Platforms.pdf）。

 

請注意，該性能比較是針對 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，會經歷一個小小的學習曲線，但相應的投資回報率仍是很客觀的！

 

如需獲取 Pulsar 的企業服務和支持

 

 

做者 : Anuradha Prasanna

翻譯 : Zhanying

審校 : Jennifer + Sijie + Yjshen

編輯 : Irene

 

 

 

Apache Pulsar 是下一代雲原生分佈式流數據平臺，它源於 Yahoo，2016 年 12 月開源，2018 年 9 月正式成爲 Apache 頂級項目，逐漸從單一的消息系統演化成集消息、存儲和函數式輕量化計算的流數據平臺。在 Apache Pulsar 快速發展的過程當中，社區的夥伴們也致力於硅谷之外的佈道之旅，在中國社區開始了不平凡的歷程。8 月 17 日，來自 Yahoo！Japan、騰訊、智聯招聘、EMQ、Apache Fink 和 Apache Pulsar 社區的開源愛好者們將齊聚一堂，共同探討 Pulsar 的用戶案例、最佳實踐和 Pulsar 特性等等，包括：

 

1. Apache Pulsar at Yahoo! Japan

2. 智聯招聘如何參與社區開發以及 Key_Shared 等近期貢獻特性詳解

3. Apache Pulsar 在騰訊計費場景下的實踐

4. Apache Pulsar 在 EMQ 物聯網平臺產品 ActorCloud 上的應用

5. Pulsar 2.5.0 事務功能預覽

6. Apache Pulsar 和大數據生態的集成與實踐

7. 監控流系統中的 Flink 狀態管理