建站
咨詢
售后
建站咨詢
新聞中心
選擇Pulsar而不是Kafka的7 大理由分別是什么，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
目前成都創(chuàng)新互聯(lián)已為成百上千的企業(yè)提供了網(wǎng)站建設(shè)、域名、雅安服務(wù)器托管、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計、信宜網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
構(gòu)建消息基礎(chǔ)架構(gòu)的第一步是選擇合適的消息中間件技術(shù)。可選方案有很多，從各種開源框架（如 RabbitMQ、ActiveMQ、NATS）到一些商用產(chǎn)品（如 IBM MQ 或者 RedHat AMQ），除此之外，我們還有 Kafka。不過，我們最后沒有使用 Kafka，而是選擇了 Pulsar。
為什么最終選擇了 Pulsar？下面列出了選擇 Pulsar 而不是 Kafka 的 7 大理由。
Pulsar 就像一個合二為一的產(chǎn)品，不僅可以像 Kafka 那樣處理高速率的實時場景，還支持標準的消息隊列模式，比如多消費者、失效備援訂閱和消息扇出等等。Pulsar 會自動跟蹤客戶端的讀取位置，并把這些信息保存在高性能的分布式 ledger（BookKeeper）當中。
與 Kafka 不同，Pulsar 具備傳統(tǒng)消息隊列（如 RabbitMQ）的功能，因此，只需要運行一個 Pulsar 系統(tǒng)就可以同時處理實時流和消息隊列。
如果你用過 Kafka，就一定知道分區(qū)是怎么回事。Kafka 中的所有主題都是分區(qū)的，這樣可以增加吞吐量。通過分區(qū)進而劃分到不同的 broker，單個主題的處理速率可以得到大幅提升。但如果某些主題不需要太高的處理速率，又該怎么辦呢？對于這類情況，如果能不考慮分區(qū)，避免隨之而來的 API 和管理工作，不是更好嗎？
Pulsar 就可以做到。如果只需要一個主題，可以使用一個主題而無需使用分區(qū)。如果需要保持多個消費者實例的處理速率，也不需要使用分區(qū)，Pulsar 的共享訂閱可以達到這一目的。
如果確實需要分區(qū)來進一步提升性能，Pulsar 也可以支持分區(qū)的使用。
Kafka 開發(fā)團隊預(yù)見了日志對于一個實時數(shù)據(jù)交換系統(tǒng)的重要性。日志通過追加的方式寫入系統(tǒng)，寫入速度很快。日志中的數(shù)據(jù)是串行的，可以按照寫入的順序快速讀取數(shù)據(jù)。相比隨機讀取和寫入，串行讀取和寫入速度更快。對于任何一個提供數(shù)據(jù)保證的系統(tǒng)來說，持久化存儲方面的交互都是一個瓶頸，而日志抽象最大限度地提升了這方面的效率。
日志固然好，但當數(shù)據(jù)量過大時，也會給我們帶來一些麻煩，單臺服務(wù)器上保存所有日志已經(jīng)成為一個挑戰(zhàn)。在日志占滿服務(wù)器存儲之后該怎么辦？如何進行擴容？或者保存日志的服務(wù)器宕機，需要重新從副本創(chuàng)建新的服務(wù)器時，該怎么辦？將日志從一臺服務(wù)器拷貝到另一臺服務(wù)器耗時很長，特別是想要同時保持系統(tǒng)實時數(shù)據(jù)時，完成這個操作就更難了。
Pulsar 對日志進行分段，從而避免了拷貝大塊的日志。通過 BookKeeper， Pulsar 將日志分段分散到多臺不同的服務(wù)器上。也就是說，日志不會保存在單臺服務(wù)器上，任何一臺服務(wù)器都不會成為整個系統(tǒng)的瓶頸。這使故障處理和擴容更加簡單，只需要加入新的服務(wù)器，而無需進行再均衡處理。
對于云原生應(yīng)用程序開發(fā)人員來說，最喜歡的東西就是無狀態(tài)。無狀態(tài)組件啟動速度快、可替換，還可以實現(xiàn)無縫擴容。如果消息中間件也是無狀態(tài)的，那豈不是更好？
Kafka 不是無狀態(tài)的，每個 broker 都包含了分區(qū)的所有日志，如果一個 broker 宕機，不是所有 broker 都可以接替它的工作。如果工作負載太高，也不能隨意添加新的 broker 來分擔，而是必須與持有其分區(qū)副本的 broker 進行狀態(tài)同步。
在 Pulsar 架構(gòu)中，broker 是無狀態(tài)的。但是完全無狀態(tài)的系統(tǒng)無法持久化消息，所以 Pulsar 不是依靠 broker 來實現(xiàn)消息持久化的。在 Pulsar 架構(gòu)中，數(shù)據(jù)的分發(fā)和保存是相互獨立的。broker 從生產(chǎn)者接收數(shù)據(jù)，然后將數(shù)據(jù)發(fā)送給消費者，但數(shù)據(jù)保存在 BookKeeper 中。
Pulsar 的 broker 是無狀態(tài)的，所以如果工作負載很高，可以直接添加新的 broker，快速接管工作負載。
跨域復(fù)制是 Pulsar 的拿手好戲。Pulsar 在設(shè)計之初就考慮到了這個特性，配置也很容易。無論是全局分布式應(yīng)用程序還是災(zāi)備方案，都可以通過 Pulsar 搞定。
基準測試（http://openmessaging.cloud/docs/benchmarks/pulsar/）表明，Pulsar 可以在提供較高吞吐量的同時保持較低的延遲。
Pulsar 提供了很多與 Kafka 相似的特性，比如跨域復(fù)制、流式消息處理（Pulsar Functions）、連接器（Pulsar IO）、基于 SQL 的主題查詢（Pulsar SQL）、schema registry，還有一些 Kafka 沒有的特性，比如分層存儲和多租戶。更贊的是，這些功能特性都是開源的。
關(guān)于選擇Pulsar而不是Kafka的7 大理由分別是什么問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。
網(wǎng)站標題：選擇Pulsar而不是Kafka的7大理由分別是什么
文章路徑：http://ef60e0e.cn/article/gosjoj.html
