分散一貫性に関する簡単な説明: Raft と SOFAJRaft

[[403519]]

1. 分散コンセンサスアルゴリズム

1 分散コンセンサスをどう理解するか?

複数の参加者が 1 つの事柄について完全な合意に達します。つまり、1 つの事柄、1 つの結論です。

合意によって得られた結論は覆すことはできない。

2. 分散コンセンサスアルゴリズムとは何ですか?

Paxos: 分散コンセンサスアルゴリズムの基礎と考えられており、その他はすべてそのバリエーションです。しかし、Paxos の論文では単一の提案のプロセスのみが示されており、レプリケーションステートマシンで必要な複数の Paxos の関連する詳細については説明されていません。 Paxos の実装には、高度なエンジニアリングの複雑さ (複数の書き込みポイント、ログホールの許可など) が伴います。
Zab: Zookeeper で使用されており、業界で広く使用されていますが、汎用的なライブラリとして抽象化されていません。
Raft: 理解しやすいことで知られており、etcd、braft、tikv など、業界では多くの raft 実装が登場しています。

2. いかだの紹介

1. 特徴: 強いリーダー

システムには一度に 1 人のリーダーが存在する必要があり、リーダーだけがクライアントからのリクエストを受け入れることができます。
リーダーは、すべてのフォロワーと積極的にコミュニケーションを取り、すべてのフォロワーに「提案」を送信し、大多数のフォロワーからの応答を収集する責任があります。
リーダーは、リーダーシップを維持する（プレゼンスを維持する）ために、すべてのフォロワーにハートビートを積極的に送信する必要もあります。

さらに、リーダーとしては常に心拍を維持する必要があります。

2 レプリケーションステートマシン

無限に増加するシーケンス a[1, 2, 3…] について、任意の整数 i に対して a[i] の値が分散一貫性を満たす場合、システムは一貫性のある状態マシンの要件を満たします。

実際のシステムでは、ほぼすべて、一定の操作ストリームが実行されるため、単一の値に同意するだけでは不十分です。実際のシステムですべてのレプリカの一貫性を確保するために、操作は通常、書き込み先行ログ (WAL) に変換されます。次に、システム内のすべてのレプリカを WAL と整合させて、各レプリカが WAL 内の操作を順番に実行し、最終状態の整合性が確保されるようにします。

クライアントはリーダーに書き込み要求を送信します。
リーダーは「操作」を WAL に変換し、ローカルログを書き込むと同時に、そのログをすべてのフォロワーにコピーします。
リーダーは多数決応答を受信し、ログに対応する「操作」をステートマシンに適用します。
処理結果をクライアントに返信します。

Raft の 3 つの基本概念

Raftノードの3つの役割/ステータス

フォロワー: 完全に受動的で、リクエストを送信することはできず、リーダーと候補者からのメッセージを受信して応答するだけです。起動後のノードの初期状態はフォロワーである必要があります。
リーダー: クライアントからのすべてのリクエストを処理し、ログをすべてのフォロワーに複製します。
候補者: 新しいリーダーに立候補するために使用されます (候補者はフォロワーのタイムアウトによってトリガーされます)。

3種類のメッセージ

RequestVote RPC: 候補者によって発行されました。
AppendEntries (ハートビート) RPC: リーダーによって発行されました。
InstallSnapshot RPC: リーダーによって発行されます。

用語論理クロック

時間は用語に分割され、用語 ID は時間軸に沿って単調に増加します。
各任期はリーダー選挙から始まります。選挙が成功すると、リーダーは「選挙 + 通常運用」の任期中にクラスター全体を管理します。
1 期につきリーダーは最大 1 人であり、分割投票のためリーダーが存在しない場合もあります。

4. ラフトの機能分解

リーダー選挙

タイムアウトドライバー: ハートビート / 選挙タイムアウト

ランダムタイムアウト: 選挙の衝突により票が分割される可能性を減らす

選挙プロセス: フォロワー --> 候補者 (選挙タイムアウトトリガー)

選挙に勝つ：候補者 --> リーダー
別のノードが選挙に勝利: 候補者 --> フォロワー
一定期間、どのノードも選挙に勝てない: 候補 --> 候補

選挙活動:

現在の期間++
リクエストを送信投票 RPC

新しいリーダー選出原則（最大服従原則）：

候補者は、RequestVote RPC にログ情報 (最後のログエントリのインデックスと用語) を含めます。
選挙中、コミットされたすべてのエントリが含まれる可能性が最も高いログを持つ候補者を選択します
投票サーバー V は、ログが「より完全」である場合に投票を拒否します: (lastTermV > lastTermC) ||((lastTermV == lastTermC) && (lastIndexV > lastIndexC))
リーダーは、選出された多数派の中で「最も完全な」ログを持つことになる

安全性: 1 期につき、最大 1 人のリーダーが選出されます。リーダーがいない場合は、次の任期で別のリーダーが選出されます。

ラフト選挙の成功率に影響するいくつかの時間パラメータ:

RTT (ラウンドトリップタイム): ネットワーク遅延
ハートビートタイムアウト: ハートビート間隔は、通常、選出タイムアウトよりも 1 桁小さくする必要があります。これは、リーダーがハートビートを送信し続け、フォロワーが選出をトリガーするのを防ぐためです。
選挙タイムアウト: リーダーとフォロワー間の通信がタイムアウトし、選挙がトリガーされる時間
MTBF (平均故障間隔): サーバーの連続ルーチン障害時間間隔 RTT << ハートビートタイムアウト < 選出タイムアウト (ET) << MTBF

メイントリガー時間をランダムに選択: ランダム (ET、2ET)

ログのレプリケーション

ラフトログフォーマット:

(TermId、LogIndex、LogValue)
その中で、（TermId、LogIndex）は、ログのみを決定できる。

ログレプリケーションの重要なポイント:

連続性: ログにギャップがあってはなりません
有効：
- 同じ用語とlogIndexを持つ異なるノードのログ値は同じでなければならない
- リーダーのログは有効である必要があります
- フォロワーのログが有効かどうかは、リーダーのログと比較することで判断できます (方法は?)

フォロワーログの有効性チェック:

AppendEntries RPCは、前のログの一意の識別子（prevTermId、prevLogIndex）も運びます。
再帰的導出

フォロワーのログ回復:

リーダーは nextIndex を減分し、リーダーログと一致するまで AppendEntries を再送信します。

コミットインデックスの前進

コミットインデックス (TermId、LogIndex):

いわゆる commitIndex は、過半数に達し、ステートマシンに適用できる最新のログ位置です。
ログがフォロワーにコピーされた後、最初に永続化され、すぐにステートマシンに適用することはできません。
ログが過半数に達し、ステートマシンに適用できるかどうかはリーダーのみが知っている
フォロワーはリーダーから送信された現在の commitIndex を記録します。 commitIndex 以下のすべてのログをステートマシンに適用できます。

CommitIndex の進歩:

リーダーは、次のAppendEntries RPC（ハートビートを含む）で現在のcommitIndexを伝達します。
フォロワーはログの有効性をチェックし、AppendEntries を受け入れて、同時にローカル commitIndex を更新します。最後に、commitIndex 以下のすべてのログがステートマシンに適用されます。

エントリ追加 RPC

完全な情報: (currentTerm、logEntries[]、prevTerm、prevLogIndex、commitTerm、commitLogIndex)
currentTerm、logEntries[]: ログ情報。効率性のため、ログは通常複数のエントリになります。
prevTerm、prevLogIndex: ログの有効性チェック
commitTerm、commitLogIndex: 最新のコミットログの位置 (commitIndex)

要約: 今、Raft で何ができるでしょうか?

複数の提案を継続的に確認し、クラスタ内の各システムノードのステータスが完全に一貫していることを確認します。
少数のサーバーに障害が発生した場合でも、継続的な可用性を確保するためにリーダーを自動的に選択します。
強力なログ同期、ダウンタイム後のデータ損失ゼロ

3 ソファラフト

純粋な Java ラフトアルゴリズム実装ライブラリです。すべての関数が Java で書き直され、いくつかの改善と最適化が加えられています。

1. SOFAJRaftの全体機能

機能サポート

リーダー選挙: リーダー選挙。

ログのレプリケーションとリカバリ: ログのレプリケーションとログのリカバリ。ログリカバリは、コミットされたデータが失われないようにするためのものです。ログのリカバリには 2 つの側面があります。

現在の用語ログリカバリは、主に一部のフォロワーノードを再起動してクラスターに参加したり、新しいフォロワーノードを追加したりするために行われます。
前期ログリカバリ、主にリーダー切り替え前後のログの一貫性を保つため

スナップショットとログの圧縮: 定期的にスナップショットを生成してログの圧縮を実装し、起動と回復を高速化し、InstallSnapshot を使用してデータをフォロワーにコピーします。

メンバーシップの変更: ノードの追加、ノードの削除、ノードの置き換えなど、クラスターのオンライン構成変更。

リーダーの移行: 再起動メンテナンス、リーダーの負荷分散などのためにリーダーを積極的に変更します。

対称ネットワークパーティション許容度: 対称ネットワークパーティション許容度。

事前投票: 上の図に示すように、S1 が現在のリーダーです。ネットワーク分割により、S2 はローカル項を継続的に増加させます。ネットワークが復旧した後に S2 が選挙を開始するのを防ぐために、誠実に作業しているリーダーが退任し、クラスター全体が選挙を再開することになるため、要求投票の前に事前投票 (currentTerm + 1、lastLogIndex、lastLogTerm) が実行されます。過半数が成功した場合にのみ、実際のリクエスト投票を開始するために状態が候補に変更されます。そのため、分割後のノードでは事前投票が成功せず、クラスターは一定期間正常にサービスを提供できなくなります。

非対称ネットワークパーティション許容度: 非対称ネットワークパーティション許容度。

上の図に示すように、S1 が現在のリーダーであり、S2 はリーダー選出をトリガーするためにタイムアウトし続け、S3 は現在のリースを中断するために期間を増やし、それによってリーダーの更新を拒否します。このとき、トリックチェックを追加できます。各フォロワーは、リーダーのデータ更新 (ハートビートを含む) を受信した時刻を記録するためにタイムスタンプを保持します。選挙タイムアウト後にのみ、リクエスト投票リクエストを受け入れることができます。

フォールトトレランス: フォールトトレランスとは、少数の障害がシステム全体の可用性に影響を与えないことを意味します。

機械の電源障害
アプリケーションを強制終了する
遅いノード (GC、OOM など)
ネットワーク障害
その他の奇妙な理由により、ラフトノードが正常に動作しない

定足数ピアがダウンした場合の回避策: 大多数がダウンすると、グループ全体が使用できなくなります。安全なアプローチは、大多数のノードが回復するまで待つことです。この方法でのみデータのセキュリティが保証されます。ただし、ビジネスが可用性をより追求し、データの一貫性を放棄する場合は、手動の reset_peers コマンドを使用してクラスター全体をすばやく再構築し、クラスターの可用性を回復できます。

メトリクス: SOFAJRaft には、豊富なパフォーマンス統計インジケータを備えた、メトリクスライブラリに基づくパフォーマンスインジケータ統計が組み込まれています。

Jepsen: 単体テストに加えて、SOFAJRaft は分散検証およびフォールトインジェクションテストフレームワークである jepsen を使用して、検証済みのさまざまな状況をシミュレートします。

ランダムなパーティション分割、2つのネットワークパーティション、1つは大きく、もう1つは小さい

ランダムにノードを追加および削除する
ノードをランダムに停止および起動する
ランダムに-9を殺してノードを起動する
ランダムに2つのグループに分割し、中間ノードに接続して分割をシミュレートします
ランダムに異なる多数派グループに分ける

パフォーマンスの最適化

バッチ: SOFAJRaftのリンク全体がバッチ化され、バッチ消費にはディスラプターのMPSCモデルが使用されます。これには以下が含まれますが、これらに限定されません。

タスクの一括送信
バッチネットワーク送信
ローカル IO バッチ書き込みでは、ログが失われないようにするために、通常、各ログエントリを fsync する必要があり、時間がかかります。 SOFAJRaft はマージ書き込みを最適化しました。
ステートマシンにバッチを適用する

レプリケーションパイプライン: パイプラインレプリケーションでは、リーダーノードとフォロワーノード間のログ同期はシリアルバッチモードで行われます。各バッチが送信された後、次のバッチの送信を続行する前にバッチ同期が完了するのを待つ必要があり (ピンポン)、これにより長い遅延が発生します。これは、リーダーノードとフォロワーノード間のパイプラインを複製することで改善でき、更新の待ち時間を効果的に短縮し、スループットを向上させることができます。

ログを並列に追加: リーダーはログエントリを保持し、フォロワーにログエントリを並列に送信します。

完全な同時レプリケーション: リーダーは、すべてのフォロワーにログを完全に並列に送信します。

非同期: Jraft では、リンク全体にブロッキングがほとんどなく、完全に非同期であり、コールバックプログラミングモデルです。

ReadIndex: raft ログを使用して raft 読み取りのパフォーマンスを最適化します。読み取りが実行されるたびに、commitIndex のみが記録され、その後、リーダー ID を確認するためにすべてのピアのハートビートが送信されます。リーダー ID が正常に確認された場合、適用されたインデックス >= commitIndex のときにクライアント読み取りを返すことができます。 ReadIndex に基づいて、線形一貫性読み取りを非常に便利に提供できます。ただし、commitIndex はリーダーから取得する必要があり、これにより RPC の追加ラウンドが追加されます。

リース読み取り: リーダー ID はリースによって保証されるため、readIndex がハートビートごとにリーダー ID を確認する必要がなくなり、パフォーマンスが向上します。ただし、クロックを通じてリースを維持することは絶対に安全ではありません (readIndex のパフォーマンスが十分に優れているため、jraft のデフォルト構成は readIndex です)。

2 SOFAJラフトデザイン

SOFAJRaft - ラフトノード

ノード: Raft グループ内のノード。基盤となるすべてのサービスを接続してカプセル化します。これはユーザーに表示される主要なサービスインターフェイスであり、特に apply(task) は、ラフトグループで構成されるレプリケーションステートマシンクラスターのビジネスステートマシンに新しいタスクを送信するために使用されます。

ストレージ：

ログストレージには、raft ユーザーが送信したタスクのログが記録され、リーダーから他のノードにコピーされます。 LogStorage はストレージ実装です。 LogManager は、基盤となるストレージの呼び出し、呼び出しのキャッシュ、バッチコミット、および必要なチェックと最適化の実行を担当します。
メタデータストレージ (メタ情報ストレージ) は、現在の用語、どのノードに投票するかなどのラフト実装の内部ステータスを記録します。
スナップショットストレージは、ユーザーのステートマシンスナップショットとメタ情報を保存するために使用されます。オプションです。 SnapshotStorage はスナップショットストレージの実装に使用され、SnapshotExecutor はスナップショットの実際のストレージ、リモートインストール、およびレプリケーション管理に使用されます。

ステートマシン:

StateMachine: ユーザーのコアロジックの実装。中核となるのは onApply(Iterator) メソッドで、Node#apply(task) によって送信されたログをビジネスステートマシンに適用します。
FSMCaller: ビジネス StateMachine の状態遷移の呼び出しやログの書き込みなどをカプセル化します。有限ステートマシンの実装であり、必要なチェック、マージ送信の要求、並行処理などを実行します。

コピー：

レプリケーター: リーダーがフォロワーにログを複製するために使用します。これは、ハートビートの生存チェックなどを含む、ラフトの AppendEntries 呼び出しです。
ReplicatorGroup: 単一の raft グループがすべてのレプリケーターを管理し、必要な権限チェックと配布を実行します。

RPC モジュールは、ノード間のネットワーク通信に使用されます。

RPC サーバー: ノードに組み込まれた RPC サーバーは、他のノードまたはクライアントからの要求を受信し、対応するサービスに転送して処理します。
RPC クライアント: 投票、ログのコピー、ハートビートなど、他のノードへのリクエストを開始するために使用されます。

KV ストア: SOFAJRaft は単なるライブラリです。 KV ストアは、SOFAJRaft の典型的なアプリケーションシナリオです。 SOFAJRaft をより良く理解するために図にしました。

SOFAJRaft - ラフトグループ

SOFAJRaft - マルチラフトグループ

3 SOFAJRaft実装の詳細

効率的な線形化可能な読み取り

線形化可能な読み取りとは何ですか?

線形一貫性のある読み取りの簡単な例としては、時刻 t1 に値を書き込むと、t1 以降はこの値を確実に読み取ることができ、t1 より前の古い値を読み取ることは不可能である、というものがあります (Java の volatile キーワードについて考えてみましょう。簡単に言えば、線形一貫性のある読み取りとは、分散システムで volatile セマンティクスを実装することです)。

上の図では、クライアント A、B、C、D はすべて線形一貫性読み取りに準拠しています。その中で、D は古臭い読み物のように見えますが、そうではありません。 D の要求は 3 つの段階にまたがり、読み取りはいつでも発生する可能性があるため、読み取り 1 または 2 で問題ありません。

重要: 以下の説明は、ビジネスステートマシンの実装が線形一貫性を満たす必要があるという大前提に基づいています。これは、Java の volatile のセマンティクスも備えている必要があることを意味します。

1) もっと直接的に、現在のリーダーノードから直接読み取ることは可能ですか?

現在のリーダーが本当にリーダーであるかどうか (ネットワークパーティション) を判断するにはどうすればよいでしょうか?

2) 最も単純な実装方法: 読み取り要求はラフトプロトコルを経由する

何か質問はありますか？

ログ書き込みのオーバーヘッドが発生するだけでなく、ログレプリケーションの RPC オーバーヘッドも発生するため、読み取り負荷の高いワークロードを持つシステムでは許容されません。
いかだの「ログを読む」もたくさんある

3) ReadIndex 読み取り

これは、raft 論文で言及されている最適化ソリューションです。具体的には：

独自のログの現在のコミットインデックスをローカル変数 ReadIndex に記録します。
他のノードへのハートビートを開始します。ほとんどのノードが対応するハートビート応答を返す場合、リーダーは自分がまだリーダーであることを確信できます (自分自身であることが証明されます)。
リーダーは、適用インデックスが ReadIndex を超えるまでステートマシンの実行を待機します。これにより、リーダーが読み取り時にドリフトしたかどうかに関係なく、安全に Linearizable Read を提供できます (読み取り要求を実行する前に、適用インデックスが ReadIndex を超えるまで待機する必要があるのはなぜかを考えてみてください)。
リーダーは読み取り要求を実行し、結果をクライアントに返します。

ReadIndex を使用すると、フォロワーに対して線形化可能な読み取りを提供することも簡単になります。

フォロワーノードはリーダーから最新の ReadIndex を要求します。
リーダーは上記のプロセスを i から iii まで実行し (本当にリーダーであることを確認するため)、ReadIndex をフォロワーに返します。
フォロワーは、適用インデックスが ReadIndex を超えるまで待機します (問題は何ですか? ノードが遅いのですか?)。
フォロワーは読み取り要求を実行し、結果をクライアントに返します。

ReadIndexの概要:

ラフトログ方式と比較すると、ReadIndex 読み取りではディスクオーバーヘッドが節約され、スループットが大幅に向上します。 SOFAJRaft のバッチ + パイプライン ack + 完全非同期メカニズムと組み合わせると、レプリカが 3 つの場合のリーダー読み取りスループットは RPC の上限に近くなります。
遅延は大多数の心拍応答の中で最も遅いものによって決まるため、理論的には遅延を減らす効果はそれほど大きくありません。

4)リース読み取り

Lease read は ReadIndex に似ていますが、ログだけでなくネットワークのやり取りも排除することでさらに一歩進んでいます。読み取りスループットを大幅に向上し、レイテンシを大幅に削減できます。

基本的な考え方は、リーダーが選出タイムアウトよりも小さい（できれば 1 桁小さい）リースを取得することです。リース期間中は選出が行われないため、リーダーが変更されることはなく、ReadIndex の 2 番目のステップをスキップしてレイテンシを削減できます。ご覧のとおり、Lease Read の正確さは時間に関連しているため、時間の実装が重要です。ドリフトが深刻な場合、このメカニズムに問題が生じます。

実装：

時間指定のハートビートにより、多数決の応答が得られ、リーダーの有効性が確認されます (SOFAJRaft のデフォルトのハートビート間隔は、選出タイムアウトの 10 分の 1 です)。
リースの有効期間中、現在のリーダーはラフトグループ内の唯一の有効なリーダーとみなされ、ReadIndexのハートビート確認ステップ（2）は無視できます。
リーダーは、適用インデックスが ReadIndex を超えるまでステートマシンの実行を待機し、安全に Linearizable Read を提供できるようにします。

5) さらに一歩先へ: 待機無料

これまでのところ、lease は ReadIndex の 2 番目のステップ (ハートビート) を省略しています。実際、さらに一歩進んで、3 番目のステップを省略することもできます。

前回の実装の本質について考えてみましょう。現在のノードのステートマシンは、「読み取り」の瞬間に同じ状態または更新された状態に到達します。

さらに厳しい制約は、現時点では、現在のノードのステートマシンが最新であるということです。

問題は、リーダーノードのステートマシンが最新であることを保証できるかどうかです。

まず、リーダーノードのログは最新のものでなければなりません。新しく選出されたリーダーが選出された場合でも、そのリーダーにはすべてのコミットログが含まれている必要がありますが、その状態マシンは古いリーダーより遅れている可能性があります。
ただし、リーダーが現在の期間の最初のログを適用した後は、その状態マシンは最新の状態である必要があります。
したがって、リーダーが自身の期間の最初のログを正常に適用した後は、コミットインデックスを取得したり、ステートマシンを待機したりする必要はないと結論付けることができます。直接的な読み取りは、間違いなく線形的に一貫した読み取りです。

概要: Wait Free メカニズムにより、読み取り待ち時間が最小限に抑えられます。 SOFAJRaft はまだ待機なしの最適化を実装していませんが、すでに計画に含まれています。

SOFAJRaft で線形化可能な読み取り要求を開始します。

 // KVストレージは線形一貫性読み取りを実装します
パブリックvoid readFromQuorum(文字列キー、AsyncContext asyncContext) {
    // リクエストIDがリクエストコンテキストとして渡される
    byte[] reqContext = 新しいbyte[4];
    Bits.putInt(reqContext, 0, requestId.incrementAndGet());
    // readIndex メソッドを呼び出して、コールバックが実行されるのを待ちます
    this.node.readIndex(reqContext、新しいReadIndexClosure() { 
 
        @オーバーライド
パブリックvoid run(ステータス status, long index , byte[] reqCtx) {
            （ステータスが正常であれば）
                試す {
                    // ReadIndexClosureコールバックが成功し、最新のデータがステートマシンから読み取られ、返されます
                    // 状態の実装にバージョンの概念がある場合は、渡されたログインデックス番号に基づいて読み取ることができます。
                    asyncContext.sendResponse(新しいValueCommand(fsm.getValue(キー)));
                } (KeyNotFoundException e) をキャッチします {
                    asyncContext.sendResponse(GetCommandProcessor.createKeyNotFoundResponse());
                }
            }それ以外{
                // 選挙などの特定の状況では、読み取り要求は失敗します
                asyncContext.sendResponse(新しい BooleanCommand( false 、 status.getErrorMsg()));
            }
        }
    });
 }

SOFAJRaft の 4 つのアプリケーションシナリオ

1 SOFAJRaft で何ができるのか？

選挙
Zookeeperなどの分散ロックサービス
信頼性の高いメタデータ管理
分散メッセージキュー、分散ファイルシステム、分散ブロックシステムなどの分散ストレージシステム。

2 ユーザーケース

AntQ Streams QCoordinator: SOFAJRaft を使用して、コーディネータークラスター内で選択、メタデータの保存、およびその他の機能を実行します。
スキーマレジストリ: Kafka スキーマレジストリに似た、信頼性の高いスキーマ管理サービス。
SOFA サービス登録センターメタ情報管理モジュール: IP データ情報登録では、データの書き込みがすべてのノード間で一貫していること、および少数ノードに障害が発生しても通常のデータストレージが影響を受けないことが求められます。
RheaKV: SOFAJRaft と rocksDB をベースにした、組み込み型、分散型、高可用性、強力な一貫性を備えた KV ストレージライブラリ。

3 簡単な練習: SOFAJRaft をベースにしたシンプルな KV ストアを設計する

今のところ、ライブラリとしての SOFAJRaft に特別な点は見当たりません。zk や etcd は SOFAJRaft でできることはできるようですが、SOFAJRaft は車輪の再発明なのでしょうか?

SOFAJRaft が優れた想像力と拡張性を備えていることを示すために、以下では SOFAJRaft に基づいたより複雑な実践を紹介します。

4 より複雑な実践：SOFAJRaftに基づくRhea KVの設計

機能名詞

PD: クラスター全体のスケジュールを管理するグローバル中央制御ノード。自己管理を必要としないクラスターでは、PD を有効にする必要はありません (1 つの PD で、clusterId に基づいて分離された複数のクラスターを管理できます)。
ストア: クラスター内の物理ストレージノード。ストアには 1 つ以上のリージョンが含まれます。
リージョン: 最小の KV データ単位。各領域には、左が閉じ、右が開いている間隔 [startKey、endKey) があります。リクエストトラフィック/負荷/データサイズなどの指標に基づいて、自動的に分割および自動的に複製できます。

特徴