歴史上最も知られていないアルゴリズムとして知られる Paxos は、どのようにして理解しやすくなったのでしょうか?

背景

分散コンセンサスアルゴリズム（Consensus Algorithm）は、分散コンピューティングの分野における基本的な問題です。その最も基本的な機能は、複数のプロセス間で特定の値（特定の値）に関するコンセンサス（強い一貫性）に達し、分散システムの可用性の問題（高可用性）を解決することです。 Paxos は最も重要な分散コンセンサスアルゴリズムであり、多くの人がこれを「分散コンセンサスプロトコル」の同義語として使用しています (Google の Chubby サービスの発明者である Mike Burrows 氏は、「コンセンサスプロトコルは 1 つしかなく、それが Paxos です」と述べています)。

Paxos の歴史や原理については、すでに参考になる古典的な論文が数多く存在し、また社内外から詳細な説明を提供する記事も多数あるため、本稿では繰り返さないことにします。興味のある学生はこれらの論文[1,2,3,4]を読むことができます。

業界

Paxos の理論が提案されたのは 17 年前、Paxos が初めて産業的に実装されたのは 11 年前ですが、近年まで、主要な会議や業界において、Paxos 関連の論文やプロジェクトが数多く発表され続けてきました。

業界に目を向けると、Paxos とその派生製品を使用した製品は次々と登場しているものの、真に産業グレードで独立した Paxos ベースのライブラリはまだ非常に稀です。Google は Paxos ベースのライブラリをオープンソース化していません (Paxos を含むプロジェクトさえも)。Facebook は Paxos を含む製品を発表していません。Apache には Zookeeper がありますが、そのプロトコルは高スループットのステートマシンレプリケーションをサポートできず、迅速なアクセスのための独立したサードパーティライブラリも提供していません。

Github で最も人気のある独立した Paxos ライブラリは、昨年 Tencent によってオープンソース化された phxpaxos です (後で他の競合製品と詳細に比較します)。

そのため、これまでのところ、業界には成熟し、信頼性が高く、すぐに使用できる独立したサードパーティの Paxos ライブラリはほとんど存在せず、オープンソースの Paxos エコシステムはまだ成熟していません。

X-パクソス

ビジョン

当初の意図は、パブリック Paxos ライブラリを作成することではありませんでした。X-Paxos は Alibaba の分散データベース AliSQL X-Cluster で生まれましたが、X-Paxos は AliSQL X-Cluster に属していません。 Paxos は分散システムの基礎です。X-Paxos は、さまざまな分散システムにおける一貫性の問題を解決するために使用できます。

そこで、分散データベース全体の設計当初から、分散一貫性プロトコルモジュールを独自に設計し、X-Paxos に分離しました。 X-Paxos は、AliSQL X-Cluster の分散一貫性の問題を解決し、他のシステムに分散一貫性機能を迅速に提供することもできます。

分散一貫性の要件は、AliSQL X-Cluster に固有のものではありません。多くのシステムでは、高可用性と強力な一貫性が求められています。私たちは、この機能を他のより多くのシステムに導入することを望んで、Paxos 機能を独立した基本ライブラリにしました。

たとえば、チームの学生は X-Paxos をスタンドアロン KV データベース RocksDB に統合し、分散 KV エンジンを迅速に実装しました。グループのビジネスチームは、X-Paxos をビジネスストレージシステムに統合し、新しい分散型の強力な一貫性のあるストレージサービスを構築しました。

同時に、X-Paxos を可能にするのは AliSQL X-Cluster です。 Google の論文「Paxos made live」に非常に良い一節があり、大まかに次のように述べられています。「Paxos の理論と現実世界での実装の間には大きなギャップがあります。実際に Paxos を実装する場合、古典的な Paxos の理論に何らかの拡張を加える必要があることがよくあります (特に、高性能な Paxos を実装する場合は、拡張ポイントが多くなります。機能強化とパフォーマンスの最適化については後述します)。このため、実際の Paxos 実装は、実際には十分に実証されていないプロトコルに基づいているということがよくあります。」

このため、Paxos の実装を理論的に証明することは、Paxos を実装することよりも難しいと言われています。したがって、成熟した Paxos 実装を単独で作成することは困難であり、多くの場合、1 つ以上のシステムを通じてその信頼性と完全性を検証するためにシステムと組み合わせる必要があります。このため、成熟した Paxos のケースのほとんどは、最も初期の Paxos 実装 (Chubby) や現在の主要な Paxos 実装 (Google の MegaStore、Spanner、AWS の DynamoDB、S3 など) などの分散データベースと組み合わせられています。 X-Paxos は、信頼性と完全性を検証するために AliSQL X-Cluster に依存しています。

私たちのビジョンは、実際にテストされた、非常に成熟した信頼性の高い独立した Paxos ベースライブラリを提供することです。これにより、バックエンドサービスは、強力な一貫性、高可用性、自動災害復旧、および Paxos アルゴリズムによって提供されるその他の機能を、簡単なアクセスを通じて利用できるようになります。これにより、あまり知られていない Paxos が本当に身近なものとなり、何百万もの家庭に届けられるようになります。

建築

X-Paxos の全体的なアーキテクチャは上図に示されています。ネットワーク層、サービス層、アルゴリズムモジュール、ログモジュールの 4 つの部分に分けられます。

ネットワーク層

ネットワーク層は、Alibaba 内の非常に成熟したネットワークライブラリである libeasy に基づいて実装されています。 Libeasy の非同期フレームワークとスレッドプールは、全体的な非同期設計によく適合しています。同時に、分散プロトコルの要件に適応するために、libeasy の再接続ロジックを変更しました。

サービス層

サービスレイヤーは Paxos 全体の操作を駆動する基盤であり、イベント駆動や時間指定のコールバックなどのコア操作機能を Paxos に提供します。各 Paxos 実装には密接に関連するドライバーレイヤーがあり、ドライバーレイヤーのアーキテクチャはパフォーマンスと安定性に密接に関連しています。

X-Paxos のサービス層は、C++11 機能に基づいて実装されたマルチスレッド非同期フレームワークです。一般的なステートマシン/コールバックモデルには、開発効率が低い、読みにくいなどの問題があり、開発者から常に批判されてきました。また、コルーチンの適用シナリオは、シングルスレッドのボトルネックのために制限されています。 C++11 以降の新しいバージョンでは、引数転送や可変長テンプレートなどの機能が提供され、新しい非同期呼び出しモデルの実装が可能になります。

たとえば、これは単一のスケジュールされたタスクを作成する X-Paxos の実際のコード行です。

新しい ThreadTimer(srv_->getThreadTimerService(), srv_, electionTimeout_, ThreadTimer::Oneshot,
 &Paxos::checkLeaderTransfer、this、targetId、currentTerm_.load()、log_->getLastLogIndex());

上記の 1 行のプログラムには、タイマーの作成、コールバック関数の設定、コールバック関数のパラメータの転送が含まれており、コールバックがトリガーされた後のメモリの自動リサイクルを保証します (Oneshot)。同時に、サービスレイヤーはネストされたコールバックをサポートします。つまり、コールバック関数内で再度時間指定/即時タスクを生成し、有限数の時間指定ループロジックを実装します。

アルゴリズムモジュール

現在のX-Paxosアルゴリズムは、ユニークプロポーザマルチパクソス[3]に基づいて実装されています。ユニークプロポーザベースのマルチパクソスのパフォーマンスは、マルチパクソス/基本パクソスよりも優れていることが、多くの理論と実践によって証明されています。現在成熟しているPaxosベースのシステムのほとんどは、このアプローチを採用しています。

アルゴリズムモジュールの基本的な機能はこの記事では繰り返しません。興味のある学生は関連論文[1,2,4]を参照してください。 X-Paxos は、基本アルゴリズムに基づき、Alibaba のビジネスシナリオと高性能およびエコシステムの要件を組み合わせて、多くの革新的な機能とパフォーマンスの最適化を実現し、基本的なマルチ Paxos よりも機能性が高く、さまざまな展開シナリオでパフォーマンスが大幅に向上しました。次の章では、これらの最適化について詳しく紹介します。

ログモジュール

ログモジュールは元々アルゴリズムモジュールの一部ですが、最大限のパフォーマンス要件を満たすために、ログモジュールを分離し、デフォルトの高性能ログモジュールを実装しました。最大限のパフォーマンスとコスト要件を持つユーザーは、既存のログシステムを組み合わせてログモジュールインターフェイスに接続することで、より高いパフォーマンスとより低いコストを実現できます。これは、高性能な独立ライブラリとしての X-Paxos 独自の利点でもあり、次の章で詳しく紹介します。

機能強化

幅広いビジネスシナリオを組み合わせてオープンなエコシステムを構築

1. オンラインでノードを追加/削除し、オンラインでリーダーを転送する

X-Paxos は、標準のマルチ Paxos に基づいて、複数の役割を持つノードのオンライン追加/削除をサポートし、リーダーシップノードの他のノードへのオンライン高速転送 (マスター選出を使用) をサポートします。

2. 戦略的多数決と重み付けされたリーダー選出

グループと Ant グループは現在、複数の場所の集中型アーキテクチャを採用しています。その展開の特性上、多くのアプリケーションでは、都市レベルの災害復旧が発生していない場合にのみ、データベースに書き込んだり、センター内の他の分散サービスに呼び出したりする必要があります。同時に、都市レベルの災害が発生した場合 (同じ都市内の複数のコンピュータルームがすべて使用不可)、データ損失なしで書き込みポイントを非中央の場所に切り替えることができる必要があります。

従来のマルチパクソスはこれらの要件を満たすことができません。古典的な理論では、大多数が強力に同期された後に送信を完了できますが、大多数は非特定的であり、特定のノードが完全なデータを取得してサービスをアクティブ化することを保証できません。実際の実装では、地理的に近いノードは強い一貫性のあるデータを持つことが多いのに対し、地理的に遠いノードは常に強い一貫性のないノードです。これらのノードは、災害復旧時にプライマリノードとしてアクティブ化することはできず、役に立ちません。

同時に、センター内の単一ノードに障害が発生し、災害復旧が必要な場合、プライマリノードを同じセンター内の別のノードに切り替える必要があることがよくあります。複数の場所でのアプリケーションの展開は非対称であることが多いため、単一のリージョンが完全にハングした場合、プライマリノードを特定のリージョンに切り替える必要があります。これらの要件では、Paxos でリーダーを選択する際にユーザーがルールを指定できることが求められますが、古典理論には同様の機能はありません。また、Paxos の正確性を保証するために重みの追加も必要です。

X-Paxos は、プロトコルに戦略的多数決と加重リーダー選挙を実装します。戦略的な多数決に基づいて、ユーザーはノードを動的に構成して強力な一貫性のあるデータを維持し、災害復旧が必要なときにすぐにプライマリノードとしてアクティブ化できます。重み付けされたリーダー選出に基づいて、ユーザーは各ノードのリーダー選出の重みを指定できます。重みの高いノードがすべて使用できない場合にのみ、重みの低いノードがアクティブになります。

3. ノードロールのカスタマイズ（提案者/受け入れ者/学習者の独立した構成）

従来のマルチ Paxos 実装では、各ノードには通常、提案者/受け入れ者/学習者の 3 つの機能が含まれており、各ノードはフル機能ノードです。しかし、場合によっては、すべてのノードにすべての機能を持たせる必要はありません。次に例を示します。

従来の 3 つのレプリカの展開では、ノードの 1 つのステートマシンをトリミングして、ログのみを保持できます (データがない純粋なログノードですが、同期の多数決計算として使用されます)。この場合、プロトコルの Proposer 機能 (選出される権利) をトリミングし、Accepter 機能と Learner 機能を保持する必要があります。
ダウンストリームとして機能し、プロトコルによって生成されたログストリームをサブスクライブ/消費できるが、クラスターのメンバーではない (これらのノードはログストリームを保存しないため、過半数としてカウントされない) ノードがいくつかあることを期待します。この場合、プロトコルの Proposer/Accepter 機能を削除し、Learner 機能のみを保持します。

もちろん、他の組み合わせもあります。ノードの役割をカスタマイズして組み合わせることで、多くのカスタマイズされた機能ノードを開発でき、コストを節約し、機能を充実させることができます。

4. 証人SDK

前のセクションのノードロールのカスタマイズにおける個別の学習者ロールの機能に基づいて、無限の想像力が引き起こされます。学習者の役割は、データストリームサブスクライバー (Witness Node) に抽象化できます。無数のサブスクライバーをクラスター全体に追加できます。新しいログが送信されると、これらのサブスクライバーは関心のあるログストリームを受信します。サブスクライバー機能に基づいて、クラスターでダウンストリームサブスクリプションの消費、インスタントログバックアップ、構成変更のプッシュなどの機能を簡単に実装できます。

そのため、Learner ロールを別の SDK にカプセル化しました。この SDK に基づいて、ユーザーはサブスクリプション登録とストリーミングサブスクリプション機能を独自のクラスターにすばやく追加し、特定の目的に基づいた完全なエコシステムを構築できます。

たとえば、AliSQL X-Cluster のログストリーム SDK によって作成されたエコシステム:

X-Paxos では、Witness SDK を使用して、分散システムを他の下流システムと迅速に接続し、完全なエコシステムを形成することもできます。

MySQL のログ (binlog) バックアップを例に挙げてみましょう。

通常プラン

◦ 一定時間 Tb ごとに、MySQL によって生成された binlog ファイルを *** バックアップシステム (OSS、S3 など) にバックアップします。

◦ RPO（リカバリポイント目標）はTb

SDKソリューション

◦ X-Paxos は SDK による増分ログサブスクリプションをサポートします。バックアップシステムでは、SDK ストリームを OSS ストリームに接続するだけで、ストリーミングバックアップを実現できます。

◦ RPO (Recovery Point Objective) は 0 です。バックアップに加えて、Witness SDK には、ダウンストリームストリーミングサブスクリプション (DRC)、自己完結型高可用性システム (X-Driver)、非同期読み取り専用スタンバイデータベースなどの実用的なケースがあり、さらに多くのアプリケーションケースが継続的に追加されています。

パフォーマンスの最適化

私たちは常に、ネットワークの遅延がスループットに影響を与えるべきではないと信じてきました

1. バッチ処理とパイプライン処理

設計当初の強力な一貫性と高可用性に加え、Paxos の高パフォーマンスも重要です。特に、AliSQL X-Cluster などの高性能分散データベースに適用する場合は、プロトコルのスループットとレイテンシに高い要件が課されます。同時に、グローバルに展開可能な分散一貫性プロトコルとして、高レイテンシでのパフォーマンスの課題が特に重要になります。

X-Paxos は、高遅延ネットワーク向けにプロトコルを最適化するために多くの試みとテストを行ってきました。学術界における既存の理論的成果 [5,6,7] と組み合わせて、高遅延かつ高スループット、および低遅延かつ高スループットのネットワーク向けの適応型通信モードの完全なセットが、合理的なバッチ処理とパイプライン処理を通じて設計および実装されており、X-Paxos のパフォーマンスが大幅に向上しています (比較については次のセクションを参照)。同様の競合製品間で同様の最適化が行われることは、依然として非常にまれです。

バッチ処理とは、複数のログを 1 つのメッセージにまとめて送信することを意味します。バッチ処理により、メッセージの粒度によって生じる余分な損失を効果的に削減し、スループットを向上させることができます。ただし、バッチ処理を過度に行うと、単一のリクエストで過度の遅延が発生しやすくなり、同時リクエストの数が過度に多くなり、スループットとリクエストのレイテンシに影響を及ぼします。

パイプラインとは、前のメッセージが結果を返す前に、次のメッセージを対応するノードに同時に送信するためのメカニズムを指します。同時送信メッセージ数（パイプライン数）を増やすことで、同時単一リクエストのレイテンシを効果的に削減できます。同時に、送信遅延が伝播遅延よりも小さい場合（高レイテンシ、高スループットのネットワーク）、パフォーマンスを効果的に向上できます。

バッチ処理 (メッセージサイズ: M) とパイプ処理 (メッセージの同時実行性: P) は、次の関係で最高のスループットを達成できると推測できます。

M/R * P = D

ここで、R はネットワーク帯域幅、D はネットワーク伝播遅延 (およそ RTT/2) です。X-Paxos は上記の理論を組み合わせ、組み込みの検出を使用して、さまざまなノードの展開遅延に応じて各ノードのバッチ処理およびパイプラインパラメータを適応的に調整し、全体の最大スループットを実現します。

Pipeling の導入では、特にリモートシナリオでのログの無秩序の問題を解決する必要があります。ウィンドウが大きいほど、無秩序の可能性が高くなります。 X-Paxos は、基盤となるログの順序不同の問題を遮断し、効率的な順序不同のログストレージを実現できる、効率的な順序不同処理モジュールを実装します。

2. マルチスレッド、完全非同期のPaxosライブラリ

Paxos の内部状態は複雑なため、効率的な単一インスタンスのマルチスレッド Paxos を実装することは非常に大きな課題となります。前述の GitHub で最も多くのスターを獲得している phxpaxos であれ、Oracle MySQL Group Replication で使用されている xcom であれ、それらはすべてシングルスレッド実装です。 Phxpaxos は、全体的なスループットを向上させるために、単一パーティション、単一スレッド、およびマルチインスタンスの集約アプローチを使用しますが、単一パーティションのパフォーマンスは非常に制限されています。xcom は、コルーチンに基づく単一スレッド実装です。シングルスレッドの Paxos 実装は、シリアル化/デシリアル化、配布、およびパケット送信ロジックを処理するときにシリアルに実行されるため、明らかなパフォーマンスのボトルネックが発生します。

X-Paxos は完全にマルチスレッド実装に基づいており、単一パーティション Paxos でマルチスレッド機能を最大限に活用できます。すべてのタスクは一般的なワーカーによって実行されるため、CPU ボトルネックが解消されます。 X-Paxos は、サービス層と非同期ネットワーク層のマルチスレッド非同期フレームワークに依存して、必要なプロトコルシリアルポイントを除いてほとんどの操作を同時に実行できます。また、一部のプロトコルシリアルポイントはロックフリー設計を採用しているため、マルチスレッド機能を効果的に活用し、Paxos のシングルパーティションマルチスレッド機能を実現できます。シングルパーティションのパフォーマンスは競合製品をはるかに上回り、競合製品のマルチパーティションパフォーマンスさえも上回ります。

3. 地域性を考慮したコンテンツ配信

ユニークプロポーザに基づく分散システムのボトルネックは、マスターノードが唯一のコンテンツ出力ソースであることです。クラスター内のノード数が多い場合、マスターノードのネットワーク送受信作業量が多いため、マスターノードに過負荷がかかり、CPUと帯域幅のボトルネックが発生します。全国/グローバルに展開する場合、すべてのノードとマスターノード間の直接通信により、地域をまたぐ長距離伝送/国際リンクの帯域幅が過度に占有されます。

X-Paxos は、グローバル分散型の強力な一貫性の問題を解決するために設計された独立した Paxos ライブラリです。この問題は、設計当初から考慮されていました。定常状態で稼働している場合、X-Paxos はノード間のネットワーク遅延 (物理的な距離) を感知し、カスケードトポロジを形成して、マスターノードの負荷と長距離リンクの帯域幅使用量を効果的に削減します。ノードに異常が発生した場合、自動的にトポロジを再編成し、生き残ったノード間の正常なピアリングを確保します。同時に、X-Paxos は、企業がトポロジーを再編成するためのルールを設定することをサポートします。企業は、独自の APP 展開アーキテクチャとレイテンシ特性に基づいて、ターゲットを絞った方法でトポロジーの再編成ルールを設定できます。

4. プラグ可能なログ記録

X-Paxos と既存のほとんどの Paxos ライブラリとの大きな違いは、X-Paxos がプラグ可能なログ記録モジュールをサポートしていることです。ログモジュールは Paxos の重要なモジュールです。その永続性はデータの一貫性に関係しており、その読み取りおよび書き込みパフォーマンスはプロトコルの全体的な読み取りおよび書き込みパフォーマンスに大きく影響します。現在、ほとんどの独立した Paxos ライブラリにはログモジュールが組み込まれており、プラグ可能性をサポートしていません。これには 2 つの欠点があります。

デフォルトのログモジュールは一般的な機能を提供するため、特定のシステム向けに最適化することは困難です。
既存のシステムには WAL (Write Ahead Log) が既に存在することが多く、Paxos プロトコルでは別のコピーを保存する必要があります。これは、a) 1回のコミットに2回のローカル同期が必要（パフォーマンスに影響）であること、b) 二重ログによって大量のストレージが浪費されることを意味します。

たとえば、phxpaxos の組み込みログモジュールは LevelDB を使用します。ログシステムとして、その操作は冗長性が高く、ターゲットを絞った最適化が行われていないため、パフォーマンスが心配です。同時に、phxpaxos を使用する単一の phxsql ノードは、binlog と Paxos ログの両方を (独立した phxbinlogsvr に) 保存する必要があり、パフォーマンスに重大な影響を与え、ストレージスペースを浪費します。 X-Paxos を採用した AliSQL X-Cluster は、既存の binlog モジュールを直接変換し、X-Paxos のログモジュールに接続します。各ノードにはログが 1 つだけ存在するため、ストレージが削減され、パフォーマンスが向上します。

分散正しさ検証

分散型の強力な一貫性プロトコルにとって、正確性は生命線です。前述のように、分散型の強力な一貫性プロトコルの正しさを理論的に完全に証明することは困難です。エンジニアリング実装の問題が加わると、困難さはさらに大きくなります。 X-Paxos の正確性と完全性を確保するために、理論的側面とエンジニアリング的側面の両方から多くの理論的および技術的手段を採用しました。

1. ジェプセン

Jepsen は、オープンソースコミュニティで広く認知されている分散データベーステストフレームワークです。 Jepsen は、VoltDB、CockroachDB、Galera、MongoDB、etcd を含むほぼすべての主流の分散データベース/システムを検証し、多くの問題を発見しました。
X-Paxos は Jepsen との接続を完了し、さまざまな分散データベースの既存の事例を検証しました。

2. TLA+

TLA+ は、Paxos の創設者でありチューリング賞を受賞した Leslie Lamport によって発明された形式仕様言語です。 TLA+ は、分散同時実行システムの設計、モデリング、検証に特化しています。 Amazon DynamoDB/S3/EBSMicrosoft Cosmos DBはいずれもTLA+モデル検証を通じて多くの問題を発見した。
X-Paxos は現在、TLA+ モデル検証に合格しています。

3. ランダム例外システム

さまざまな例外シナリオ下でプロトコルの正確性と安定性を自動的に検証できる自動ランダム例外検証システムを構築しました。シミュレートされたネットワークパケット損失、フラッシュ切断、分離、およびディスク障害の状況下で、X-Paxos が正しく機能し、データが一貫していることを確認します。

4. 異常回帰システム

X-Paxos には例外ケース回帰システムがあります。発生した、または予想される同時例外ケースは、毎日の回帰検証のために例外ケースライブラリに追加されます。同時に、例外ケースライブラリも継続的に強化されています。

競合製品の分析と比較

XCOM (MySQL グループレプリケーション)

MySQL GroupReplication は、MySQL が Galera のアイデアを公式に使用して、MySQL 上に分散型の強力な一貫性のあるクラスターを構築するためのプラグインです。 MySQLグループレプリケーションの初期に使用されていた分散プロトコルは、Red HatがTotem（The Totem Single-Ring Ordering and Membership Protocol）[8]プロトコルに基づいて開発した分散一貫性プロトコルライブラリであるCoroSyncでした。Totemアルゴリズム自体のパフォーマンス上の制限により、MySQL 5.7.9以降、正式版では独自のPaxos（Mencius）[10]ベースの一貫性プロトコルライブラリXCOMが採用されています。

XCOMはMySQLグループレプリケーションのコアコンポーネントであり、グループコミュニケーションコア[9]と呼ばれます。 XCOM のソースコードを分析しました。XCOM は、純粋な C 言語でコンパイルされたコアモジュールと C++ で実装されたプロキシで構成されるシステムです。純粋な C モジュールは単一のスレッドによって駆動され、タスクのスケジュールを実装するためにコルーチンに依存します。したがって、クライアント (MySQL GroupReplication プラグイン) は、TCP 接続を使用して XCOM に要求を送信する必要があります。したがって、XCOM には次の欠点があります。

1. シングルスレッドドライバー、マルチスレッド機能なし

アーキテクチャによって突破の難しさが決まる

2. 通信フローには追加のTCPプロトコルスタックが必要

メモリコピーが慎重に計算されるアプリケーションでは、スレッド間のネットワーク通信が1つ増えることは許容されません。

3. XCOMはバッチ処理とパイプライン処理を実装していますが、その値は固定されており、実際のシナリオに適応するのは困難です。

これは公式文書にも記載されている[9]
これにより、クロスリージョンシナリオでのMySQLグループレプリケーションのパフォーマンスも非常に不十分になります（AliSQL X-Cluster比較テストを参照）。

phxpaxos (phxsql)

phxpaxos は、Tencent が立ち上げた Paxos プロトコルに基づく独立したライブラリです。これを MySQL と組み合わせることで、MySQL をベースに実装された分散型の強力な一貫性を持つ MySQL クラスターである phxsql プロジェクトが立ち上げられました。 phxpaxos は他のプロジェクトで独立して使用することができ、現在 GitHub で最も多くのスター (1000 以上) を獲得している Paxos 独立ライブラリです。この記事では、phxsql の詳細については説明しません。詳細については、「AliSQL X-Cluster 競合製品分析」を参照してください。ここでは、phxpaxos の分析に焦点を当てます。

Phxpaxos もマルチ Paxos に基づく独立したライブラリです。そのアーキテクチャはシングル Paxos シングルスレッド設計を採用していますが、マルチスレッド機能を拡張するために複数の Paxos パーティションをサポートしています。この拡張には、複数のデータを事前にパーティション分割する必要があります。したがって、phxpaxos の欠点は次のとおりです。

単一のPaxosオブジェクトは単一のスレッドのみをサポートします。複数のPaxosオブジェクトをサポートし、ネットワーク層を共有することができます。
パイプラインをサポートしておらず、クロスリージョン環境ではほとんど使用できない（高レイテンシ）
多重ログ冗長性、LevelDB ベースのログシステムのパフォーマンスボトルネック

パフォーマンス比較

私たちは、依然としてTencentのphxpaxosを競合製品として比較しています（XCOMには独立したコンポーネントがないため、MySQL Group ReplicationとAliSQL X-Clusterの比較テスト結果を間接的に参照できます）。

次の条件下で、異なるリクエストサイズでストレステストを実行しました: a) 1 つのリージョンに 3 つのノードを展開。b) 3 つのリージョンそれぞれに 1 つのノードを展開。

上記の 2 つの比較画像から、次のことがわかります。

同じリージョンでの X-Paxos のパフォーマンスは、phxpaxos の 100 倍以上です。
Phxpaxos はクロスリージョンシナリオではほとんど使用できませんが、X-Paxos では 444 バイト (sysbench 挿入シナリオでの単一リクエストのサイズ) で 3.5% のパフォーマンス低下しか見られず、スループットにほとんど影響しません。

現状と将来

現状

現在、X-Paxos の第一フェーズがリリースされ、開始されています。

X-Paxos をベースにしたグループデータベースチーム製品である AliSQL X-Cluster は、グループ内で広く使用されています。

X-Paxosと業務システムを組み合わせた分散型サービスも続々と登場しています。

未来

Paxos は分散システムの礎です。近年でも、Paxos に関する学術論文や新たな進化の方向性が次々と発表されています。当社の X-Paxos も、グループのニーズやそれ以外のニーズをよりよく満たすために開発を続けます。今後の主な開発の方向性は次のとおりです。