這篇文章給大家介紹為什么選擇 Pulsar 而非 Kafka ，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
創(chuàng)新互聯(lián)是一家企業(yè)級云計算解決方案提供商,超15年IDC數(shù)據(jù)中心運營經(jīng)驗。主營GPU顯卡服務器，站群服務器，成都服務器托管，海外高防服務器，服務器機柜，動態(tài)撥號VPS，海外云手機，海外云服務器，海外服務器租用托管等。
Pulsar 對多租戶的支持是一個很重要的特性。
在企業(yè)中，消息基礎架構會被多團隊、多項目使用。
為每個團隊（項目）分別維護一個獨立的消息系統(tǒng)集群代價過高且難以維護。
Pulsar 可以有
多個租戶
，這些租戶可以有多個命名空間，以保持內(nèi)容順序。
再加上每個命名空間的訪問控制、配額、速率限制等，可以想象，將來我們可以只使用一個集群就能處理多租戶問題。
其實不僅我們考慮到這個問題，Kafka 也會考慮。 接下來，我會講到很多細節(jié)。
要想確保消息不丟失，消息傳遞系統(tǒng)會配置每條消息生成 2 或 3 個副本，以防出錯。
Kafka 使用 follow-the-leader 模型來實現(xiàn)這一點。
Leader 存儲消息，而 follower 復制 leader 上的消息。
一旦有足夠多的 follower 確認已經(jīng)完成了復制，Kafka 就“高興”了。
Pulsar 使用
Quorum 模型
。
它把消息發(fā)送給一堆節(jié)點，一旦有足夠多的節(jié)點確認它們已經(jīng)接收到消息，Pulsar 就很“高興”。Quorum 復制更加民主，沒有這種 leader-follower 層次結構。
所有選票均等時，多數(shù)勝利。
但這與技術無關。
重要的是，隨著時間的推移，Quorum 復制傾向于提供更一致的行為。這或許可以解釋為什么 Pulsar 具有更一致的延遲性能。
事實上，Kafka 也一直在考慮使用 Quorum 復制來改善延遲一致性。
關于此，可以查看
KIP-250
中的討論。像 Kafka 這樣的流處理系統(tǒng)，其一大優(yōu)點在于它能夠重放已經(jīng)被消費的消息。
如果你第一次見到就很喜歡這些消息，則可以進行重播以更正某些內(nèi)容，或圍繞它們構建新的應用程序，這也是很有趣的。如果你非常喜歡這些消息，想把它們永遠保存下來，那該怎么辦？
比如，如果你在做
事件溯源
。
這聽起來很不錯，但永久可是
一段很長的時間
，而且永久存儲消息也可能很貴，特別是存儲在高性能固態(tài)硬盤上。
這些硬盤需要維持消息系統(tǒng)保持良好的運行狀態(tài)。如果能把那些舊消息（那些以后可能會再用到的消息）轉(zhuǎn)移到相對便宜的存儲解決方案中，是否可行呢？
如果可以使用像 Amazon S3 存儲桶這樣廉價的云存儲，那豈不是很棒嗎？
你可能已經(jīng)猜到我要說什么了。借助 Pulsar
分層存儲
，你可以把那些舊消息自動推送到幾乎無限的、廉價的云存儲中，然后像檢索新消息一樣執(zhí)行相關操作。
我敢打賭，Kafka 希望擁有該功能。
沒錯，他們會的。顯然，安全是很重要的，誰都不希望信息安全被偷窺。
當然，你會在客戶端和消息傳遞系統(tǒng)之間使用 TLS（在傳輸過程中加密）。
這樣做時，消息傳遞系統(tǒng)必須解密該連接，以便了解客戶端想要表達的內(nèi)容。 然后，它把未加密的消息保存在磁盤上。
當然，你會堅持對磁盤進行加密，這樣即使磁盤被偷，消息仍然是安全的（靜態(tài)加密）。
但在這兩種情況下，消息傳遞系統(tǒng)都需要有數(shù)據(jù)的密鑰。
如果不是這樣，那就是在處理一大堆莫名其妙的天書。許多情況下，這種級別的加密已經(jīng)足夠好了，但是如果你想要確保沒有人可以偷窺你的消息，則需要進行端到端加密。
生產(chǎn)者在發(fā)送消息之前使用與接收消息的使用者共享的密鑰對消息進行加密。
當消息保存在消息系統(tǒng)的磁盤上時，就會被加密，而消息系統(tǒng)沒有密鑰。
消息傳遞系統(tǒng)可以完成它的工作，但是你的消息對于消息傳遞系統(tǒng)來說是就像天書一樣，所以是十分安全的。Pulsar 可以在其 Java 客戶端中進行
端到端加密
。 Pulsar broker 是無狀態(tài)的。
組件無狀態(tài)是件非常棒的事情，當一個組件過載時，你可以添加另一個組件來處理負載。
當新客戶端連接時，可以將它們定向到新實例。
但這并不能幫助到第一次被重載的實例。
你需要將一些工作從重載實例轉(zhuǎn)移到新的實例上。
換句話說，需要重新平衡負載。Pulsar 會自動進行
broker 負載平衡
。
它監(jiān)視 broker 的 CPU、內(nèi)存、網(wǎng)絡（不是磁盤，我提到的代理是無狀態(tài)的）的使用情況，并調(diào)整負載以保持平衡。
這意味著你不需要在單個 broker 熱點時擴容 broker 集群，除非 broker 集群服務能力到達上限。你也可以使用 Kafka 進行代理負載平衡。
但是，你必須多安裝一個程序，例如 LinkedIn 的
Cruise Control
。
或者也可以使用 Confluent 的
負載平衡器工具
（這款工具是需要付費的）。>>> 社區(qū)和生態(tài)系統(tǒng) <<<有人批評我沒有提到 Kafka 社區(qū)和生態(tài)系統(tǒng)的規(guī)模和豐富程度。
這個批評很中肯。
在社區(qū)和生態(tài)系統(tǒng)類別中，Kafka 確實比 Pulsar 做得好。
作為一個開源項目，Kafka 已經(jīng)開創(chuàng)了 5 年，所以它有一個更大的社區(qū)，有更多相關的項目，并且在 Stack Overflow 上有更多相關的問題與答案。隨著大家不斷貢獻新的組件和周邊集成，Pulsar 社區(qū)日益發(fā)展壯大，Slack 社區(qū)的小伙伴們都很友好，也樂于助人。
我還想補充一下：
Pulsar 在許多方面受到 Kafka 的啟發(fā)，并且站在了巨人 Kafka 的肩膀上。
Kafka 項目和社區(qū)值得稱贊與尊重。
有時候聽起來像是我不尊重 Kafka，其實我很尊重 Kafka，我只是對 Pulsar 更有好感罷了。我認為 Pulsar 是 Kafka 的
合理替代品
。
Pulsar 支持 Kafka 的大部分功能，而且 Pulsar 有更多優(yōu)勢（目前我列舉了 12 個）。
了解 Pulsar 的人越多，它的發(fā)展勢頭就越大。
如果你正在評估流和/或隊列系統(tǒng)，考慮一下
Apache Pulsar
吧。關于為什么選擇 Pulsar 而非 Kafka 就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
分享標題：為什么選擇Pulsar而非Kafka
本文路徑：
http://weahome.cn/article/ppjgpo.html
重慶分公司
重慶分公司
