對于開發(fā)云原生分布式應(yīng)用程序的開發(fā)人員來說，他們應(yīng)該把更多的精力放在應(yīng)用程序和微服務(wù)上，而不是把時間浪費(fèi)在處理復(fù)雜的消息基礎(chǔ)設(shè)施上，他們需要一些解決方案幫助他們管理好這些基礎(chǔ)設(shè)施。

構(gòu)建消息基礎(chǔ)設(shè)施的第一步是選擇合適的消息中間件技術(shù)。在這方面有很多選擇，從各種開源框架(如 RabbitMQ、ActiveMQ、NATS)到一些商用產(chǎn)品(如 IBM MQ 或者 RedHat AMQ)。當(dāng)然，除了這些之外，我們還有 Kafka。不過，我們最后并沒有選擇 Kafka，而是選擇了 Pulsar。

為什么我們最終選擇了 Pulsar?下面列出了選擇 Pulsar 而不是 Kafka 的 7 大理由。

1. 流式處理和隊(duì)列的合體

Pulsar 就像是一個合二為一的產(chǎn)品，不僅可以像 Kafka 那樣處理高速率的實(shí)時場景，還能支持標(biāo)準(zhǔn)的消息隊(duì)列模式，比如多消費(fèi)者、失效備援訂閱和消息扇出，等等。Pulsar 會自動跟蹤客戶端的讀取位置，并把這些信息保存在高性能的分布式 ledger(BookKeeper)當(dāng)中。

與 Kafka 不一樣的是，Pulsar 具備傳統(tǒng)消息隊(duì)列(如 RabbitMQ)那樣的功能，因此，只需要運(yùn)行一個 Pulsar 系統(tǒng)就可以同時處理實(shí)時流和消息隊(duì)列。

2. 支持分區(qū)，但不是必需的

如果你用過 Kafka，就一定知道分區(qū)是怎么回事。Kafka 中的所有主題都是分區(qū)的，這樣可以增加吞吐量。通過分區(qū)，單個主題的處理速率可以得到大幅提升。但如果某些主題不需要太高的處理速率，那該怎么辦?對于這類情況，就不需要考慮分區(qū)了，以避免復(fù)雜的 API 和管理方面的工作，這樣不是更好嗎?

Pulsar 就可以做到。如果你只需要一個主題，而不需要分區(qū)，那使用一個主題就好了。如果你需要使用多個消費(fèi)者實(shí)例來提升處理速率，其實(shí)也不需要使用分區(qū)，因?yàn)?Pulsar 的共享訂閱可以達(dá)到你的目的。

如果你確實(shí)需要分區(qū)來進(jìn)一步提升性能，你也可以使用分區(qū)。

3. 日志固然不錯，但 ledger 更勝一籌

Kafka 開發(fā)團(tuán)隊(duì)預(yù)見了日志對于一個實(shí)時數(shù)據(jù)交換系統(tǒng)的重要性。因?yàn)槿罩臼峭ㄟ^追加的方式寫入系統(tǒng)的，所以數(shù)據(jù)寫入速度很快。又因?yàn)槿罩局械臄?shù)據(jù)是串行的，所以可以按照寫入的順序快速讀取數(shù)據(jù)。相比隨機(jī)讀取和寫入，串行讀取和寫入速度更快。對于任何一個提供數(shù)據(jù)保證的系統(tǒng)來說，持久化存儲方面的交互都是一個瓶頸，而日志抽象最大限度地提升了這方面的效率。

日志固然是好，但當(dāng)它們的量增長到很大的時候，也會給我們帶來一些麻煩。在單臺服務(wù)器上保存所有日志已經(jīng)成為一個挑戰(zhàn)。在服務(wù)器存儲被日志填滿之后該怎么辦?如何進(jìn)行伸縮?或者保存日志的服務(wù)器宕機(jī)，需要重新從副本創(chuàng)建新的服務(wù)器，該怎么辦?將日志從一臺服務(wù)器拷貝到另一臺服務(wù)器是很耗費(fèi)時間的，特別是如果你想要在保持系統(tǒng)實(shí)時數(shù)據(jù)的情況下完成這個操作就更難了。

Pulsar 對日志進(jìn)行分段，從而避免了拷貝大塊的日志。它通過 BookKeeper 將日志分段分散到多臺不同的服務(wù)器上。也就是說，日志并不是保存在單臺服務(wù)器上，所以任何一臺服務(wù)器都不會成為整個系統(tǒng)的瓶頸。這樣就可以更容易地處理故障，要進(jìn)行伸縮也很容易，只需要加入新的服務(wù)器，不需要進(jìn)行再均衡。

4. 無狀態(tài)

對于云原生應(yīng)用程序開發(fā)人員來說，他們最喜歡的東西就是無狀態(tài)。無狀態(tài)組件啟動速度快，可替換，還可以實(shí)現(xiàn)無縫的伸縮。如果消息中間件也是無狀態(tài)的，那豈不是更好?

Kafka 不是無狀態(tài)的，因?yàn)槊總� broker 都包含了分區(qū)的所有日志，如果一個 broker 宕機(jī)，并非任意一 broker 都可以接替它的工作。如果工作負(fù)載太高，也不能隨意添加新的 broker 來分擔(dān)。broker 之間必須進(jìn)行狀態(tài)同步。

在 Pulsar 架構(gòu)中，broker 是無狀態(tài)的。但是完全無狀態(tài)的系統(tǒng)是無法用來持久化消息的，所以 Pulsar 其實(shí)是有維護(hù)在狀態(tài)的，只是不是在 broker 上。在 Pulsar 架構(gòu)中，數(shù)據(jù)的分發(fā)和保存是相互獨(dú)立的。broker 從生產(chǎn)者接收數(shù)據(jù)，然后將數(shù)據(jù)發(fā)送給消費(fèi)者，但數(shù)據(jù)是保存在 BookKeeper 中的。

因?yàn)?Pulsar 的 broker 是無狀態(tài)的，所以如果工作負(fù)載很高，就可以直接添加新的 broker。

5. 簡單的跨域復(fù)制

跨域復(fù)制是 Pulsar 的拿手好戲。Pulsar 在設(shè)計之初就考慮到了這個特性，配置也很容易。要搭建一個全球化的分布式 Pulsar 集群，并不需要你擁有博士學(xué)位。

6. 穩(wěn)定的表現(xiàn)

一些基準(zhǔn)測試表明，Pulsar 可以在提供較高吞吐量的同時保持較低的延遲。

7. 完全開源

Pulsar 提供了很多與 Kafka 相似的特性，比如跨域復(fù)制、流式消息處理(Pulsar Function)、連接器(Pulsar IO)、基于 SQL 的主題查詢(Pulsar SQL)、schema registry，還有一些 Kafka 沒有的特性，比如分層存儲和多租戶，所有這些特性都是開源的。

結(jié)論

為此，我們有理由選擇 Pulsar 來構(gòu)建我們的消息基礎(chǔ)設(shè)施服務(wù)。其實(shí)除了上述這些原因之外，使用 Pulsar 還有其他好處，比如多租戶、命名空間、認(rèn)證和授權(quán)、文檔、對 Kubernetes 的友好支持。

英文原文：https://kafkaesque.io/7-reasons-we-choose-apache-pulsar-over-apache-kafka/

標(biāo)簽： [db:TAGG]

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。