為什么選擇Pulsar而非Kafka

這篇文章給大家介紹為什么選擇 Pulsar 而非 Kafka ,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。

創(chuàng)新互聯是一家企業(yè)級云計算解決方案提供商,超15年IDC數據中心運營經驗。主營GPU顯卡服務器,站群服務器,成都服務器托管,海外高防服務器,服務器機柜,動態(tài)撥號VPS,海外云手機,海外云服務器,海外服務器租用托管等。

>>> 多租戶處理 <<<
 Pulsar 對多租戶的支持是一個很重要的特性。  在企業(yè)中,消息基礎架構會被多團隊、多項目使用。  為每個團隊(項目)分別維護一個獨立的消息系統集群代價過高且難以維護。

Pulsar 可以有  多個租戶  ,這些租戶可以有多個命名空間,以保持內容順序。  再加上每個命名空間的訪問控制、配額、速率限制等,可以想象,將來我們可以只使用一個集群就能處理多租戶問題。  其實不僅我們考慮到這個問題,Kafka 也會考慮。    


>>> Quorum 復制 <<<

接下來,我會講到很多細節(jié)。  要想確保消息不丟失,消息傳遞系統會配置每條消息生成 2 或 3 個副本,以防出錯。  Kafka 使用 follow-the-leader 模型來實現這一點。  Leader 存儲消息,而 follower 復制 leader 上的消息。  

一旦有足夠多的 follower 確認已經完成了復制,Kafka 就“高興”了。  Pulsar 使用   Quorum 模型  。  它把消息發(fā)送給一堆節(jié)點,一旦有足夠多的節(jié)點確認它們已經接收到消息,Pulsar 就很“高興”。

Quorum 復制更加民主,沒有這種 leader-follower 層次結構。  所有選票均等時,多數勝利。  但這與技術無關。  重要的是,隨著時間的推移,Quorum 復制傾向于提供更一致的行為。

這或許可以解釋為什么 Pulsar 具有更一致的延遲性能。    

事實上,Kafka 也一直在考慮使用 Quorum 復制來改善延遲一致性。  關于此,可以查看   KIP-250   中的討論。


>>> 分層存儲 <<<

像 Kafka 這樣的流處理系統,其一大優(yōu)點在于它能夠重放已經被消費的消息。  如果你第一次見到就很喜歡這些消息,則可以進行重播以更正某些內容,或圍繞它們構建新的應用程序,這也是很有趣的。

如果你非常喜歡這些消息,想把它們永遠保存下來,那該怎么辦?  比如,如果你在做  事件溯源  。  這聽起來很不錯,但永久可是  一段很長的時間  ,而且永久存儲消息也可能很貴,特別是存儲在高性能固態(tài)硬盤上。  這些硬盤需要維持消息系統保持良好的運行狀態(tài)。

如果能把那些舊消息(那些以后可能會再用到的消息)轉移到相對便宜的存儲解決方案中,是否可行呢?  如果可以使用像 Amazon S3 存儲桶這樣廉價的云存儲,那豈不是很棒嗎?  你可能已經猜到我要說什么了。

借助 Pulsar    分層存儲  ,你可以把那些舊消息自動推送到幾乎無限的、廉價的云存儲中,然后像檢索新消息一樣執(zhí)行相關操作。  我敢打賭,Kafka 希望擁有該功能。  沒錯,他們會的。
>>> 端到端加密 <<<

顯然,安全是很重要的,誰都不希望信息安全被偷窺。  當然,你會在客戶端和消息傳遞系統之間使用 TLS(在傳輸過程中加密)。  這樣做時,消息傳遞系統必須解密該連接,以便了解客戶端想要表達的內容。

 然后,它把未加密的消息保存在磁盤上。  當然,你會堅持對磁盤進行加密,這樣即使磁盤被偷,消息仍然是安全的(靜態(tài)加密)。  但在這兩種情況下,消息傳遞系統都需要有數據的密鑰。  如果不是這樣,那就是在處理一大堆莫名其妙的天書。

許多情況下,這種級別的加密已經足夠好了,但是如果你想要確保沒有人可以偷窺你的消息,則需要進行端到端加密。  生產者在發(fā)送消息之前使用與接收消息的使用者共享的密鑰對消息進行加密。  當消息保存在消息系統的磁盤上時,就會被加密,而消息系統沒有密鑰。  消息傳遞系統可以完成它的工作,但是你的消息對于消息傳遞系統來說是就像天書一樣,所以是十分安全的。

Pulsar 可以在其 Java 客戶端中進行  端到端加密  。    

>>> Broker 平衡 <<<

Pulsar broker 是無狀態(tài)的。  組件無狀態(tài)是件非常棒的事情,當一個組件過載時,你可以添加另一個組件來處理負載。  當新客戶端連接時,可以將它們定向到新實例。  但這并不能幫助到第一次被重載的實例。  你需要將一些工作從重載實例轉移到新的實例上。  換句話說,需要重新平衡負載。

Pulsar 會自動進行   broker 負載平衡  。  它監(jiān)視 broker 的 CPU、內存、網絡(不是磁盤,我提到的代理是無狀態(tài)的)的使用情況,并調整負載以保持平衡。  這意味著你不需要在單個 broker 熱點時擴容 broker 集群,除非 broker 集群服務能力到達上限。

你也可以使用 Kafka 進行代理負載平衡。  但是,你必須多安裝一個程序,例如 LinkedIn 的   Cruise Control  。  或者也可以使用 Confluent 的  負載平衡器工具  (這款工具是需要付費的)。


>>> 社區(qū)和生態(tài)系統 <<<

有人批評我沒有提到 Kafka 社區(qū)和生態(tài)系統的規(guī)模和豐富程度。  這個批評很中肯。  在社區(qū)和生態(tài)系統類別中,Kafka 確實比 Pulsar 做得好。  作為一個開源項目,Kafka 已經開創(chuàng)了 5 年,所以它有一個更大的社區(qū),有更多相關的項目,并且在 Stack Overflow 上有更多相關的問題與答案。

隨著大家不斷貢獻新的組件和周邊集成,Pulsar 社區(qū)日益發(fā)展壯大,Slack 社區(qū)的小伙伴們都很友好,也樂于助人。  我還想補充一下:  Pulsar 在許多方面受到 Kafka 的啟發(fā),并且站在了巨人 Kafka 的肩膀上。  Kafka 項目和社區(qū)值得稱贊與尊重。  有時候聽起來像是我不尊重 Kafka,其實我很尊重 Kafka,我只是對 Pulsar 更有好感罷了。


>>> KAFKA 的合理替代品 <<<

我認為 Pulsar 是 Kafka 的  合理替代品  。  Pulsar 支持 Kafka 的大部分功能,而且 Pulsar 有更多優(yōu)勢(目前我列舉了 12 個)。  了解 Pulsar 的人越多,它的發(fā)展勢頭就越大。  如果你正在評估流和/或隊列系統,考慮一下   Apache Pulsar   吧。

關于為什么選擇 Pulsar 而非 Kafka 就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。

網站題目:為什么選擇Pulsar而非Kafka
標題來源:http://muchs.cn/article30/ppjgpo.html

成都網站建設公司_創(chuàng)新互聯,為您提供動態(tài)網站、用戶體驗、搜索引擎優(yōu)化、電子商務、關鍵詞優(yōu)化App開發(fā)

廣告

聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯

成都網站建設公司