質問: 1` を照会して、クライアント1から送信されたすべてのイベントを取得することができます(たとえそれらのイベントがまだDBに保存されていない場合でも) これに対処する方法について「教室」の例はありますか? 可能な解決策 ------ ### サーバーにイベントをエンキューする サーバー上のイベントをキューに入れることができます(キューの最大同時実行数は400であるため、接続プールは不足しません)。 これは*悪い考え*です。 * 利用可能なサーバーメモリを使い果たします。積み上げられたエンキューイベントは大量のRAMを消費します。 * 我々のサーバーは **24時間に1回**再起動します。これは、Herokuによる厳しい制限です。イベントがエンキューされている間にサーバーを再起動すると、エンキューされたイベントが失われます。 * サーバーの状態が変化するため、スケーラビリティが低下します。マルチサーバー設定でクライアントがすべてのエンキュー+保存済みイベントを読みたい場合、エンキューされたイベントがどのサーバー上にあるかわかりません。 ### 別のメッセージキューを使用する メッセージキュー( RabbitMQ のような)を使用することができると思います。そこにメッセージを送り続けます。もう一方の端には、DBにイベントを保存することだけを扱う別のサーバーがあります。 メッセージキューが(まだ保存されていない)キューに入れられたイベントの照会を許可するかどうかわからないので、別のクライアントが別のクライアントのメッセージを読みたい場合は、保存メッセージをDBから、保留メッセージをキューから取得できます。そしてそれらを連結して、読み取り要求クライアントに送り返します。 ### 複数のデータベースを使用し、それぞれがメッセージの一部を中央のDBコーディネーターサーバーに保存して管理します 私達がしたもう一つの解決策は中央の "DBコーディネーター/ロードバランサー"で複数のデータベースを使うことです。イベントを受け取り次第 このコーディネーターは、メッセージを書き込むデータベースを1つ選択します。これにより、複数のHerokuデータベースを使用できるようになり、接続数の上限は500 xデータベースになります。 読み込みの問い合わせがあると、このコーディネータは各データベースに対して `SELECT` クエリを発行し、すべての結果をマージして読み込みを要求したクライアントに送り返します。 これは*悪い考え*です。 * この考えは...ああ、オーバーエンジニアリングのようですね。同様に管理するのは悪夢かもしれません(バックアップなど)。構築と保守は複雑で、どうしても必要な場合を除き、 KISS 違反のように思えます。 * 一貫性を犠牲にします。複数のDBにまたがってトランザクションを実行するのは、この考えに従うといけません。
回答: 私はあなたが拒絶したアプローチをもっと注意深く探る必要があると思います * サーバーにイベントをエンキューする 私の提案は、 LMAXアーキテクチャについて公開されているさまざまな記事を読み始めることです。彼らは彼らのユースケースのために大量のバッチ処理をすることに成功した、そしてそれはあなたのトレードオフを彼らのもののように見えるようにすることは可能かもしれない。 また、読み取りが邪魔にならないかどうかを確認したい場合があります。理想的には、書き込みとは無関係に読み取りを拡大できるようにしたいということです。それはCQRS(コマンドクエリ責任分離)を調べることを意味するかもしれません。 > > イベントがエンキューされている間にサーバーを再起動すると、エンキューされたイベントが失われます。 > > > 分散システムでは、メッセージが失われることにかなり自信があると思います。シーケンスの障壁について慎重に検討することで、その影響の一部を軽減できる可能性があります(たとえば、イベントがシステムの外部で共有される前に、永続ストレージへの書き込みが行われるようにする)。 * 複数のデータベースを使用し、それぞれがメッセージの一部を中央のDBコーディネーターサーバーに保存して管理します。 たぶん - 私はあなたのビジネスの境界を調べて、データを断片化するための自然な場所があるかどうかを確かめることになるでしょう。 > > データを失うことが許容できるトレードオフである場合がありますか? > > > まあ、私はあるかもしれないと思いますが、それは私が行っていた場所ではありません。重要なのは、メッセージの損失に直面しても、設計には進歩に必要な堅牢性が組み込まれている必要があるということです。 これがよく見えるのは、通知を伴うプルベースのモデルです。プロバイダはメッセージを順序付けされた永続ストアに書き込みます。消費者は店からメッセージを引き出し、それ自身の最高水準点を追跡します。プッシュ通知は待ち時間を短縮する装置として使用されますが、通知が紛失しても、コンシューマが定期的にスケジュールを進めているため、メッセージは(最終的には)まだ取得されます。 ) See Reliable Messaging Without Distributed Transactions, by Udi Dahan (already referenced by Andy) and Polyglot Data by Greg Young.