分散メッセージキューのApacheパルサー

パルサーについて

Apacheのパルサーは、もともと2016年にヤフー、オープンソースで開発されたエンタープライズクラスの分散型メッセージングシステム、である、Apacheのインキュベーター財団中です。Plusar Yahooは、主にメール、財務、スポーツ、Flickrの、ジェミニ広告プラットフォーム、シェルパとYahooのKVストレージを提供し、3年以上の運用環境で使用されてきました。

パルサーは、主に以下の特徴の、メッセージキューの次の世代と呼ばれることができました。

• 線膨張。それは、数百のノードに絹のような拡張可能（カフカ拡張ノード間でデータをコピーするために必要なシステムリソースの多くを取る、完全ではないPlusar）

• ハイスループット。Yahooは、本番環境での秒あたりのメッセージ数百万の試練に耐えました

• 低レイテンシー。低レイテンシを維持することができ、依然としてメッセージの膨大な量の（<5ミリ秒）

• 永続化メカニズム。Plusar Apacheの簿記係の上に構築された永続化メカニズムは、IOは書き込みや読み出しの前に絶縁を提供します

• ベースの場所をコピーします。Plusarは、主要機能のサポートとして利用できる多地域/エリアをコピーします。ユーザーは、単に利用可能な領域を設定し、メッセージが他の利用可能なエリアの安定したストリームにコピーされます。ネットワークパーティションまたはハングの利用可能エリアの場合は1、plusarは、再試行の後に続けます。

• 展開の多様化。どちらも、ベアメタル上で実行されますが、ローカルの開発者は全体のみコマンドライン環境を起動する必要がありながらも、現在の例ドッカー、K8Sコンテナスキームと異なるクラウドベンダーのいくつかをサポートすることができます。

• トピックは、消費パターンの多様性をサポートしています、排他的、共有、フェイルオーバー

アーキテクチャの概要

トップビュー、複数のクラスタからなるPlusarユニットから、各ユニット内のクラスタは前のデータをコピーし、plusar一般的に以下の成分を有していてもよいです。

• ブローカー：消費者に送信され、分散したメッセージの処理を担当プロデューサー。共同のグローバルZKクラスターを通じてさまざまなタスクを処理するには、例えば、ロケーションベースのレプリケーションと述べました。そして、メッセージは、簿記係を保存するだけでなく、いくつかのメタデータを格納するための単一のクラスタZKクラスタを持っている必要があります。

• 簿記クラスタ：永続的なメッセージのために、内部のブックメーカーを複数備えました。

• ZooKeeperの集

ブローカ

在Kafka和RocketMQ中，Broker负责消息数据的存储以及consumer消费位移的存储等，而Plusar中的broker和他们两个有所不同，plusar中的broker是一个无状态的节点，主要负责三件事情：

• 暴露REST接口用于执行管理员的命令以及topic所有者的查询等

• 一个用于节点间通讯的异步的TCP服务器，协议目前采用的是Google之前开源的Protocol Buffer

• 为了支持地域复制，broker会将自己 集群所在的消息发布到其他可用区。

消息会被先发布到BookKeeper中，然后会在Broker本地内存中缓存一份，因此一般来说消息的读取都会从从内存中读取，因此第一条中所说的查找topic所有者就是说，因为BookKeeper中的一个ledger只允许一个writer，因此我们可以调用rest接口获取到某一个topic当前的所有者。

BookKeeper

BookKeeper是一个可横向扩展的、错误容忍的、低延迟的分布式存储服务，BookKeeper中最基本的单位是记录，实际上就一个字节数组，而记录的数组称之为ledger，BK会将记录复制到多个bookies，存储ledger的节点叫做bookies，从而获得更高的可用性和错误容忍性。从设计阶段BK就考虑到了各种故障，Bookies可以宕机、丢数据、脏数据，但是主要整个集群中有足够的Bookies服务的行为就是正确的。
在Pulsar中，每个分区topic是由若干个ledger组成的，而ledger是一个append-only的数据结构，只允许单个writer，ledger中的每条记录会被复制到多个bookies中，一个ledger被关闭后(例如broker宕机了或者达到了一定的大小)就只支持读取，而当ledger中的数据不再需要的时候(例如所有的消费者都已经消费了这个ledger中的消息)就会被删除.

Bookkeeper的主要优势在于它可以保证在出现故障时在ledger的读取一致性。因为ledger只能被同时被一个writer写入，因为没有竞争，BK可以更高效的实现写入。在Broker宕机后重启时，Plusar会启动一个恢复的操作，从ZK中读取最后一个写入的Ledger并读取最后一个已提交的记录，然后所有的消费者也都被保证能看到同样的内容。

我们知道Kafka在0.8版本之前是将消费进度存储到ZK中的，但是ZK本质上基于单个日志的中心服务，简单来讲，ZK的性能不会随着你增加更多的节点而线性增加，会只会相反减少，因为更多的节点意味着需要将日志同步到更多的节点，性能也会随之下降，因此QPS也会受单机性能影响，因此0.8版本之后就将消费进度存储到了Kafka的Topic中，而RocketMQ最初的版本也类似，有几种不同的实现例如ZK、数据库等，目前版本采用的是存储到本机文件系统中，而Plusar采用了和Kafka类似的思想，Plusar将消费进度也存储到了BK的ledger中。

元数据

Plusar中的元数据主要存储到ZK中，例如不同可用区相关的配置会存在全局的ZK中，集群内部的ZK用于存储例如某个topic的数据写入到了那些Ledger、Broker目前的一些埋点数据等等

Plusar核心概念

Topic

发布订阅系统中最核心的概念是topic，简单来说，topic可以理解为一个管道，producer可以往这个管道丢消息，consumer可以从这个管道的另一端读取消息，但是这里可以有多个consumer同时从这个管道读取消息。

トピック下の異なるパーティション・メッセージは、それが異なる含まれる各トピックは、複数のパーティションに分割することができます。パーティションオフセット一意に割り当てられた後、各メッセージに追加され、同じパーティション内のメッセージは、クライアントのユーザを順序付けされ、例えば、全体のメッセージが、ユーザIDに応じて剰余をハッシュされるようにすることができある程度の競合状態の問題を回避するように、パーティション全体に送られます。
パーティショニングすることによって、異なるノードへのメッセージ処理は複数の高スループットを達成します。デフォルトでは、plusarトピックは、非パーティションですが、インターフェースが作成またはCLIによるパーティショントピックの一定数をサポートします。

Plusar自動的にバランスのとれた生産と消費者が、クライアントがルーティング独自のビジネスルールに従って、デフォルトで行われることを望んで時々、Plusarのデフォルトは次のルールをサポートしています。単一パーティション、ポーリング、ハッシュ、カスタム（で、自分自身を達成するためにルーティングルールをカスタマイズするには、関連するインタフェース）

消費パターン

排他的、共有、フェイルオーバー：消費者は、メッセージがコンシューマに配信された正確にどのように決定し、Plusarは、消費のいくつかの異なるパターンをサポートしています。次のように示します：

• 独占：トピックは、消費者によって消費することができます。これがデフォルトのモードですPlusar

• 共有：共有通話モードまたはポーリングモードは、複数の消費者は、別のトピックに接続することができ、メッセージは順番に、消費者、消費者がダウンまたは切断するためのイニシアチブをとるに配布され、その後、消費者に送られていませんACKメッセージは、他の消費者に配布再スケジュールされます。

• フェイルオーバー：複数の消費者が同じトピックに接続し、辞書式順序をたどることができ、マスタ切断、消費者はいないACKとメッセージキュー分布のすべての残り、マスターと呼ばれる最初のメッセージを、支出を開始します別のコンシューマへ。

Plusarは今も、着信メッセージのIDをサポートし、別のリーダー・インターフェースをサポートし、例えば、最も古いメッセージから支出を開始するMessage.Earliestを言います。

概要

Plusarは非常に魅力的な性質を持って、次の世代として、メッセージキューを分散し、だけでなく、コピー領域、マルチテナント、スケーラビリティ、分離と読み書きするなどの他の競合製品、いくつかの欠点を補います。