一年一度由世界知名科技媒體 InfoWorld 評(píng)選的 Bossie Awards 于 9 月 26 日公布，本次 Bossie Awards 評(píng)選出了最佳數(shù)據(jù)庫與數(shù)據(jù)分析平臺(tái)獎(jiǎng)、最佳軟件開發(fā)工具獎(jiǎng)、最佳機(jī)器學(xué)習(xí)項(xiàng)目獎(jiǎng)等多個(gè)獎(jiǎng)項(xiàng)。在最佳開源數(shù)據(jù)庫與數(shù)據(jù)分析平臺(tái)獎(jiǎng)中，之前曾連續(xù)兩年入選的 Kafka 意外滑鐵盧落選，取而代之的是新興項(xiàng)目 Pulsar。

Bossie Awards 中對(duì) Pulsar 點(diǎn)評(píng)如下：“Pulsar 旨在取代 Apache Kafka 多年的主宰地位。 Pulsar 在很多情況下提供了比 Kafka 更快的吞吐量和更低的延遲，并為開發(fā)人員提供了一組兼容的 API，讓他們可以很輕松地從 Kafka 切換到 Pulsar。Pulsar 的最大優(yōu)點(diǎn)在于它提供了比 Apache Kafka 更簡(jiǎn)單明了、更健壯的一系列操作功能，特別在解決可觀察性、地域復(fù)制和多租戶方面的問題。在運(yùn)行大型 Kafka 集群方面感覺有困難的企業(yè)可以考慮轉(zhuǎn)向使用 Pulsar。”

AI 前線近一年發(fā)布了不少 Pulsar 的技術(shù)文章，我們經(jīng)常被問到一個(gè)問題：Apache Pulsar 和 Apache Kafka 到底有什么不同?今天，大家所期待的對(duì)比文終于來了!本文將詳述 Pulsar 和 Kafka 消息模型之間的區(qū)別，以及 Pulsar 與 Kafka 在系統(tǒng)架構(gòu)設(shè)計(jì)方面的差異。

在用戶選擇一個(gè)消息系統(tǒng)時(shí)，消息模型是用戶首先考慮的事情。消息模型應(yīng)涵蓋以下 3 個(gè)方面：

1、消息消費(fèi)——如何發(fā)送和消費(fèi)消息;
2、消息確認(rèn)(ack)——如何確認(rèn)消息;
3、消息保存——消息保留多長(zhǎng)時(shí)間，觸發(fā)消息刪除的原因以及怎樣刪除;

消息消費(fèi)模型

在實(shí)時(shí)流式架構(gòu)中，消息傳遞可以分為兩類：隊(duì)列(Queue)和流(Stream)。

隊(duì)列(Queue)模型

隊(duì)列模型主要是采用無序或者共享的方式來消費(fèi)消息。通過隊(duì)列模型，用戶可以創(chuàng)建多個(gè)消費(fèi)者從單個(gè)管道中接收消息;當(dāng)一條消息從隊(duì)列發(fā)送出來后，多個(gè)消費(fèi)者中的只有一個(gè)(任何一個(gè)都有可能)接收和消費(fèi)這條消息。消息系統(tǒng)的具體實(shí)現(xiàn)決定了最終哪個(gè)消費(fèi)者實(shí)際接收到消息。

隊(duì)列模型通常與無狀態(tài)應(yīng)用程序一起結(jié)合使用。無狀態(tài)應(yīng)用程序不關(guān)心排序，但它們確實(shí)需要能夠確認(rèn)(ack)或刪除單條消息，以及盡可能地?cái)U(kuò)展消費(fèi)并行性的能力。典型的基于隊(duì)列模型的消息系統(tǒng)包括 RabbitMQ 和 RocketMQ。

流式(Stream)模型

相比之下，流模型要求消息的消費(fèi)嚴(yán)格排序或獨(dú)占消息消費(fèi)。對(duì)于一個(gè)管道，使用流式模型，始終只會(huì)有一個(gè)消費(fèi)者使用和消費(fèi)消息。消費(fèi)者按照消息寫入管道的確切順序接收從管道發(fā)送的消息。

流模型通常與有狀態(tài)應(yīng)用程序相關(guān)聯(lián)。有狀態(tài)的應(yīng)用程序更加關(guān)注消息的順序及其狀態(tài)。消息的消費(fèi)順序決定了有狀態(tài)應(yīng)用程序的狀態(tài)。消息的順序?qū)⒂绊憫?yīng)用程序處理邏輯的正確性。

在面向微服務(wù)或事件驅(qū)動(dòng)的體系結(jié)構(gòu)中，隊(duì)列模型和流模型都是必需的。

Pulsar 的消息消費(fèi)模型

Apache Pulsar 通過“訂閱”，抽象出了統(tǒng)一的: producer-topic-subscription-consumer 消費(fèi)模型。Pulsar 的消息模型既支持隊(duì)列模型，也支持流模型。

在 Pulsar 的消息消費(fèi)模型中，Topic 是用于發(fā)送消息的通道。每一個(gè) Topic 對(duì)應(yīng)著 Apache BookKeeper 中的一個(gè)分布式日志。發(fā)布者發(fā)布的每條消息只在 Topic 中存儲(chǔ)一次;存儲(chǔ)的過程中，BookKeeper 會(huì)將消息復(fù)制存儲(chǔ)在多個(gè)存儲(chǔ)節(jié)點(diǎn)上;Topic 中的每條消息，可以根據(jù)消費(fèi)者的訂閱需求，多次被使用，每個(gè)訂閱對(duì)應(yīng)一個(gè)消費(fèi)者組(Consumer Group)。

主題(Topic)是消費(fèi)消息的真實(shí)來源。盡管消息僅在主題(Topic)上存儲(chǔ)一次，但是用戶可以有不同的訂閱方式來消費(fèi)這些消息：

♦ 消費(fèi)者被組合在一起以消費(fèi)消息，每個(gè)消費(fèi)組是一個(gè)訂閱。

♦ 每個(gè) Topic 可以有不同的消費(fèi)組。

♦ 每組消費(fèi)者都是對(duì)主題的一個(gè)訂閱。

♦ 每組消費(fèi)者可以擁有自己不同的消費(fèi)方式： 獨(dú)占(Exclusive)，故障切換(Failover)或共享(Share)。

Pulsar 通過這種模型，將隊(duì)列模型和流模型這兩種模型結(jié)合在了一起，提供了統(tǒng)一的 API 接口。 這種模型，既不會(huì)影響消息系統(tǒng)的性能，也不會(huì)帶來額外的開銷，同時(shí)還為用戶提供了更多靈活性，方便用戶程序以最匹配模式來使用消息系統(tǒng)。

獨(dú)占訂閱(Stream 流模型)

顧名思義，獨(dú)占訂閱中，在任何時(shí)間，一個(gè)消費(fèi)者組(訂閱)中有且只有一個(gè)消費(fèi)者來消費(fèi) Topic 中的消息。下圖是獨(dú)占訂閱的示例。在這個(gè)示例中有一個(gè)有訂閱 A 的活躍消費(fèi)者 A-0，消息 m0 到 m4 按順序傳送并由 A-0 消費(fèi)。如果另一個(gè)消費(fèi)者 A-1 想要附加到訂閱 A，則是不被允許的。

 

 

故障切換(Stream 流模型)

使用故障切換訂閱，多個(gè)消費(fèi)者(Consumer)可以附加到同一訂閱。 但是，一個(gè)訂閱中的所有消費(fèi)者，只會(huì)有一個(gè)消費(fèi)者被選為該訂閱的主消費(fèi)者。 其他消費(fèi)者將被指定為故障轉(zhuǎn)移消費(fèi)者。

當(dāng)主消費(fèi)者斷開連接時(shí)，分區(qū)將被重新分配給其中一個(gè)故障轉(zhuǎn)移消費(fèi)者，而新分配的消費(fèi)者將成為新的主消費(fèi)者。 發(fā)生這種情況時(shí)，所有未確認(rèn)(ack)的消息都將傳遞給新的主消費(fèi)者。 這類似于 Apache Kafka 中的 Consumer partition rebalance。

下圖是故障切換訂閱的示例。 消費(fèi)者 B-0 和 B-1 通過訂閱 B 訂閱消費(fèi)消息。B-0 是主消費(fèi)者并接收所有消息。 B-1 是故障轉(zhuǎn)移消費(fèi)者，如果消費(fèi)者 B-0 出現(xiàn)故障，它將接管消費(fèi)。

 

 

共享訂閱(Queue 隊(duì)列模型)

使用共享訂閱，在同一個(gè)訂閱背后，用戶按照應(yīng)用的需求掛載任意多的消費(fèi)者。 訂閱中的所有消息以循環(huán)分發(fā)形式發(fā)送給訂閱背后的多個(gè)消費(fèi)者，并且一個(gè)消息僅傳遞給一個(gè)消費(fèi)者。

當(dāng)消費(fèi)者斷開連接時(shí)，所有傳遞給它但是未被確認(rèn)(ack)的消息將被重新分配和組織，以便發(fā)送給該訂閱上剩余的剩余消費(fèi)者。

下圖是共享訂閱的示例。 消費(fèi)者 C-1，C-2 和 C-3 都在同一主題上消費(fèi)消息。 每個(gè)消費(fèi)者接收大約所有消息的 1/3。

如果想提高消費(fèi)的速度，用戶不需要不增加分區(qū)數(shù)量，只需要在同一個(gè)訂閱中添加更多的消費(fèi)者。

 

 

三種訂閱模式的選擇

獨(dú)占和故障切換訂閱，僅允許一個(gè)消費(fèi)者來使用和消費(fèi)每個(gè)對(duì)主題的訂閱。這兩種模式都按主題分區(qū)順序使用消息。它們最適用于需要嚴(yán)格消息順序的流(Stream)用例。

共享訂閱允許每個(gè)主題分區(qū)有多個(gè)消費(fèi)者。同一訂閱中的每個(gè)消費(fèi)者僅接收主題分區(qū)的一部分消息。共享訂閱最適用于不需要保證消息順序的隊(duì)列(Queue)的使用模式，并且可以按照需要任意擴(kuò)展消費(fèi)者的數(shù)量。

Pulsar 中的訂閱實(shí)際上與 Apache Kafka 中的 Consumer Group 的概念類似。創(chuàng)建訂閱的操作很輕量化，而且具有高度可擴(kuò)展性，用戶可以根據(jù)應(yīng)用的需要?jiǎng)?chuàng)建任意數(shù)量的訂閱。

對(duì)同一主題的不同訂閱，也可以采用不同的訂閱類型。比如用戶可以在同一主題上可以提供一個(gè)包含 3 個(gè)消費(fèi)者的故障切換訂閱，同時(shí)也提供一個(gè)包含 20 個(gè)消費(fèi)者的共享訂閱，并且可以在不改變分區(qū)數(shù)量的情況下，向共享訂閱添加更多的消費(fèi)者。

下圖描繪了一個(gè)包含 3 個(gè)訂閱 A，B 和 C 的主題，并說明了消息如何從生產(chǎn)者流向消費(fèi)者。

 

 

除了統(tǒng)一消息 API 之外，由于 Pulsar 主題分區(qū)實(shí)際上是存儲(chǔ)在 Apache BookKeeper 中，它還提供了一個(gè)讀取 API(Reader)，類似于消費(fèi)者 API(但 Reader 沒有游標(biāo)管理)，以便用戶完全控制如何使用 Topic 中的消息。

Pulsar 的消息確認(rèn)(ACK)

由于分布式系統(tǒng)的特性，當(dāng)使用分布式消息系統(tǒng)時(shí)，可能會(huì)發(fā)生故障。比如在消費(fèi)者從消息系統(tǒng)中的主題消費(fèi)消息的過程中，消費(fèi)消息的消費(fèi)者和服務(wù)于主題分區(qū)的消息代理(Broker)都可能發(fā)生錯(cuò)誤。消息確認(rèn)(ACK)的目的就是保證當(dāng)發(fā)生這樣的故障后，消費(fèi)者能夠從上一次停止的地方恢復(fù)消費(fèi)，保證既不會(huì)丟失消息，也不會(huì)重復(fù)處理已經(jīng)確認(rèn)(ACK)的消息。

在 Apache Kafka 中，恢復(fù)點(diǎn)通常稱為 Offset，更新恢復(fù)點(diǎn)的過程稱為消息確認(rèn)或提交 Offset。

在 Apache Pulsar 中，每個(gè)訂閱中都使用一個(gè)專門的數(shù)據(jù)結(jié)構(gòu)–游標(biāo)(Cursor)來跟蹤訂閱中的每條消息的確認(rèn)(ACK)狀態(tài)。每當(dāng)消費(fèi)者在主題分區(qū)上確認(rèn)消息時(shí)，游標(biāo)都會(huì)更新。更新游標(biāo)可確保消費(fèi)者不會(huì)再次收到消息。

Apache Pulsar 提供兩種消息確認(rèn)方法，單條確認(rèn)(Individual Ack)和累積確認(rèn)(Cumulative Ack)。通過累積確認(rèn)，消費(fèi)者只需要確認(rèn)它收到的最后一條消息。主題分區(qū)中的所有消息(包括)提供消息 ID 將被標(biāo)記為已確認(rèn)，并且不會(huì)再次傳遞給消費(fèi)者。累積確認(rèn)與 Apache Kafka 中的 Offset 更新類似。

Apache Pulsar 可以支持消息的單條確認(rèn)，也就是選擇性確認(rèn)。消費(fèi)者可以單獨(dú)確認(rèn)一條消息。 被確認(rèn)后的消息將不會(huì)被重新傳遞。下圖說明了單條確認(rèn)和累積確認(rèn)的差異(灰色框中的消息被確認(rèn)并且不會(huì)被重新傳遞)。在圖的上半部分，它顯示了累計(jì)確認(rèn)的一個(gè)例子，M12 之前的消息被標(biāo)記為 acked。在圖的下半部分，它顯示了單獨(dú)進(jìn)行 acking 的示例。僅確認(rèn)消息 M7 和 M12 - 在消費(fèi)者失敗的情況下，除了 M7 和 M12 之外，其他所有消息將被重新傳送。

 

 

獨(dú)占訂閱或故障切換訂閱的消費(fèi)者能夠?qū)ο�息進(jìn)行單條確認(rèn)和累積確認(rèn);共享訂閱的消費(fèi)者只允許對(duì)消息進(jìn)行單條確認(rèn)。單條確認(rèn)消息的能力為處理消費(fèi)者故障提供了更好的體驗(yàn)。對(duì)于某些應(yīng)用來說，處理一條消息可能需要很長(zhǎng)時(shí)間或者非常昂貴，防止重新傳送已經(jīng)確認(rèn)的消息非常重要。

這個(gè)管理 Ack 的專門的數(shù)據(jù)結(jié)構(gòu)–游標(biāo)(Cursor)，由 Broker 來管理，利用 BookKeeper 的 Ledger 提供存儲(chǔ)，在后面的文章中我們會(huì)介紹更多的關(guān)于游標(biāo)(Cursor)的細(xì)節(jié)。

Apache Pulsar 提供了靈活的消息消費(fèi)訂閱類型和消息確認(rèn)方法，通過簡(jiǎn)單的統(tǒng)一的 API，就可以支持各種消息和流的使用場(chǎng)景。

Pulsar 的消息保留(Retention)

在消息被確認(rèn)后，Pulsar 的 Broker 會(huì)更新對(duì)應(yīng)的游標(biāo)。當(dāng) Topic 里面中的一條消息，被所有的訂閱都確認(rèn) ack 后，才能刪除這條消息。Pulsar 還允許通過設(shè)置保留時(shí)間，將消息保留更長(zhǎng)時(shí)間，即使所有訂閱已經(jīng)確認(rèn)消費(fèi)了它們。

下圖說明了如何在有 2 個(gè)訂閱的主題中保留消息。訂閱 A 在 M6 和訂閱 B 已經(jīng)消耗了 M10 之前的所有消息之前已經(jīng)消耗了所有消息。這意味著 M6 之前的所有消息(灰色框中)都可以安全刪除。訂閱 A 仍未使用 M6 和 M9 之間的消息，無法刪除它們。如果主題配置了消息保留期，則消息 M0 到 M5 將在配置的時(shí)間段內(nèi)保持不變，即使 A 和 B 已經(jīng)確認(rèn)消費(fèi)了它們。

 

 

在消息保留策略中，Pulsar 還支持消息生存時(shí)間(TTL)。如果消息未在配置的 TTL 時(shí)間段內(nèi)被任何消費(fèi)者使用，則消息將自動(dòng)標(biāo)記為已確認(rèn)。 消息保留期消息 TTL 之間的區(qū)別在于：消息保留期作用于標(biāo)記為已確認(rèn)并設(shè)置為已刪除的消息，而 TTL 作用于未 ack 的消息。 上面的圖例中說明了 Pulsar 中的 TTL。 例如，如果訂閱 B 沒有活動(dòng)消費(fèi)者，則在配置的 TTL 時(shí)間段過后，消息 M10 將自動(dòng)標(biāo)記為已確認(rèn)，即使沒有消費(fèi)者實(shí)際讀取該消息。

Pulsar VS. Kafka

通過以上幾個(gè)方面，我們對(duì) Pulsar 和 Kafka 在消息模型方面的不同點(diǎn)進(jìn)行一個(gè)總結(jié)。

模型概念

Kafka： Producer - topic - consumer group - consumer;

Pulsar：Producer - topic - subscription - consumer。

消費(fèi)模式

Kafka： 主要集中在流(Stream)模式，對(duì)單個(gè) partition 是獨(dú)占消費(fèi)，沒有共享(Queue)的消費(fèi)模式;

Pulsar：提供了統(tǒng)一的消息模型和 API。流(Stream)模式 – 獨(dú)占和故障切換訂閱方式;隊(duì)列(Queue)模式 – 共享訂閱的方式。

消息確認(rèn)(Ack)

Kafka： 使用偏移 Offset;

Pulsar：使用專門的 Cursor 管理。累積確認(rèn)和 Kafka 效果一樣;提供單條或選擇性確認(rèn)。

消息保留

Kafka：根據(jù)設(shè)置的保留期來刪除消息。有可能消息沒被消費(fèi)，過期后被刪除。 不支持 TTL。

Pulsar：消息只有被所有訂閱消費(fèi)后才會(huì)刪除，不會(huì)丟失數(shù)據(jù)。也允許設(shè)置保留期，保留被消費(fèi)的數(shù)據(jù)。支持 TTL。

對(duì)比總結(jié)

Apache Pulsar 將高性能的流(Apache Kafka 所追求的)和靈活的傳統(tǒng)隊(duì)列(RabbitMQ 所追求的)結(jié)合到一個(gè)統(tǒng)一的消息模型和 API 中。 Pulsar 使用統(tǒng)一的 API 為用戶提供一個(gè)支持流和隊(duì)列的系統(tǒng)，且具有同樣的高性能。 應(yīng)用程序可以將此統(tǒng)一的 API 用于高性能隊(duì)列和流式傳輸，而無需維護(hù)兩套系統(tǒng)：RabbitMQ 進(jìn)行隊(duì)列處理，Kafka 進(jìn)行流式處理。

系統(tǒng)架構(gòu)和設(shè)計(jì)理念

Pulsar 的分層架構(gòu)

Apache Pulsar 和其他消息系統(tǒng)最根本的不同是采用分層架構(gòu)。 Apache Pulsar 集群由兩層組成：無狀態(tài)服務(wù)層，由一組接收和傳遞消息的 Broker 組成;以及一個(gè)有狀態(tài)持久層，由一組名為 bookies 的 Apache BookKeeper 存儲(chǔ)節(jié)點(diǎn)組成，可持久化地存儲(chǔ)消息。 下圖顯示了 Apache Pulsar 的典型部署。

 

 

在 Pulsar 客戶端中提供生產(chǎn)者和消費(fèi)者(Producer & Consumer)接口，應(yīng)用程序使用 Pulsar 客戶端連接到 Broker 來發(fā)布和消費(fèi)消息。

Pulsar 客戶端不直接與存儲(chǔ)層 Apache BookKeeper 交互。 客戶端也沒有直接的 Zookeeper 訪問權(quán)限。這種隔離，為 Pulsar 實(shí)現(xiàn)安全的多租戶統(tǒng)一身份驗(yàn)證模型提供了基礎(chǔ)。

Apache Pulsar 為客戶端提供多種語言的支持，包括 Java，C ++，Python，Go 和 Websockets。

Apache Pulsar 還提供了一組兼容 Kafka 的 API，用戶可以通過簡(jiǎn)單地更新依賴關(guān)系并將客戶端指向 Pulsar 集群來遷移現(xiàn)有的 Kafka 應(yīng)用程序，這樣現(xiàn)有的 Kafka 應(yīng)用程序可以立即與 Apache Pulsar 一起使用，無需更改任何代碼。

Broker 層：無狀態(tài)服務(wù)層

Broker 集群在 Apache Pulsar 中形成無狀態(tài)服務(wù)層。服務(wù)層是“無狀態(tài)的”，因?yàn)?Broker 實(shí)際上并不在本地存儲(chǔ)任何消息數(shù)據(jù)。有關(guān) Pulsar 主題的消息，都被存儲(chǔ)在分布式日志存儲(chǔ)系統(tǒng)(Apache BookKeeper)中。我們將在下一節(jié)中更多地討論 BookKeeper。

每個(gè)主題分區(qū)(Topic Partition)由 Pulsar 分配給某個(gè) Broker，該 Broker 稱為該主題分區(qū)的所有者。 Pulsar 生產(chǎn)者和消費(fèi)者連接到主題分區(qū)的所有者 Broker，以向所有者代理發(fā)送消息并消費(fèi)消息。

如果一個(gè) Broker 失敗，Pulsar 會(huì)自動(dòng)將其擁有的主題分區(qū)移動(dòng)到群集中剩余的某一個(gè)可用 Broker 中。這里要說的一件事是：由于 Broker 是無狀態(tài)的，當(dāng)發(fā)生 Topic 的遷移時(shí)，Pulsar 只是將所有權(quán)從一個(gè) Broker 轉(zhuǎn)移到另一個(gè) Broker，在這個(gè)過程中，不會(huì)有任何數(shù)據(jù)復(fù)制發(fā)生。

下圖顯示了一個(gè)擁有 4 個(gè) Broker 的 Pulsar 集群，其中 4 個(gè)主題分區(qū)分布在 4 個(gè) Broker 中。每個(gè) Broker 擁有并為一個(gè)主題分區(qū)提供消息服務(wù)。

 

 

BookKeeper 層：持久化存儲(chǔ)層

Apache BookKeeper 是 Apache Pulsar 的持久化存儲(chǔ)層。 Apache Pulsar 中的每個(gè)主題分區(qū)本質(zhì)上都是存儲(chǔ)在 Apache BookKeeper 中的分布式日志。

每個(gè)分布式日志又被分為 Segment 分段。 每個(gè) Segment 分段作為 Apache BookKeeper 中的一個(gè) Ledger，均勻分布并存儲(chǔ)在 BookKeeper 群集中的多個(gè) Bookie(Apache BookKeeper 的存儲(chǔ)節(jié)點(diǎn))中。

Segment 的創(chuàng)建時(shí)機(jī)包括以下幾種：基于配置的 Segment 大小;基于配置的滾動(dòng)時(shí)間;或者當(dāng) Segment 的所有者被切換。

通過 Segment 分段的方式，主題分區(qū)中的消息可以均勻和平衡地分布在群集中的所有 Bookie 中。 這意味著主題分區(qū)的大小不僅受一個(gè)節(jié)點(diǎn)容量的限制; 相反，它可以擴(kuò)展到整個(gè) BookKeeper 集群的總?cè)萘俊?/p>

下面的圖說明了一個(gè)分為 x 個(gè) Segment 段的主題分區(qū)。 每個(gè) Segment 段存儲(chǔ) 3 個(gè)副本。 所有 Segment 都分布并存儲(chǔ)在 4 個(gè) Bookie 中。

 

 

Segment 為中心的存儲(chǔ)

存儲(chǔ)服務(wù)的分層的架構(gòu) 和 以 Segment 為中心的存儲(chǔ) 是 Apache Pulsar(使用 Apache BookKeeper)的兩個(gè)關(guān)鍵設(shè)計(jì)理念。 這兩個(gè)基礎(chǔ)為 Pulsar 提供了許多重要的好處：

♦ 無限制的主題分區(qū)存儲(chǔ)

♦ 即時(shí)擴(kuò)展，無需數(shù)據(jù)遷移

♦ 無縫 Broker 故障恢復(fù)

♦ 無縫集群擴(kuò)展

♦ 無縫的存儲(chǔ)(Bookie)故障恢復(fù)

♦ 獨(dú)立的可擴(kuò)展性

下面我們分別展開來看這幾個(gè)好處。

無限制的主題分區(qū)存儲(chǔ)

由于主題分區(qū)被分割成 Segment 并在 Apache BookKeeper 中以分布式方式存儲(chǔ)，因此主題分區(qū)的容量不受任何單一節(jié)點(diǎn)容量的限制。 相反，主題分區(qū)可以擴(kuò)展到整個(gè) BookKeeper 集群的總?cè)萘�，只需添�?Bookie 節(jié)點(diǎn)即可擴(kuò)展集群容量。 這是 Apache Pulsar 支持存儲(chǔ)無限大小的流數(shù)據(jù)，并能夠以高效，分布式方式處理數(shù)據(jù)的關(guān)鍵。 使用 Apache BookKeeper 的分布式日志存儲(chǔ)，對(duì)于統(tǒng)一消息服務(wù)和存儲(chǔ)至關(guān)重要。

即時(shí)擴(kuò)展，無需數(shù)據(jù)遷移

由于消息服務(wù)和消息存儲(chǔ)分為兩層，因此將主題分區(qū)從一個(gè) Broker 移動(dòng)到另一個(gè) Broker 幾乎可以瞬時(shí)內(nèi)完成，而無需任何數(shù)據(jù)重新平衡(將數(shù)據(jù)從一個(gè)節(jié)點(diǎn)重新復(fù)制到另一個(gè)節(jié)點(diǎn))。 這一特性對(duì)于高可用的許多方面至關(guān)重要，例如集群擴(kuò)展;對(duì) Broker 和 Bookie 失敗的快速應(yīng)對(duì)。 我將使用例子在下文更詳細(xì)地進(jìn)行解釋。

無縫 Broker 故障恢復(fù)

下圖說明了 Pulsar 如何處理 Broker 失敗的示例。 在例子中 Broker 2 因某種原因(例如停電)而斷開。 Pulsar 檢測(cè)到 Broker 2 已關(guān)閉，并立即將 Topic1-Part2 的所有權(quán)從 Broker 2 轉(zhuǎn)移到 Broker 3。在 Pulsar 中數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)服務(wù)分離，所以當(dāng)代理 3 接管 Topic1-Part2 的所有權(quán)時(shí)，它不需要復(fù)制 Partiton 的數(shù)據(jù)。 如果有新數(shù)據(jù)到來，它立即附加并存儲(chǔ)為 Topic1-Part2 中的 Segment x + 1。 Segment x + 1 被分發(fā)并存儲(chǔ)在 Bookie1, 2 和 4 上。因?yàn)樗�不需要重新�?fù)制數(shù)據(jù)，所以所有權(quán)轉(zhuǎn)移立即發(fā)生而不會(huì)犧牲主題分區(qū)的可用性。

 

 

無縫集群容量擴(kuò)展

下圖說明了 Pulsar 如何處理集群的容量擴(kuò)展。 當(dāng) Broker 2 將消息寫入 Topic1-Part2 的 Segment X 時(shí)，將 Bookie X 和 Bookie Y 添加到集群中。 Broker 2 立即發(fā)現(xiàn)新加入的 Bookies X 和 Y。然后 Broker 將嘗試將 Segment X + 1 和 X + 2 的消息存儲(chǔ)到新添加的 Bookie 中。 新增加的 Bookie 立刻被使用起來，流量立即增加，而不會(huì)重新復(fù)制任何數(shù)據(jù)。 除了機(jī)架感知和區(qū)域感知策略之外，Apache BookKeeper 還提供資源感知的放置策略，以確保流量在群集中的所有存儲(chǔ)節(jié)點(diǎn)之間保持平衡。

 

 

無縫的存儲(chǔ)(Bookie)故障恢復(fù)

下圖說明了 Pulsar(通過 Apache BookKeeper)如何處理 bookie 的磁盤故障。 這里有一個(gè)磁盤故障導(dǎo)致存儲(chǔ)在 bookie 2 上的 Segment 4 被破壞。Apache BookKeeper 后臺(tái)會(huì)檢測(cè)到這個(gè)錯(cuò)誤并進(jìn)行復(fù)制修復(fù)。

 

 

Apache BookKeeper 中的副本修復(fù)是 Segment(甚至是 Entry)級(jí)別的多對(duì)多快速修復(fù)，這比重新復(fù)制整個(gè)主題分區(qū)要精細(xì)，只會(huì)復(fù)制必須的數(shù)據(jù)。 這意味著 Apache BookKeeper 可以從 bookie 3 和 bookie 4 讀取 Segment 4 中的消息，并在 bookie 1 處修復(fù) Segment 4。所有的副本修復(fù)都在后臺(tái)進(jìn)行，對(duì) Broker 和應(yīng)用透明。

即使有 Bookie 節(jié)點(diǎn)出錯(cuò)的情況發(fā)生時(shí)，通過添加新的可用的 Bookie 來替換失敗的 Bookie，所有 Broker 都可以繼續(xù)接受寫入，而不會(huì)犧牲主題分區(qū)的可用性。

獨(dú)立的可擴(kuò)展性

由于消息服務(wù)層和持久存儲(chǔ)層是分開的，因此 Apache Pulsar 可以獨(dú)立地?cái)U(kuò)展存儲(chǔ)層和服務(wù)層。這種獨(dú)立的擴(kuò)展，更具成本效益：

當(dāng)您需要支持更多的消費(fèi)者或生產(chǎn)者時(shí)，您可以簡(jiǎn)單地添加更多的 Broker。主題分區(qū)將立即在 Brokers 中做平衡遷移，一些主題分區(qū)的所有權(quán)立即轉(zhuǎn)移到新的 Broker。

當(dāng)您需要更多存儲(chǔ)空間來將消息保存更長(zhǎng)時(shí)間時(shí)，您只需添加更多 Bookie。通過智能資源感知和數(shù)據(jù)放置，流量將自動(dòng)切換到新的 Bookie 中。 Apache Pulsar 中不會(huì)涉及到不必要的數(shù)據(jù)搬遷，不會(huì)將舊數(shù)據(jù)從現(xiàn)有存儲(chǔ)節(jié)點(diǎn)重新復(fù)制到新存儲(chǔ)節(jié)點(diǎn)。

Pulsar VS. Kafka

Apache Kafka 和 Apache Pulsar 都有類似的消息概念。 客戶端通過主題與消息系統(tǒng)進(jìn)行交互。 每個(gè)主題都可以分為多個(gè)分區(qū)。 然而，Apache Pulsar 和 Apache Kafka 之間的根本區(qū)別在于 Apache Kafka 是以分區(qū)為存儲(chǔ)中心，而 Apache Pulsar 是以 Segment 為存儲(chǔ)中心。

 

 

上圖顯示了以分區(qū)為中心和以 Segment 為中心的系統(tǒng)之間的差異。

在 Apache Kafka 中，分區(qū)只能存儲(chǔ)在單個(gè)節(jié)點(diǎn)上并復(fù)制到其他節(jié)點(diǎn)，其容量受最小節(jié)點(diǎn)容量的限制。這意味著容量擴(kuò)展需要對(duì)分區(qū)重新平衡，這反過來又需要重新復(fù)制整個(gè)分區(qū)，以平衡新添加的代理的數(shù)據(jù)和流量。

重新傳輸數(shù)據(jù)非常昂貴且容易出錯(cuò)，并且會(huì)消耗網(wǎng)絡(luò)帶寬和 I/O。維護(hù)人員在執(zhí)行此操作時(shí)必須非常小心，以避免破壞生產(chǎn)系統(tǒng)。

Kafka 中分區(qū)數(shù)據(jù)的重新拷貝不僅發(fā)生在以分區(qū)為中心的系統(tǒng)中的群集擴(kuò)展上。許多其他事情也會(huì)觸發(fā)數(shù)據(jù)重新拷貝，例如副本故障，磁盤故障或計(jì)算機(jī)的故障。在數(shù)據(jù)重新復(fù)制期間，分區(qū)通常不可用，直到數(shù)據(jù)重新復(fù)制完成。例如，如果您將分區(qū)配置為存儲(chǔ)為 3 個(gè)副本，這時(shí)，如果丟失了一個(gè)副本，則必須重新復(fù)制完整個(gè)分區(qū)后，分區(qū)才可以再次可用。

在用戶遇到故障之前，通常會(huì)忽略這種缺陷，因?yàn)樵S多情況下，在短時(shí)間內(nèi)僅是對(duì)內(nèi)存中緩存數(shù)據(jù)的讀取。當(dāng)數(shù)據(jù)被保存到磁盤后，用戶將越來越多地不可避免地遇到數(shù)據(jù)丟失，故障恢復(fù)的問題，特別是在需要將數(shù)據(jù)長(zhǎng)時(shí)間保存的場(chǎng)合。

相反，在 Apache Pulsar 中，同樣是以分區(qū)為邏輯單元，但是以 Segment 為物理存儲(chǔ)單元。分區(qū)隨著時(shí)間的推移會(huì)進(jìn)行分段，并在整個(gè)集群中均衡分布，旨在有效地迅速地?cái)U(kuò)展。

Pulsar 是以 Segment 為中心的，因此在擴(kuò)展容量時(shí)不需要數(shù)據(jù)重新平衡和拷貝，舊數(shù)據(jù)不會(huì)被重新復(fù)制，這要?dú)w功于在 Apache BookKeeper 中使用可擴(kuò)展的以 Segment 為中心的分布式日志存儲(chǔ)系統(tǒng)。

通過利用分布式日志存儲(chǔ)，Pulsar 可以最大化 Segment 放置選項(xiàng)，實(shí)現(xiàn)高寫入和高讀取可用性。 例如，使用 BookKeeper，副本設(shè)置等于 2，只要任何 2 個(gè) Bookie 啟動(dòng)，就可以對(duì)主題分區(qū)進(jìn)行寫入。 對(duì)于讀取可用性，只要主題分區(qū)的副本集中有 1 個(gè)處于活動(dòng)狀態(tài)，用戶就可以讀取它，而不會(huì)出現(xiàn)任何不一致。

總之，Apache Pulsar 這種獨(dú)特的基于分布式日志存儲(chǔ)的以 Segment 為中心的發(fā)布 / 訂閱消息系統(tǒng)可以提供許多優(yōu)勢(shì)，例如可靠的流式系統(tǒng)，包括無限制的日志存儲(chǔ)，無需分區(qū)重新平衡的即時(shí)擴(kuò)展，快速復(fù)制修復(fù)以及通過最大化數(shù)據(jù)放置實(shí)現(xiàn)高寫入和讀取可用性選項(xiàng)。

英文原文鏈接：

https://streaml.io/blog/pulsar-streaming-queuing

https://streaml.io/blog/pulsar-segment-based-architecture

如果對(duì) Pulsar 感興趣，可通過下列方式參與 Pulsar 社區(qū)：

Pulsar Slack 頻道：

https://apache-pulsar.slack.com/

可自行在這里注冊(cè)：

https://apache-pulsar.herokuapp.com/

Pulsar 郵件列表:

http://pulsar.incubator.apache.org/contact

有關(guān) Apache Pulsar 項(xiàng)目的更多信息，請(qǐng)?jiān)L問官網(wǎng)：

http://pulsar.incubator.apache.org/

標(biāo)簽： 安全 代碼 媒體 權(quán)限 數(shù)據(jù)分析 數(shù)據(jù)庫 網(wǎng)絡(luò)

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