介紹
最近，我一直在研究Pulsar及其與Kafka的比較。快速搜索將顯示兩個最著名的開源消息傳遞系統之間存在當前的"戰爭"。javascript
做爲Kafka的用戶，我確實對Kafka的某些問題感到困惑，而且我對Pulsar感到很是失望。因此最後，我設法花了一些時間進行研究，而且作了不少研究。在本文中，我將重點介紹Pulsar的優點，併爲您提供一些理由，使您對比Kafka來考慮它。可是，請在產品使用，支持，社區，文檔等方面明確一點；Kafka顯然超過了Pulsar，而且只有在本文中討論的大多數優勢都適合您的用例的狀況下，才考慮使用Pulsar。讓咱們開始！java
Kafka基礎知識
Kafka是消息傳遞系統之王。它由LinkedIn於2011年建立，並在Confluent的支持下獲得了普遍的傳播。Confluent已向開源社區發佈了許多新功能和附加組件，例如用於模式演化的Schema Registry，用於從其餘數據源輕鬆流式傳輸的Kafka Connect等。數據庫到Kafka，Kafka Streams進行分佈式流處理，最近使用KSQL對Kafka主題執行相似SQL的查詢等等。它還具備用於許多系統的許多鏈接器，有關更多詳細信息，請查看Confluent Platform。python
Kafka快速，易於安裝，很是受歡迎，可用於普遍的範圍或用例。從開發人員的角度來看，儘管Apache Kafka一直很友好，但在操做上倒是一團糟。所以，讓咱們回顧一下Kafka的一些痛點。git
> Kafka example. Source: https://talks.rmoff.net/pZC6Za/slidesgithub
Kafka的問題
· 擴展Kafka十分棘手，這是因爲代理還存儲數據的耦合體系結構所致。剝離另外一個代理意味着它必須複製主題分區和副本，這很是耗時。sql
· 沒有與租戶徹底隔離的本地多租戶。數據庫
· 存儲可能會變得很是昂貴，儘管能夠長時間存儲數據，可是因爲成本問題，不多使用它。apache
· 萬一副本不一樣步，有可能丟失消息。編程
· 必須提早計劃和計算代理，主題，分區和副本的數量（以適應計劃的將來使用量增加），以免擴展問題，這很是困難。swift
· 若是僅須要消息傳遞系統，則使用偏移量可能會很複雜。
· 集羣從新平衡會影響相連的生產者和消費者的性能。
· MirrorMaker Geo複製機制存在問題。像Uber這樣的公司已經建立了本身的解決方案來克服這些問題。
如您所見，大多數問題與操做方面有關。儘管安裝起來相對容易，但Kafka難以管理和調整。並且，它尚未像它可能的那樣靈活和有彈性。
Pulsar基礎知識
Pulsar由Yahoo在2013年建立，並於2016年捐贈給Apache基金會。Pulsar如今是Apache的頂級項目。Yahoo，Verizon，Twitter等公司在生產中使用它來處理數百萬條消息。它具備許多功能，而且很是靈活。它聲稱比Kafka更快，所以運行成本更低。它旨在解決Kafka的大部分難題，使其更易於擴展。
Pulsar很是靈活；它能夠像Kafka這樣的分佈式日誌，也能夠像RabbitMQ這樣的純消息傳遞系統。它具備多種類型的訂閱，幾種交付保證，保留策略以及幾種處理模式演變的方法。它還有不少功能……
> Pulsar architecture: https://pulsar.apache.org/docs/en/concepts-architecture-overview/
Pulsar的特性
· 因爲內置了多租戶，所以不一樣的團隊可使用相同的集羣並將其隔離。這解決了許多管理難題。它支持隔離，身份驗證，受權和配額。
· 多層體系結構：Pulsar將全部主題數據存儲在由Apache BookKeeper支持的專業數據層中，做爲數據分類賬。存儲和消息傳遞的分離解決了擴展，從新平衡和維護集羣的許多問題。它還提升了可靠性，幾乎不可能丟失數據。另外，在讀取數據時，能夠直接鏈接到Bookeeper，而不會影響實時攝取。例如，可使用Presto對主題執行SQL查詢，相似於KSQL，但請放心，這不會影響實時數據處理。
· 虛擬主題。因爲採用n層體系結構，所以對主題的數量沒有限制，主題及其存儲是分離的。還能夠建立非持久性主題。
· N層存儲。Kafka的一個問題是，存儲可能變得昂貴。所以，它不多用於存儲"冷"數據，而且消息常常被刪除。而且仍然向客戶展現透明視圖；客戶端能夠從時間開始讀取，就像全部消息都存在於日誌中同樣。
·Pulsar函數。易於部署，輕量級計算過程，對開發人員友好的API，無需運行本身的流處理引擎（如Kafka）。
· 安全性：它具備內置的代理，多租戶安全性，可插入身份驗證等等。
· 快速從新平衡。分區分爲易於從新平衡的段。
· 服務器端重複數據刪除和無效字段。無需在客戶端中執行此操做，也能夠在壓縮期間執行重複數據刪除。
· 內置架構註冊表。支持多種策略，很是易於使用。
· 地理複製和內置發現。將羣集複製到多個區域很是容易。
· 集成的負載均衡器和Prometheus指標。
· 多重集成：Kafka，RabbitMQ等。
· 支持許多編程語言，例如GoLang，Java，Scala，Node，Python…
· 客戶端不須要知道分片和數據分區，這是在服務器端透明進行的。
> List of features: https://pulsar.apache.org/
如您所見，Pulsar具備許多有趣的功能。
Pulsar 動手
開始使用Pulsar很是容易。確保已安裝JDK！
· 下載Pulsar並解壓縮：
$ wget https://archive.apache.org/dist/pulsar/pulsar-2.6.1/apache-pulsar-2.6.1-bin.tar.gz
2.下載鏈接器（可選）：
$ wget https://archive.apache.org/dist/pulsar/pulsar-2.6.1/connectors/{connector}-2.6.1.nar
3.下載nar文件後，將文件複製到pulsar目錄中的connectors目錄
4.啓動Pulsar！
$ bin/pulsar standalone
Pulsar提供了一個稱爲pulsar-client的CLI工具，咱們可使用它與集羣進行交互。
產生消息：
$ bin/pulsar-client produce my-topic --messages "hello-pulsar"
閱讀消息：
$ bin/pulsar-client consume my-topic -s "first-subscription"
Akka流示例
做爲一個客戶示例，讓咱們在Akka上使用Pulsar4s！
首先，咱們須要建立一個Source來使用數據流，所須要的只是一個函數，該函數將按需建立使用者並查找消息ID：
val topic = Topic("persistent://standalone/mytopic")
val consumerFn = () => client.consumer(ConsumerConfig(topic, subscription))
而後，咱們傳遞consumerFn函數來建立源：
import com.sksamuel.pulsar4s.akka.streams._
val pulsarSource = source(consumerFn, Some(MessageId.earliest))
Akka源的物化值是Control的一個實例，該對象提供了一種"關閉"方法，可用於中止使用消息。如今，咱們能夠像往常同樣使用Akka Streams處理數據。
要建立一個接收器：
val topic = Topic("persistent://standalone/mytopic")
val producerFn = () => client.producer(ProducerConfig(topic))
import com.sksamuel.pulsar4s.akka.streams._
val pulsarSink = sink(producerFn)
完整示例摘自Pulsar4s：
Pulsar函數示例
Pulsar函數處理來自一個或多個主題的消息，對其進行轉換並將結果輸出到另外一個主題：
> Pulsar Functions. Source: https://pulsar.apache.org/docs/en/functions-overview/
能夠在兩個接口之間進行選擇以編寫函數：
· 語言本機界面：不須要特定於Pulsar的庫或特殊的依賴項。沒法訪問上下文。僅支持Java和Python。
· Pulsar Function SDK：可用於Java / Python / Go，並提供更多功能，包括訪問上下文對象。
使用語言本機接口很是容易，您只需編寫一個簡單的函數便可轉換消息：
def process(input):
return "{}!".format(input)
用Python編寫的這個簡單函數只是向全部傳入的字符串添加一個感嘆號，並將結果字符串發佈到主題。
要使用SDK，您須要導入依賴項，例如在Go中，咱們將編寫：
package main
import (
"context"
"fmt"
"github.com/apache/pulsar/pulsar-function-go/pf"
)
func HandleRequest(ctx context.Context, in []byte) error {
fmt.Println(string(in) + "!")
return nil
}
func main() {
pf.Start(HandleRequest)
}
要發佈無服務器功能並將其部署到集羣，咱們使用pulsar-admin CLI，若是使用Python，咱們將使用：
$ bin/pulsar-admin functions create \
--py ~/router.py \
--classname router.RoutingFunction \
--tenant public \
--namespace default \
--name route-fruit-veg \
--inputs persistent://public/default/basket-items
Pulsar Functions的一個重要功能是您能夠在發佈該函數時設置交付保證：
$ bin/pulsar-admin functions create \
--name my-effectively-once-function \
--processing-guarantees EFFECTIVELY_ONCE
有如下選擇：
Pulsar的優點
讓咱們回顧一下與Kafka相比的主要優點：
· 更多功能：Pulsar函數，多租戶，架構註冊表，n層存儲，多種使用模式和持久性模式等。
· 更大的靈活性：3種訂閱類型（獨佔，共享和故障轉移），您能夠在一個訂閱上收聽多個主題。持久性選項：非持久（快速），持久，壓縮（每一個消息僅最後一個鍵）。能夠選擇交付保證，它具備服務器端重複數據刪除和無效字樣。許多保留政策和TTL。
· 無需提早定義擴展需求。
· 支持排隊和流媒體。所以它能夠像RabbitMQ或Kafka。
· 因爲存儲與代理分離，所以擴展性更好。從新平衡更快，更可靠。
· 易於操做：得益於去耦和n層存儲。管理員REST API也很棒。
· 與Presto的SQL集成，可直接查詢存儲而不會影響代理。
· 藉助n層自動存儲選項，能夠更便宜地存儲。
· 更快：許多基準測試在各類狀況下都表現出更好的性能。Pulsar聲稱具備較低的延遲和更好的擴展功能。可是，這正受到Confluent的挑戰，所以，請帶着鹽味作，並本身制定基準。
· Pulsar Functions將無服務器計算帶到您的消息傳遞平臺。
· 集成架構註冊表支持輕鬆的架構演變
· 集成的負載平衡器和Prometheus指標。
· 地理複製效果更好，更易於設置。Pulsar還內置了發現能力。
· 能夠建立的主題數量沒有限制。
· 與Kafka兼容，易於集成。
Pulsar的問題
Pulsar並不完美，Kafka之因此流行是有緣由的，它作一件事而且作得很好。Pulsar試圖解決太多領域，但沒有超越任何一個領域。讓咱們總結一下Pulsar的一些問題：
· 受歡迎程度：Pulsar不那麼受歡迎。它缺少支持，文檔和實際使用狀況。對於大型組織而言，這是一個主要問題。
· 因爲n層體系結構，它須要更多組件：Bookkeeper。
· 在平臺內沒有對流應用程序的適當支持。Pulsar函數與Kafka Streams不一樣，它們更簡單，而且不用於實時流處理。您沒法進行有狀態處理。
· 與Kafka相比，插件和客戶端更少。此外，掌握Pulsar技能的人較少，所以須要在內部學習。
· 它在雲中的支持較少。Confluent具備託管雲產品。
Confluent在Pulsar和Kafka之間進行了比較，能夠在其中進行更多的詳細說明。該博客還回答了有關Kafka與Pulsar的一些問題，但請注意，這些問題可能有偏見。
Pulsar使用案例
Pulsar可用於普遍的用例：
· 發佈/訂閱隊列消息傳遞
· 分佈式日誌
· 事件源壁架，用於永久性事件存儲
· 微服務
· SQL分析
· 無服務器功能
何時應該考慮Pulsar
· 須要像RabbitMQ這樣的隊列，也須要像Kafka這樣的流處理程序。
· 須要簡單的地理複製。
· 多租戶是必須具有的，而且想確保每一個團隊的訪問權限。
· 須要將全部消息保留很長時間，而且不想將其卸載到另外一個存儲中。
· 性能對你相當重要，基準測試代表Pulsar提供了更低的延遲和更高的吞吐量。
· 在本地運行，沒有設置Kafka的經驗，但具備Hadoop經驗。
請注意，若是在雲中，請考慮基於雲的解決方案。雲提供商擁有涵蓋某些用例的不一樣服務。例如，對於隊列消息傳遞，雲提供商提供了許多服務，例如Google pub / sub。對於分佈式日誌，有Confluent雲或AWS Kinesis。雲提供商還提供了很是好的安全性。Pulsar的優點在於能夠在一個平臺上提供許多功能。一些團隊可能將其用做微服務的消息傳遞系統，而另外一些團隊則將其用做數據處理的分佈式日誌。
結論
我是Kafka的忠實粉絲，這就是爲何我對Pulsar如此感興趣。競爭是好的，它驅動創新。
Kafka是一種成熟，富有彈性且通過戰鬥考驗的產品，在世界範圍內得到了巨大成功。沒有它，我沒法想象任何公司。可是，我確實看到Kafka成爲其自身成功的受害者，巨大的增加減慢了功能開發的速度，由於它們須要支持這麼多大型公司。刪除ZooKeeper依賴項等重要功能花費的時間太長。這爲諸如Pulsar等工具蓬勃發展創造了空間。解決Kafka的一些問題並添加更多功能。
可是，Pulsar仍然很不成熟，在投入生產以前，我會格外當心。在將Pulsar歸入你的組織以前，進行分析，進行基準測試，研究並編寫概念證實。從小處着手，在從Kafka遷移以前進行概念驗證，並在決定進行徹底遷移以前先評估影響。
做者：聞數起舞
連接：https://0x9.me/cYZFN
本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。