選擇Pulsar而不是Kafka的7 大理由分別是什么

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

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

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

如果你用過(guò) Kafka，就一定知道分區(qū)是怎么回事。Kafka 中的所有主題都是分區(qū)的，這樣可以增加吞吐量。通過(guò)分區(qū)進(jìn)而劃分到不同的 broker，單個(gè)主題的處理速率可以得到大幅提升。但如果某些主題不需要太高的處理速率，又該怎么辦呢？對(duì)于這類(lèi)情況，如果能不考慮分區(qū)，避免隨之而來(lái)的 API 和管理工作，不是更好嗎？

Pulsar 就可以做到。如果只需要一個(gè)主題，可以使用一個(gè)主題而無(wú)需使用分區(qū)。如果需要保持多個(gè)消費(fèi)者實(shí)例的處理速率，也不需要使用分區(qū)，Pulsar 的共享訂閱可以達(dá)到這一目的。

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

Kafka 開(kāi)發(fā)團(tuán)隊(duì)預(yù)見(jiàn)了日志對(duì)于一個(gè)實(shí)時(shí)數(shù)據(jù)交換系統(tǒng)的重要性。日志通過(guò)追加的方式寫(xiě)入系統(tǒng)，寫(xiě)入速度很快。日志中的數(shù)據(jù)是串行的，可以按照寫(xiě)入的順序快速讀取數(shù)據(jù)。相比隨機(jī)讀取和寫(xiě)入，串行讀取和寫(xiě)入速度更快。對(duì)于任何一個(gè)提供數(shù)據(jù)保證的系統(tǒng)來(lái)說(shuō)，持久化存儲(chǔ)方面的交互都是一個(gè)瓶頸，而日志抽象最大限度地提升了這方面的效率。

日志固然好，但當(dāng)數(shù)據(jù)量過(guò)大時(shí)，也會(huì)給我們帶來(lái)一些麻煩，單臺(tái)服務(wù)器上保存所有日志已經(jīng)成為一個(gè)挑戰(zhàn)。在日志占滿服務(wù)器存儲(chǔ)之后該怎么辦？如何進(jìn)行擴(kuò)容？或者保存日志的服務(wù)器宕機(jī)，需要重新從副本創(chuàng)建新的服務(wù)器時(shí)，該怎么辦？將日志從一臺(tái)服務(wù)器拷貝到另一臺(tái)服務(wù)器耗時(shí)很長(zhǎng)，特別是想要同時(shí)保持系統(tǒng)實(shí)時(shí)數(shù)據(jù)時(shí)，完成這個(gè)操作就更難了。

Pulsar 對(duì)日志進(jìn)行分段，從而避免了拷貝大塊的日志。通過(guò) BookKeeper， Pulsar 將日志分段分散到多臺(tái)不同的服務(wù)器上。也就是說(shuō)，日志不會(huì)保存在單臺(tái)服務(wù)器上，任何一臺(tái)服務(wù)器都不會(huì)成為整個(gè)系統(tǒng)的瓶頸。這使故障處理和擴(kuò)容更加簡(jiǎn)單，只需要加入新的服務(wù)器，而無(wú)需進(jìn)行再均衡處理。

對(duì)于云原生應(yīng)用程序開(kāi)發(fā)人員來(lái)說(shuō)，最喜歡的東西就是無(wú)狀態(tài)。無(wú)狀態(tài)組件啟動(dòng)速度快、可替換，還可以實(shí)現(xiàn)無(wú)縫擴(kuò)容。如果消息中間件也是無(wú)狀態(tài)的，那豈不是更好？

Kafka 不是無(wú)狀態(tài)的，每個(gè) broker 都包含了分區(qū)的所有日志，如果一個(gè) broker 宕機(jī)，不是所有 broker 都可以接替它的工作。如果工作負(fù)載太高，也不能隨意添加新的 broker 來(lái)分擔(dān)，而是必須與持有其分區(qū)副本的  broker 進(jìn)行狀態(tài)同步。

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

Pulsar 的 broker 是無(wú)狀態(tài)的，所以如果工作負(fù)載很高，可以直接添加新的 broker，快速接管工作負(fù)載。

跨域復(fù)制是 Pulsar 的拿手好戲。Pulsar 在設(shè)計(jì)之初就考慮到了這個(gè)特性，配置也很容易。無(wú)論是全局分布式應(yīng)用程序還是災(zāi)備方案，都可以通過(guò) Pulsar  搞定。

基準(zhǔn)測(cè)試（http://openmessaging.cloud/docs/benchmarks/pulsar/）表明，Pulsar 可以在提供較高吞吐量的同時(shí)保持較低的延遲。

Pulsar 提供了很多與 Kafka 相似的特性，比如跨域復(fù)制、流式消息處理（Pulsar Functions）、連接器（Pulsar IO）、基于 SQL 的主題查詢（Pulsar SQL）、schema registry，還有一些 Kafka 沒(méi)有的特性，比如分層存儲(chǔ)和多租戶。更贊的是，這些功能特性都是開(kāi)源的。