問題タブ [eventual-consistency]

結果整合性のあるハイレプリケーションデータストアでAppEngineを使用しています。シャードカウンターも使用しています。

すべてのシャードを照会して合計すると、カウントが強く一貫していると想定できますか？つまり、以下のコードはシャードカウントの正確な合計を返しますか？

I'm digging into CQRS and I am looking for articles on how to solve client reads in an eventual consistent system. Consider for example a web shop where users can add items to their cart. How can you ensure that the client displays items in the cart if the actual processing of the command "AddItemToCart" is done async? I understand the principles of dispatching commands async and updating the read model async based on domain events, but I fail to see how this is handled from the clients perspective.

RavenDB (ビルド 888) の DocumentConvention のデフォルト ctor は、DefaultQueryingConsistency を MonotonicRead に設定します。私が理解しているように、これはデフォルトでは、書き込み後にインデックスが更新されるのを待つことを意味します。誤解しないでほしいのですが、これは (特に統合テストでは) 簡単にするための素晴らしいニュースですが、結果整合性という RavenDB のマントラの一部であると私が理解していたことに反します。

ConsistencyOptions.cs で参照されている記事を読みましたが、MonotonicRead と ReadYourWrites の違いについて混乱しています - 私には同じように見えます。

では、これら 2 つの一貫性モデルの違いは何ですか? また、それは RavenDB の一貫性モデルとどのように関係しているのでしょうか?

CQRS は、すぐに一貫性のあるモデルの事後条件をどのように処理しますか? このようなことは、イベント ソーシングなどを使用した最終的に一貫性のあるシステムでは無関係であることに気付きました。しかし、バニラ CQRS を単純なインターフェイスに適用したいだけの場合、事後条件をどのように記述すればよいでしょうか? CQRS の考えは常に結果整合性を前提としていますか?

クラッド:

CQRS:

まず、Pymongo Documentationで言われていることは次のとおりです

デフォルトでは、スレッドが最初に MongoDB で操作を実行するときに、PyMongo は各スレッドのリクエストを開始します。これにより、**read-your-writes の一貫性が保証されます。リクエスト内では、スレッドは引き続き同じソケットを排他的に使用し、スレッドが end_request() を呼び出すか終了するまで、他のスレッドはこのソケットを使用しません。その時点で、ソケットは接続プールに返され、他のスレッドで使用できるようになります。

Mongodb (Asyncmongo、Motor など) に非同期ライブラリを使用する場合、ユーザーは呼び出しのブロックのような一貫性や結果整合性を持ちますか?

「トランザクションの使用」の 2 番目の例を考えてみましょう (「名前付きキーでエンティティを更新するか、まだ存在しない場合は作成します」)。

https://developers.google.com/appengine/docs/java/datastore/transactions

ここで、このシナリオを考えてみましょう。マルチプレイヤー ゲームでは、任意の 2 人のプレイヤー間で 1 つの対戦のみが許可されます。これを確実にするために、各プレーヤーのキーを使用してキーが作成されます。このキーは、UniqueMatch エンティティのキ​​ーとして使用されます。

したがって、一致を作成するために、XG トランザクションが作成されます。このトランザクション内:

1. そのキーを持つ UniqueMatch エンティティがまだ存在しないかどうかを確認します。そのキーを使用した datastore.get() 呼び出しが EntityNotFoundException をスローしない場合、これら 2 人のプレイヤー間の一致が既に存在することがわかっているため、rollback() してプレイヤーにエラー メッセージを表示します。

2. 一致を作成するために配置する必要があるすべてのエンティティを put() します。これには、UniqueMatch エンティティと、その他のいくつかのエンティティが含まれます。

3. その後、トランザクションがコミットされます。

これはうまくいくようです。ただし、短い時間枠内で任意の 2 人のプレイヤー間で 2 つのマッチを作成できることに気付きました。少しの間 (実際には、テストの 1 つで最大 10 ～ 20 秒)、datastore.get(key) への呼び出しで、そのキーが既に put() されているにもかかわらず、EntityNotFoundException がスローされます。

これは結果整合性のようです。しかし、キーによるエンティティの取得は、強い整合性が保証されているのではないでしょうか? この保証は、これが XG トランザクション内で行われるという事実によって影響を受けますか?

前もって感謝します、

重複の可能性:
結果整合性

私はNosqlを初めて使用します。多くのドキュメントを読んでいますが、それらはすべて結果整合性について話しているだけで、説明していません。どのように機能しますか。

だから、誰かが私が説明するのを手伝ってくれる？

ありがとう、

結果整合性に関するかなりの数のリソースを調べましたが、それらはすべて、結果整合性が重要である理由と、Paxos とビザンチンの一般的な問題などについて語っています。私がより興味を持っているのは、長距離ネットワーク上で結果整合性を実際に実装または保証することについて知ることです。何をする必要があるか、課題は何か、結果整合性を妨げる可能性のあるものを回避および防止および保護するための可能な方法です。あなたの個人的な経験からあなたが知っているかもしれないリンクまで、何でも本当に役に立ちます. ありがとう！

私はすでに答えを知っているのではないかと思いますが、誰かがこれまでに見つけられなかった代替の解決策を提供できることを望んでいます。いつものように、効果的な骨材設計に従ってDDDを実行することは、私が思っていたよりも難しいですが、これが私のシナリオです。

• UserとRoleGroupの2つのARがあります
• ユーザーには特定のRoleGroupを付与できるため、そのロールグループ内のRoles（コレクション値オブジェクト）によって提供されるアクセス許可を取得できます。ロールグループのIDは、別のVAとしてユーザーARに保持されます。
• RoleGroupがシステムから削除されると、ハンドラーがそのRoleGroupを参照しているすべてのユーザーを検索し、参照を削除するために使用するドメインイベントが発生します。対応するプロジェクションデノーマライザーは、同じイベントを使用して、ユーザーの有効な役割を更新します。これは、そのユーザーに付与された個々のロールと、付与されたすべてのロールグループのロールの組み合わせです。
• これはトランザクションである必要はありません（結果整合性が得られるようになりました）。
• JonathanOliverのEventStore3.0と、Lokad.CQRSおよびNCQRSの要素を使用したイベントソーシングを使用します。

したがって、理論的には、1つの要求（ASP.NET MVCアプリ）が上記のシナリオを実行しているときに、別の要求が同じRoleGroupをユーザーに付与している可能性があります。上記のドメインイベントハンドラーがそのRoleGroupに関連するユーザーをスキャンした直後にそれが発生した場合、その要求は完了します。その時点で、（物理的ではありませんが）削除されたRoleGroupと、そのRoleGroupのIDを保持しているユーザーがいます。

これをどのように防ぎますか？現在、RoleGroup ARの特定のRoleGroup部分を付与されたユーザーのIDを作成することを検討しています。これにより、RoleGroupを削除してユーザーに付与すると、楽観的同時実行性の競合が発生します。しかし、どういうわけか、これは正しい解決策のようには感じられません。

結果整合性が非常に難しい、かなり典型的なユースケースがあると思います。これを支援する Python フレームワークを既に作成している人がいるかどうか疑問に思っています。

一連のエンティティに対してクエリを発行する GET リクエストがあります。それらはめったに更新されません。一度に 1 つのエンティティを更新するための POST 要求があります。エンティティを更新すると、GET 要求に表示されるかどうか/どのように表示されるかに影響します。

エンティティはめったに変更されないため、GET リクエストを長期間 (たとえば数日または数週間) memcache したいと考えています。そのため、エンティティを更新するための POST を取得するまれな機会に、memcache をクリアできます。

POST リクエストを処理し、エンティティを更新し、キャッシュをクリアし、その後すぐに GET リクエストを受信した場合に問題が発生します。最終的に一貫性のあるデータストア クエリは古いクエリ結果を表示する場合があり、その後数日間 memcached に保存されます。または数週間。

単純にデータストアを更新してキャッシュをクリアする代わりに、次のことを行う必要があります。

これは十分に一般的な問題のようです。この問題を軽減するのに役立つ Python フレームワークはありますか?

データストア クエリはすべてのキャッシュをバイパスするため、ndb は役に立ちません。

問題があれば、私は現在 django-nonrel を使用しており、django-tastypie は GET リクエストを処理します。