問題タブ [eventual-consistency]

CAP 定理と NoSQL データの結果整合性の問題について読みました。私が理解しているように、完全な一貫性または完全な可用性を達成することはできますが、両方を達成することはできません。したがって、パフォーマンスが向上すると、古いデータや部分的なトランザクションが発生する可能性があります。そして、私が理解しているように、クラスター化されたデータストレージにはこれまでのところ解決策がありません.

一方、Hazelcast は、完全な一貫性を強制すると主張していIMapます。

質問: Hazelcast はどのように完全なデータの一貫性を強制しますか? RAMに基づいており、可用性を気にしない可能性があるため、それは可能ですか(とにかく可用性が提供されることを意味します)?

そのため、S3 のある場所にオブジェクトがあります。

私のコードは S3 オブジェクトを更新します。ただし、先に進む前に、それが適切に複製されていることを確認する必要があります。

この変更がどこにでも複製されるまで待機/ブロックする方法はありますか?

結果整合性のある分散データストア (私の場合は CouchDB) を使用するファームで Web アプリケーションを実行する場合、特定のユーザーが常に同じデータストア インスタンスに転送されるようにする必要がありますか?

任意の Web リクエストが任意のデータ ストアを使用できる別のアプローチでは、一貫性の問題 (再試行、チェックなど) に対処するためにかなりの複雑さが増すように思えます。一方、特定のセッションのユーザーが常に同じカウチ ノードに向けられている場合、一貫性の問題は主に「共有」ユーザー データに関係しているため、大幅に単純化されませんか?

ユーザーを誘導するための戦略にも興味がありますが、それは別の質問のために取っておきます (コメントを歓迎します)。

Google App Engine の NDB データストアを使用して、新しいエンティティを作成した後、エンティティのリストの強い一貫性の読み取りを保証するにはどうすればよいですか?

ユースケースの例は、従業員の種類のエンティティがあることです。

• 新しい従業員エンティティを作成する
• 従業員のリストをすぐにロードします (追加されたものを含む)

以下のアプローチにより、新しい従業員が含まれている場合と含まれていない場合がある従業員のリストの最終的に一貫した読み取りが得られることを理解しています。これは、後者の場合に悪い経験につながります。

今ここに私が考えたいくつかのオプションがあります：

重要な修飾子

私は、新しい従業員を追加したユーザーのために読み取られた一貫性のあるリストだけを気にします。他のユーザーが最終的な一貫性のある読み取りを行っているかどうかは気にしません。

強力な一貫性のある祖先クエリを有効にするために、すべての従業員を祖先の下に配置したくないと仮定しましょう。何千もの従業員エンティティの場合、1 秒あたり 5 回の書き込み制限は価値がありません。

また、書き込みとリストの読み取りが 2 つの別個の HTTP 要求の結果になるようにしたいとします。理論的には、書き込みと読み取りの両方を 1 つのトランザクション (?) に入れることはできますが、それでは非常に非 RESTful な API エンドポイントになります。

オプション1

• データストアに新しい従業員エンティティを作成します
• さらに、新しい従業員オブジェクトを memcache、ローカル ブラウザー Cookie、ローカル モバイル ストレージに書き込みます。
• 従業員のリストのデータストアをクエリします (結果整合性)
• 新しい従業員エンティティがこのリストにない場合は、memcache / ローカル メモリから (アプリケーション コードで) リストに追加します。
• 結果をユーザーに表示します。ユーザーが新しい従業員エンティティを選択した場合、key.get() を使用してエンティティを取得します (強い整合性)。

オプション 2

• トランザクションを使用して新しい従業員エンティティを作成する
• トランザクション内の従業員のリストについてデータストアにクエリを実行する

オプション＃2が実際に機能するかどうかはわかりません。

• 技術的には、そのエンティティの読み取りトランザクションが発生する前に、前の書き込みトランザクションがすべてのサーバーに書き込まれますか? それとも、これは正しい動作ではありませんか?
• トランザクション (XG を含む) にはエンティティ グループの数に制限があり、従業員のリスト (それぞれが独自のエンティティ グループ) はこの制限を超える可能性があります。
• 読み取り専用トランザクションと通常の読み取りの欠点は何ですか?

考え？オプション #1 は機能するように見えますが、後続の読み取りで一貫性を確保するのは大変な作業のようです。

共有変数 x、y、および z にアクセスする 2 つのプロセスがあります。各プロセスは、これらの変数を保持するために使用されるストアの異なるレプリカにアクセスします。x、y、z の値は最初は 0 です。

プロセス 1:

そしてプロセス 2:

両方のステートメントを完了した後、a) シーケンシャルおよび b) カジュアル一貫性モデルにおける z の可能な値は何ですか?

逐次一貫性では、プログラムによって指定された順序でプロセスが実行されることを知っています。上記の例では、2 つのプロセスがプロセスで指定された順序で同時に実行されるため、順次整合性モデルでは z の結果はゼロになると思います。そのため、if 条件は実行されません。しかし、よくわかりません。

カジュアルなものの場合、関連する書き込みはすべてのプロセスで同じ順序にする必要があります。同時書き込みは異なる順序にすることができます。このルールがこの例でどのように機能するかわかりません。

3 つのデータ センターに分散された mongo の操作

この例では、データセンター名は A、B、C です

すべてが順調に進んでいる場合、すべてのユーザー トラフィックは A に向けられます

したがって、mongo プライマリは A にあり、mongo セットアップは次のとおりです。

• A に 3 台のサーバー (優先度が高い)
• B に 1 台のサーバー (優先度が低い)
• C の 1 サーバー (優先度 0 )

問題は、2 つのシナリオが発生した場合の mongo-writes のサポートです。

1. ABC 間にネットワークがない (ネットワーク トンネルがダウンしている)
2. データ キャンター A が燃えています :)、データ センターが機能していないとします。この時点で、すべてのユーザー トラフィックが B に向けられており、B での予備選挙が予想されます。

シナリオ 1 は問題ではありません。データセンター ネットワーク トンネルが存在しない場合、A には依然として大部分のレプリカがあり、優先度が高いため、すべてがまだ機能しています。

シナリオ 2 は機能しません。これは、A が動作を停止した場合、(A 上の) 3 つのレプリカすべてに到達できないためです。このように、レプリカの大部分がダウンしているため、B または C で新しいプライマリが再処理されることはありません。

2 つのシナリオをサポートするようにレプリカ セットをセットアップするにはどうすればよいですか?

（これを説明する適切な情報源が見つからなかったので、他の場所で入手できる場合は、それを指摘してください）

1. Hazelcast は、クラスター内のすべてのノードにわたってデータを複製します。では、ノードの 1 つでデータが変更された場合、そのノードは自身のコピーを更新し、それを他のノードに伝播しますか?

2. 各データがノードによって所有されていることをどこかで読みましたが、Hazelcast はどのように所有者を決定しますか? 所有者はデータ構造ごと、またはデータ構造内のキーごとに決定されますか?

3. Hazelcast は「結果整合性」の原則に従っていますか? (データがノード間で伝播されている場合、ノード間でデータの一貫性が失われる小さなウィンドウが発生する可能性があります)

4. 競合はどのように処理されますか? (2 つのノードが同じキー値を同時に更新します)

次のようなメソッドがあると想像してください。

注文がデータベースに保存された後、イベントがメッセージ キューイング システムにパブリッシュされ、同じマシンまたは別のマシン上の他のサブシステムがそれを処理できるようになります。

しかし、this.bus.Publish(new OrderPlaced(Order))呼び出しが失敗した場合はどうなりますか? または、注文をデータベースに保存した直後にマシンがクラッシュしますか? イベントは発行されず、他のサブシステムはそれを処理できません。これは受け入れがたい。これが発生した場合、イベントが最終的に公開されるようにする必要があります。

使用できる受け入れ可能な戦略は何ですか? どれが最高ですか？

注: 分散トランザクションを使用したくありません。

編集：

Paul Sasik は非常に近く、100% 達成できると思います。これは私が考えたことです：

最初に、次のようにデータベースにテーブル Events を作成します。

int の代わりに GUID を使用したい場合や、シーケンスまたは ID を使用したい場合があります。

次に、次の擬似コードを実行します。

すべてのイベントに EventId を含める必要があります。イベント サブスクライバーがイベントを受信すると、最初にデータベース内の EventId の存在を確認します。

このようにして、99.999% だけでなく、100% の信頼性が得られます。