問題タブ [eventual-consistency]

私は、高可用性とスケーラブルでなければならないアプリケーションの設計の初期段階にあります。いくつかの理由から、このために結果整合性データモデルを使用したいと思います。これが多くのソリューションで人気のないアーキテクチャの選択である理由を私は知っており、理解していますが、私の場合は重要です。

分散/ドキュメントスタイルのデータベースを扱うときに注意すべき実際のアドバイス、ベストプラクティス、および落とし穴を探しています。特に、eコマース（ショッピングカートスタイル）アプリの周辺では、従来はリレーショナルデータベースと組み合わせるのが簡単でした。

これらのタイプのDBを使用するのは難しいことは理解していますが、GoogleとE-bayはそれらを使用しているので、それほど難しくはありません;-)アドバイスをいただければ幸いです。

erlang で bittorrent トラッカーを作成しています。サービスの性質上、絶対的な一貫性は必要ありません (つまり、ピアのリストや torrent のステータスが少し古くても、クライアントは完全に満足することができます)。

これまでの私の戦略は、disk_copies を有効にして RAM に mnesia テーブルを作成し、ログ サイズが特定のサイズを超えたときに mnesia が自動的にメモリをディスクにダンプするようにすることでした。

サーバーがクラッシュすると、一部の情報が失われます。大したことではありません。

別のアプローチとして、2 つのテーブル (1 つの RAM のみと 1 つのディスクのみ) をインスタンス化し、RAM からディスクへのプロセス コピーを約 1 分ごとに行うこともできます。これはより素朴ですが、メモリ内のサブセットのみをダンプできるため、ディスク全体のオーバーヘッドが削減され、ログの使用を完全に回避できる可能性があります (この最後のステートメントについては実際にはわかりません)。

これを行うには他にも多くの方法があると確信しています。君は？

-テオ

Amazon Web Services スタックの上に Web アプリを構築していますが、今のところ気に入っています。

また、テスト駆動開発をフルに活用しており、それも素晴らしいことが証明されています。

Amazon SimpleDB の「結果整合性」に関連して遭遇した問題について、誰かが私を助けてくれることを願っています。

発生する問題の最も良い例は、ユーザーを追加し、新しく追加されたユーザーをフェッチする呼び出しを行うことによって、ユーザーが正常に追加されたことを確認する単体テストです。

簡単に先に進み、そのためのテストを作成するだけで、すべて正常に動作する可能性がありますが、「結果整合性」と、ユーザーを取得するための呼び出しを行ったときに、ユーザーが実際にはそうではない可能性があることを認識しています。まだ追加されています。fetch user 関数が呼び出され、ユーザーがシステムに存在しない場合は、false または失敗が返されます。

私が知りたいのは、これを処理する最善の方法は何ですか? リクエスト間で 5 秒間スリープし、10 回試行する関数を作成するという提案を見てきました。指数バックオフを使用したソリューションも見てきました。最適なソリューションは何ですか?

分散システムで結果整合性を実現するために一般的に使用されるアルゴリズムはありますか?

分散システム、特にPaxosでACID トランザクション用に開発されたアルゴリズムがありますが、 BASEシナリオ用に開発された同様の理論体系はありますか?

編集:これは、開発が始まったばかりの学術研究の領域のようです。Mcdowella の回答は、この分野で少なくともいくつかの作業があったことを示しています。

Facility集約ルートのリストを含むかなり単純なドメイン モデルがあります。ドメインから発生したイベントを処理するために CQRS とイベント バスを使用している場合、セットの検証をどのように処理できますか? たとえば、次の要件があるとします。

1. Facilityには固有の名前が必要です。

クエリ側で最終的に整合性のあるデータベースを使用しているため、イベント プロセッサがイベントを処理する時点で、データベース内のデータが正確であるとは限りません。

たとえばFacilityCreatedEvent、クエリ データベースのイベント処理キューで、処理されてデータベースに書き込まれるのを待機しています。新規CreateFacilityCommandが処理されるドメインに送信されます。ドメイン サービスは読み取りデータベースにクエリを実行して、その名前で既に登録されている他の があるかどうかを確認しますが、まだ処理されておらず、ストアに書き込まれていないFacilityため、false を返します。CreateNewFacilityEvent新しいものCreateFacilityCommandは成功しFacilityCreatedEvent、イベント プロセッサがそれをデータベースに書き込もうとしてFacility、その名前の別のものが既に存在することを発見すると爆発する別のものをスローします。

CQRS パターンに従って実装する必要がある次のシナリオがあります。

1. ユーザーがログインする
2. ユーザーは保険の詳細を入力します
3. ユーザーは適用する決定を求めます
4. ユーザーは決定の結果を表示します

これはかなり簡単に思えますが、私の問題はステップ 3 と 4 の間にあります。ステップ 3 でApplyForDecision、引受サービスから決定を取得するコマンドを送信し、その決定の結果を含むイベントが読み取りストアの BUS に送信されます。後でそれを消費し、決定結果でビュー テーブルを更新します。

問題はUIにあります。CQRSでは読み取りモデルが「すぐに」更新されないため、決定が適用されていることをユーザーに知らせるにはどうすればよいですか?決定が進行中であり、「すぐに」更新されることをUIに表示するにはどうすればよいですか? ' 到着？

決定がまだ適用されていない可能性があるため、ユーザーがログアウトして再度ログインできるようにする必要もあります。UI に「保留中の決定画面」を表示するにはどうすればよいですか?

私はこれらから始めます - IMO素晴らしい - 記事：

• Base: An Acid Alternative - ダン・プリチェット著 (eBay)、2008
• 最終的に一貫した (- 再訪) - Werner Vogels (Amazon)、2008 年
• Brewer の予想と、一貫性があり、利用可能で、分割耐性のある Web サービス(非フリー) の実現可能性 - Seth Gilbert、Nancy Lnych (MIT)、2002 年

ACID が必要なスケーラビリティ/可用性を提供できなくなった (あるいは、ACID が極端な場合でも提供できる) 分散システムに関する記事にもっと興味があります。

記事は実用的な側面に焦点を当てる必要があります (私は数学が好きですが)。

私が特に興味深いと思うことの 1 つは、ACID 以外のアーキテクチャから派生できる経験則/設計パターン/... はどれですか?

私は、世界中のATMシステムがどのように設計されているかを悩ませています。銀行が世界中で一貫したシステムを設計することはかなり難しいに違いありません。これに結果整合性を使用しますか、それとも優れたACIDシステムを使用しますか？

私はある日スウェーデンにいて、銀行があり、ATMを使用し、飛行機で米国またはタイに行き、数時間後に海外でATMを使用することができます。システムに一貫性がある場合は、世界中のどこにでも非常に信頼性の高い接続が必要です。

単一クラスター内のノードに同じデータのコピーが含まれていないが、データがノード間で分散されている場合、Cassandra での結果整合性の意味は何ですか。これで、1 つのデータが 1 つの場所 (ノード) に記録されるようになりました。Cassandra がその単一の記録場所から最近の値を返さないのはなぜでしょうか? この状況で複数のコピーがどのように発生しますか?

シナリオは、連絡先のリストを含むグリッドです。ユーザーがグリッドから「メールを送信」をクリックすると、メールが送信されます。メッセージをキューにドロップして、一部の集計を更新します (一覧にも表示されます)。

問題は、電子メールを送信した後、集計がまだ更新されることが保証されていないことです。

JavaScript を使用してカウントを更新することはできますが、ページが更新され、集計がまだ完了していない場合はどうなるでしょうか。