クロスリージョンシナリオで分散システムの一貫性を解決するにはどうすればよいでしょうか?

[[377361]]

クロスリージョンとは、一般的に知られている「異地域デュアルアクティブ」や「異地域マルチアクティブ」における異なる地域の概念を指します。当社のビジネスが急速に成長するにつれ、ローカル アクセスと地域間の災害復旧のニーズを満たすために、サービスを地域全体に展開する必要が生じています。このプロセスでは、リージョン間での分散一貫性の問題が避けられません。地域間操作によって発生するネットワーク遅延の問題と、ネットワーク遅延から生じる一連の問題は、地域間分散一貫性システムの設計と構築にとって大きな課題です。この問題に対する解決策は業界内に数多く存在し、いずれも地域をまたぐシナリオにおける一貫性の問題を解決することを目的としています。

この記事では、Alibaba Nuwa チームによるクロスリージョン シナリオでの分散一貫性システムの調査について説明します。 「What How Future」の3つの側面から、クロスリージョンシナリオで取り組むべきニーズと課題、業界の共通システム、Nuwaチームのクロスリージョンシナリオのトレードオフに関する考え方、およびクロスリージョン一貫性システムの将来の開発に関する設計と考え方を紹介し、クロスリージョンシナリオにおけるより多くのニーズと課題を発見して解決します。

1. 地域間のニーズと課題

[[377362]]

1. 要件

地域をまたぐ課題は、グループのグローバル化戦略のもとでの事業の急速な発展によってもたらされた課題です。例えば、Taobao のユニット化されたビジネスや AliExpress の地域化されたビジネスでは、地域間でのデータの読み取りと書き込みの一貫性という避けられない問題があります。

その中核となる要件は次のように要約できます。

地域間ビジネスシナリオ

リージョン間の構成同期とサービス検出は、リージョン間の一貫性調整サービスの 2 つの一般的なビジネス要件です。クロスリージョン展開により、ローカル アクセス機能が提供され、サービスの遅延が短縮されます。具体的なビジネス シナリオに応じて、マルチリージョン書き込みまたは簡略化されたシングルリージョン書き込み、強力な一貫性読み取りまたは最終的な一貫性読み取りのシナリオに分けることができます。地域間セッション管理とそれに基づく地域間分散ロックにも、成熟したソリューションが早急に必要です。

サービスとリソースの拡張の問題

ある地域内のデータセンターのサービス容量が上限に達して拡張できない場合、地域内および地域をまたいで複数のデータセンターに水平拡張できる一貫したシステムが必要です。

地域間災害復旧機能

データ センターまたはリージョンで壊滅的な障害が発生した場合、リージョン間のサービス展開を通じてビジネスをあるリージョンから別のリージョンに迅速に移行し、災害復旧を完了して高可用性を実現するための一貫したシステムが必要です。

2つの課題

ネットワークの遅延とビジネス要件を考慮すると、クロスリージョン整合性システムが対処する必要がある課題をまとめることができます。

遅延: ネットワーク遅延は数十ミリ秒

マルチリージョン展開によってもたらされる主な問題は、ネットワーク遅延が大きくなることです。当社のオンライン クロスリージョン クラスターを例にとると、クラスター内のマシンは杭州、深セン、上海、北京のコンピューター ルームに配置されています。実際のテストでは、杭州のコンピューター室から上海までの遅延は約 6 ミリ秒で、深センと北京までの遅延は 30 ミリ秒近くに達する可能性があります。同じコンピュータ ルームまたは地域内のコンピュータ ルーム間のネットワーク遅延は、通常、数ミリ秒以内です。比較すると、地域間アクセスの遅延は 1 桁増加します。

水平拡張: クォーラムサーバーのサイズは制限されています

Paxos 理論とその派生に基づく分散一貫性システムでは、ノードを拡張するときに必然的にレプリケーション オーバーヘッドの問題が発生します。通常、クォーラム内のノード数は 9 以下であるため、一貫性システム ノードを複数のリージョンに直接デプロイすることはできません。サービスとリソースの拡張ニーズを満たすために、システムは継続的に水平方向に拡張できる必要があります。

ストレージ制限: 単一ノードではストレージデータが制限され、フェイルオーバーの回復が遅くなります。

MySQL であっても Paxos ベースの整合性システムであっても、単一のノードがミラー データの全量を維持してロードし、単一のクラスターの容量によって制限されます。同時に、フェイルオーバーリカバリ中にデータバージョンが大幅に遅れている場合、他のリージョンからイメージをプルしてリカバリすると、使用不可の期間が長くなります。

私たちの探検

1 業界ソリューション

業界には、主に論文[1]といくつかのオープンソース実装を参考にした、クロスリージョン一貫性システムの設計が数多く存在します。一般的なものは次のとおりです。

地域間展開

図1 直接的なクロスリージョン展開

直接的なクロスリージョン展開、読み取り要求はローカル ドメイン ノードを直接読み取り、速度は速く、一貫性と可用性は Paxos によって保証され、単一点の問題はありません。欠点も明らかです。最初の部分で説明した水平拡張の問題、つまりクォーラムを拡張するとレプリケーション オーバーヘッドの問題が発生します。クォーラムノードの数が増えると、リージョン間のネットワーク遅延が非常に高くなるため、毎回多数派が合意に達するまでに長い時間がかかり、書き込み効率が非常に低くなります。

単一リージョン展開 + 学習者ロール

図2 学習者の役割の紹介

データ同期のみを実行し、多数決には参加しないロールである学習者ロール（zkのオブザーバーやetcd[2]のラフト学習者など）を導入することにより、書き込み要求は特定のリージョン（図2のリージョンAなど）に転送され、直接マルチノード展開の投票遅延問題を回避します。この方法では、水平拡張とレイテンシの問題を解決できますが、投票に参加するロールがすべて 1 つのリージョンに展開されるため、このリージョンのデータ センターで壊滅的なイベントが発生すると、書き込みサービスが利用できなくなります。これはOtter[3]が採用した展開方法です。

マルチサービス + パーティション & 単一リージョンのデプロイメント + 学習者

図3 複数のサービス処理パーティション

データはルールに従って異なるパーティションに分割されます。各リージョンでは、サービスを提供するためにクォーラムが使用されます。異なるリージョンのクォーラムは、異なるパーティションを担当します。リージョン間のクォーラムは Learner を使用して異なるパーティション内のデータを同期し、書き込み要求を転送して、特定の領域の問題がその領域のパーティションの可用性にのみ影響するようにします。同時に、このソリューションには正確性の問題があり、つまり、操作は順次一貫性に準拠していません[4]（論文[1]を参照）。

実際の実装では、ビジネス シナリオに基づいてさまざまなソリューションがあり、欠点を補うためにターゲットを絞った最適化とトレードオフが行われます。業界でより一般的なソリューションは、単一リージョン展開 + 学習者ロール ソリューションです。これにより、同じ都市内の複数のアクティブ サーバーと学習者によるリージョン間のデータ同期を通じて、より高い可用性と効率性が保証されます。他のソリューションにも独自の最適化ソリューションがあります。クロスリージョン展開では、TiDBのフォロワーレプリケーション[5]のように、解決に達したときにリージョン間の通信を減らすことで、レイテンシと帯域幅の問題を軽減できます。マルチサービス + パーティションと単一リージョンのデプロイメント + 学習者ソリューションの正確性は、論文[1]で説明されているように、一貫性を確保するために読み取りの可用性をある程度犠牲にして、読み取り前に同期操作を追加することによっても実現できます。

最終的な結論は以下のとおりです。重要な項目については後ほど詳しく説明します。

2. 地域間のトレードオフ

最初の部分でまとめた需要の課題と、業界におけるクロスリージョン整合性システム ソリューションに関するこれまでの調査に基づいて、クロスリージョン シナリオにおける Paxos ベースの分散整合性システムの中核となるトレードオフをまとめることができます。

• 一貫性プロトコルがリージョン間の書き込み操作の解決に到達するまでに時間がかかりすぎる
• リージョン内の複数のアクティブノードは、極端な状況では可用性を提供できない
• 分散システムの中核となる水平拡張能力が必要

これら 3 つの問題に対処するために、分離されたログミラーリングを備えたクロスリージョン整合性システムを設計しました。

3. リージョン間ログミラーリングの分離

図4 ログミラー分離の概略図

図 3 に示すように、私たちのシステムは、バックエンドのログ同期チャネルと、ログを画像から分離するアーキテクチャであるフロントエンドのフル ステート マシンに分かれています。バックエンドのクロスリージョン グローバル ログ同期チャネルは、さまざまなリージョンのリクエスト ログの強力な一貫性を確保する役割を担います。フロントエンドのフル ステート マシンは、クライアント要求を処理するために各リージョンに展開され、バックエンド ログ サービスと対話し、外部にグローバルな強力な一貫性メタデータ アクセス サービスを提供する役割も担います。インターフェースは、ビジネス ニーズに応じてステート マシンを迅速に変更できます。

グローバルログとローカルイメージを分離したアーキテクチャでは、分離自体によってもたらされるシステム運用・保守性やスケーラビリティの向上に加え、非分離アーキテクチャにおける多くの課題も解決できます。次の分析は、このアーキテクチャで以前に検討されたいくつかの主要な問題に対する解決策です。

書き込み操作の効率

デプロイメント モードだけから判断すると、複数のリージョンに複数のノードを直接デプロイし、各リージョンに Learner ロールを追加するのと似ているようです。これは、直接的なマルチノード展開と Learner の導入を組み合わせたもので、両方の方法の長所と短所を組み合わせています。最大の違いは、ログとミラーが分離されていることです。つまり、クロスリージョン部分は軽量で十分に効率的な単純なログ同期であり、各リージョンにノードが 1 つしかないため、クロスリージョン帯域幅を節約できます (TiDB のフォロワー レプリケーションと同様)。同時に、バックエンド ログ同期チャネルはマルチグループ機能を実装し、データをパーティションに分割し、各整合性グループが異なるパーティションを担当することもできます。

ほとんどのビジネス シナリオでの読み取り操作はローカル データを読み取ることなので、さまざまな方法に大きな違いはありません。主な分析は書き込み操作のレイテンシに関するものです。以下は、書き込み操作 (または強力な一貫性の読み取り) のレイテンシ分析です。

RTT (ラウンドトリップ時間) は、送信者がリクエストを送信して応答を受信するまでにかかる時間として簡単に理解できます。地域間ネットワークの遅延が大きいため、以下の RTT は主に地域間 RTT を指します。

（１）直接的な地域間展開

一般的なマスター一貫性プロトコルの場合、リクエストは次の 2 つのケースに分けられます。

リーダーが配置されている領域にアクセスするための 1 RTT (現時点では領域内の小さな遅延は無視します)

クライアント -> リーダー----> フォロワー ----> リーダー -> クライアント 

フォロワー領域にアクセスするための 2 RTT

クライアント -> フォロワー----> リーダー ----> フォロワー ----> リーダー ----> フォロワー ->  

（２）単一地域展開＋学習者同期

リージョン内の複数のアクティブ サーバーとリージョン間の学習者の同期のソリューションでは、レイテンシは次のようになります。

ローカルドメインの RTT は 0 です

クライアント -> クォーラム -> クライアント

地域間のRTTは1

クライアント -> 学習者----> クォーラム ----> 学習者 -> クライアント 

（３）マルチサービス分割、単一リージョン展開＋学習者同期（Bの結果と同様）

ローカルドメインパーティション0 RTTの書き込み

パーティション間で1 RTTを書き込む

（４）ログミラー分離アーキテクチャ（A結果と同様）

ローカルドメイン パーティション 1 RTT の書き込み

クライアント -> フロントエンド -> LogChannel( local ) ----> LogChannel (ピア) ----> LogChannel (ローカル) -> フロントエンド -> クライアント 

パーティション全体に 2 つの RTT を書き込む (Paxos 2 フェーズ コミット/フォワード リーダー)

クライアント -> フロントエンド -> LogChannel (ローカル) ----> LogChannel (ピア) ----> LogChannel (ローカル) ----> LogChannel (ピア) ----> LogChannel (ローカル) -> フロントエンド -> クライアント 

上記の比較から、リージョン間の書き込み操作に一貫性プロトコルが使用されている限り、少なくとも 1 RTT の遅延が発生することがわかります。 Paxos Quorum が単一のリージョンにのみ展開されている場合、極端な状況では可用性が保証されません。したがって、ビジネス ニーズに基づいて、可用性と書き込み効率の間でトレードオフを行うことができます。ログミラー分離アーキテクチャにより、マルチリージョン展開シナリオで極めて高い可用性と正確性を確保できます。もちろん、単一リージョン展開 + 学習器よりも効率は若干悪くなりますが、複数の積分システムを使用する場合、水平拡張によりクォーラム規模が増加せず、投票効率に影響を与えないため、直接のマルチリージョン展開よりも軽量で効率的になります。複数のサービスをパーティションに展開するソリューションには効率性の利点はありませんが、操作性、保守性、正確性、可用性の点で利点があります。

一貫性

クロスリージョン展開と単一リージョン展開 + Learner の強力な一貫性が満たされます。 Zookeeper と etcd には対応する紹介がありますが、ここでは繰り返しません。マルチサービス パーティショニング ソリューションは、次の図に示すように、主にマルチサービスが各書き込み操作のコミット順序を保証できないため、順次一貫性の要件を満たしません。

図5 順序一貫性

2 つのクライアントが同時に x と y を変更する場合、書き込み操作の同時実行性が高いと順次一貫性が保証されないことがわかります。

順次一貫性とは、各クライアントの操作を正しい順序で並べることができることを意味します。図4の例では、

 set1(x,5) => get1(y)->0 => set2(y,3) => get2(x)->5

または

set2(y,3) => get2(x)->0 => set2(y,3) => get1(y)->3

それらはすべて順次一貫性があります。

ログミラー分離アーキテクチャの一貫性は、クロスリージョン展開 + Learner として簡単に理解できます。書き込み操作には同期オプションがあり、バックエンド ログが正常に送信され、対応するログがプルされた場合にのみ成功が返されます。したがって、この操作の前に他のクライアントの書き込み操作に対応するログをプルできる必要があり、それによって順次一貫性が満たされます。

可用性

可用性は、直接的なクロスリージョンのマルチノード展開の可用性と同様です。フロントエンド ステート マシンは、特定のリージョンのバックエンド ノードに障害が発生した場合に要求を転送できます。また、バックエンドのグローバル ログ サービスが利用できない場合でも読み取りの可用性を提供でき、極端な状況でも読み取りと書き込みの高可用性保証を提供できます。

同時に、イメージは各リージョンのステートマシンに保存されるため、フロントエンドのステートマシンに障害が発生した場合、クライアントを他のフロントエンドに切り替えることができます。フェイルオーバーが復元されると、バックエンドからデータを直接取得して回復できます。遅延が大きすぎる場合にのみ、ローカル ドメイン内の他のフロントエンドからイメージを取得する必要があります。リージョン間でイメージを同期する必要がないため、フロントエンドが利用できない時間を短縮できます。

水平拡張能力

水平スケーラビリティは分散サービスの中核機能です。前述のさまざまなソリューションの中で、直接的な地域間展開は水平方向のスケーラビリティが極めて低いです。 Learner に依存する他の方法も水平スケーラビリティの問題を解決しますが、分離設計はログミラー分離設計ほど明確ではありません。

上記の主要な問題を要約して比較します。

地域を超えたさらなる可能性

バックエンド ログとフロントエンド イメージが分離されているため、クロスリージョン シナリオの調査は、軽量で効率的なバックエンド ログ同期と、柔軟で豊富なフロントエンド ステート マシンの 2 つの部分に分かれています。

• 軽量さはアーキテクチャに反映されています。バックエンドはログのみを同期するため、バックエンドのストレージにほとんど負荷がかかりません。軽量の増分ログのみを同期する必要があります。
• 効率性はバックエンドの一貫性プロトコルに反映されます。軽量なので、投票と選出のロジックのみを考慮し、ログ同期の効率化に注力すれば良いです。バックエンド リソースを他のビジネス ロジックで使用する必要はありません。
• 柔軟性はアーキテクチャに反映されています。フロントエンドではアップロードされたログをカスタマイズできます。 CAS、トランザクションなどはすべてログにパッケージ化され、フロントエンドによって解析および処理されます。
• 豊富さは主にフロントエンドのステートマシンに反映されます。丸太の柔軟性により、探索と構築の余地が広がります。ニーズに応じてさまざまな複雑なトランザクションを処理するためのステート マシンをパッケージ化できます。

新しいアーキテクチャでは新たな問題が発生します。この部分では、主に、既存システムの利点を吸収し、ログミラーリングの軽量で柔軟な分離を使用して、地域間シナリオで効率的で豊富な一貫性プロトコルとステートマシンを実現する方法について説明します。また、今後地域間一貫性システムをどのように発展させていくかについても考えや計画を練る予定です。全体的な目標は、バックエンドの一貫性プロトコルを改良して深化させ、フロントエンドのステートマシンをより大きく、より強力にすることです。

1 効率的なバックエンド一貫性プロトコル

書き込み操作の効率に関する前回の説明に基づくと、複数のリージョンに同じデータを書き込む場合、レイテンシは 2 RTT 以内にしか制御できません。リージョン間のシナリオでは、主な遅延要因はリージョン間のネットワーク通信にあります。マスター側転送でも、マスターレス Paxos 2 フェーズ コミットでも、レイテンシは 2RTT です。しかし、Paxosの変種であるEPaxos[6]などのマスターレスプロトコルを使用すると、地域間シナリオでの書き込み効率を最大限に向上させることができます。レイテンシは、Fast Path と Slow Path の 2 つのケースに分けられます。 Fast Path のレイテンシは 1RTT で、Slow Path のレイテンシは 2RTT です。

EPaxos を紹介する記事から一文を引用します。

同時提案のログ間に競合がない場合、EPaxos は送信するために PreAccept フェーズのみを実行する必要があります (高速パス)。競合がない場合は、送信するために Accept フェーズを実行する必要があります (低速パス)。

パーティション操作と比較して、バックエンドの一貫性プロトコルとして EPaxos を選択した場合、極端なケースでの可用性と、ほとんどの場合での 1RTT の遅延が保証されます。これは、主にリーダー操作の転送の RTT を節約できるため、クロスリージョン シナリオにおけるマスターレス一貫性プロトコルの利点です。現在、当社のシステムでは最も基本的な Paxos 実装を使用しています。理論的には、マルチリージョン書き込みシナリオのレイテンシは、マスター プロトコルのレイテンシとそれほど変わりません。今後の開発では、EPaxos を使用して、リージョン間シナリオでの書き込み操作の効率を向上したいと考えています。

さまざまなビジネス ロジックを実装する必要がないため、効率性がバックエンド一貫性プロトコルの最大の要求となります。もちろん、その正確性や安定性も不可欠です。フロントエンドのステートマシンには、設計して実行できるさまざまなシナリオがあります。

CAS オペレーション

このアーキテクチャの下での CAS 操作の実装は非常に自然です。バックエンドには一貫性ログしかないため、CAS リクエストごとにコミット命令が自然に発生します。例を見てみましょう。

2 つのクライアントが同時に同じキーの値を書き込みます。

図6 CAS動作図

最初、キーの値は 0 です。この時点で、クライアント 1 とクライアント 2 は、キーに対して CAS 操作、つまり CAS(key, 0, 1) と CAS(key, 0, 2) を同時に実行します。これら 2 つの操作が同時に送信され、コミットされると、バックエンド クォーラムが解決に達する順序に応じて、レプリケーション ログにシーケンスが設定されることになります。したがって、これら 2 つの同時 CAS 操作は、自然に順次実行に変換されます。フロントエンドがこれら 2 つの操作のログを同期すると、これら 2 つの操作がローカル ステート マシンに順番に適用されます。当然、CAS (key, 0, 1) は成功し、キーの値が 1 に更新されますが、CAS (key, 0, 2) は更新に失敗します。このとき、フロントエンドは、CAS リクエストが成功したか失敗したかの結果を、対応するリクエスト クライアントに返します。

原則としては、同時実行操作を順次実行されるシリアル プロセスに変換し、リージョン間のシナリオをロックする必要性を回避します。バックエンドが kv 構造データを保持している場合、この操作を完了するにはクロスリージョン分散ロックを追加する必要があり、これは比較的面倒で、効率が保証されないと考えられます。ログを同期し、複雑な計算をフロントエンドに転送するだけで、フロントエンドのステートマシンを柔軟に構築し、CASやより複雑なトランザクション機能をより適切に実装できます（このアーキテクチャについては、PravegaのStateSynchronizer[7]を参照してください）。

グローバルID

グローバル ID は一般的な要件です。分散システムは一意の ID を生成します。一般的な方法としては、UUID、スノーフレーク アルゴリズム、またはデータベース、Redis、Zookeeper に基づくソリューションの使用などがあります。

Zookeeper の znode データ バージョンを使用してグローバル ID を生成するのと同様に、このログ ミラー分離アーキテクチャでは、CAS インターフェイス呼び出しを使用してキーをグローバル ID として生成し、そのたびにグローバル ID に対してアトミック操作を実行できます。上記の CAS 設計に基づくと、リージョン間の同時実行シナリオではロックは必要なく、その使用法は Redis のキーに対するアトミック操作に似ています。

2 ウォッチ操作

サブスクリプション機能は分散調整サービスに不可欠であり、最も一般的なビジネス要件です。以下は、zk と etcd に関する調査結果です。

現在、サブスクリプション通知を実装する業界で最も成熟した分散調整システムには、ETCD と ZooKeeper があります。これら 2 つのシステムを例に、それぞれのソリューションについて説明します。

ETCD はデータの複数の履歴バージョン (MVCC) を保存し、単調に増加するバージョン番号を使用してバージョンの新しさを示します。クライアントが関心のある履歴バージョンを渡す限り、サーバーは後続のすべてのイベントをクライアントにプッシュできます。

Zookeeper はデータの複数の履歴バージョンを保存せず、現在のデータ ステータスのみを保存します。クライアントはデータの履歴バージョンをサブスクライブできません。クライアントは現在のステータス後の変更イベントのみをサブスクライブできるため、サブスクリプションには読み取りが伴います。サーバーは現在のデータをクライアントに送信し、後続のイベントをプッシュします。同時に、フェイルオーバーなどの異常なシナリオで古いデータやイベントへのサブスクリプションを防止するために、クライアントは古いデータを持つサーバーへの接続を拒否します (これは、サーバーが各リクエストで現在のサーバーのグローバル XID を返すことに依存します)。

上記の調査結果の中で、ETCD は当社のインターフェース デザインとより一致しています。現在、ETCDv3 は HTTP/2 TCP リンク多重化を使用しており、監視パフォーマンスが向上しています。どちらもログとステート マシンの構造であるため、関数を設計する際の主な参照は ETCD v3 であり、複数のキーをサブスクライブしてすべての履歴イベントを返すという 2 つの機能を活用します。 etcdサブスクリプション機能を実現するために、フロントエンドのステートマシンがログを同期して解析する際に、ログの書き込みが発生すると、kv構造体のステートマシンStoreとwatchインターフェースに特別に用意されたステートマシンwatchableStoreが同時に更新されます。具体的な実装では etcd を参照することができ、サブスクリプション バージョン以降のすべての履歴イベントがログ バージョン番号に従ってクライアントに返されます。複数のキーをサブスクライブすると、ウォッチャー範囲キーのストレージ構造としてセグメント ツリーも使用され、ウォッチャー範囲キーのウォッチャー通知を実装できます。

3 リースの仕組み

所有者のいないシステムで効率的なリース メカニズムを実装することは大きな課題です。所有者なしのシステムでは、リーダーは存在せず、どのノードもリースを維持できます。リースはノード間で分散されます。ノードが利用できない場合は、他のノードへのスムーズな切り替えが必要です。所有者なしのシステムで効率的なリース メカニズムを実装する際の難しさは、リースの数が増えるにつれて、バックエンドの一貫性プロトコルに大量のリースのメンテナンス メッセージが表示され、システムのパフォーマンスに影響するのを回避する方法にあります。リース メンテナンス メッセージをバックエンドを経由せずにフロントエンドで直接処理できるようにすることが最適です。したがって、私たちのアイデアは、クライアントとフロントエンド間のリースをフロントエンドとバックエンド間のリースに集約し、リースメンテナンスメッセージをフロントエンドでローカルに直接処理できるようにすることです。

結論

グローバル化戦略の進展に伴い、地域間ニーズはますます緊急となり、地域間シナリオの本当の問題点もますます明確になります。私たちの地域横断的な研究と調査が、皆様に何らかのアイデアや参考資料を提供できれば幸いです。また、クロスリージョンログミラーリング分離のアーキテクチャの下で、さらなる可能性を模索し続けます。

関連リンク

[1]https://www.usenix.org/conference/atc16/technical-sessions/presentation/lev-ari

[2]https://github.com/etcd-io/etcd/blob/master/Documentation/learning/design-learner.md

[3]https://github.com/alibaba/otter

[4]https://zhuanlan.zhihu.com/p/43949695

[5]https://zhuanlan.zhihu.com/p/94663335

[6] https://zhuanlan.zhihu.com/p/163271175

[7]https://github.com/pravega/pravega/blob/master/documentation/src/docs/state-synchronizer-design.md