RabbitMQのような大量のメッセージをSQLデータベースに書き込むためのメッセージキュー？

Question

シナリオでは、クリックやマウスの動きを追跡するなど、大量のデータをWebアプリケーションからSQLデータベースに書き込む必要があります。データの解析は、毎日または毎週のような何らかの反復ベースで行われるため、すぐにデータを書き込む必要はありません。

私は心に来るソリューションのいくつかのフィードバックをしたい：

クリックやマウスのデータがメッセージ・キューに公開されています。これにより、メモリにキュー項目が格納されるため、SQLより高速で高速になります。その後、他のサーバーでは、次のキュー項目を取得してSQLにデータを書き込む際に、ジョブがプラグインされます。

誰もこのような実装を知っていますか？どのような落とし穴が私に見えないのですか？この解決策が良いものではない場合、他の選択肢がありますか？

よろしく

Answer 1

を私はまさにこれをやって検討していた非常によく似た問題を解決するために。最終的には、データにすばやくアクセスする必要があったため、私たちはそれを避けることにしました。しかし、私はまだアイデアが好きです。

私は最近、フードの下では、これが正確にMicrosofft Dynamics CRMがメッセージの受け渡しを使用してデータベースを更新する方法であることを知りました。

私はあなたが慎重に注意を払う必要があると思います。

1. RabbitMQインスタンスが消えても、クライアントに影響を与えないようにしてください。ウサギの死が十分に悪いです、あなたのクライアントはウサギがダウンしているためにエラーがひどいです。
2. 本当に非常にボリュームが大きい（そして、とにかく信頼性のための良い練習である）場合、クラスタリングは価値のあるものです。
3. 明らかに、デッドレターのキューに注意を払うことは必須です。しかし何らかの理由で失敗したメッセージを再生する能力は素晴らしいです。理論的には、少なくともあなたのデータはいつもあなたのデータベースに到達するはずです。たとえそれが一定の期間にわたって落ちたとしても。
4. 渡されるメッセージの数に追いつくことができることを確認してください。もちろん、これは特定のキューにコンシューマーを追加することで解決できます。それは...
5. メッセージのIdempotency。あなたのメッセージがDB書き込みに直接関連するとすれば、それらは冪等でなければなりません。

Answer 2

RabbitMQはリアルタイムメッセージ交換のためのものであり、一時的なバッファリングデータのためのものではありません。すべてのデータがキューに到着するとすぐに使用できる場合は、このソリューションが有効です。さもなければ、RabbitMQはメモリ内で成長し、最終的には死ぬでしょう。次に、いくつかのデータを投げ捨てるように設定する必要があります（これにはルールを選択するオプションがたくさんあります）。

Redisキャッシュにデータを格納する可能性はありますが、RabbitMQにイベントを公開するのと同じくらい速くできます。その後、リモートサーバーからRedisの新しい変更を聴いたり、使用するデータベースストレージをいっぱいにしたり、データストレージとして使用することもできます。