RabbitMQ、ZeroMQ、Service Brokerなどの高可用性データベースWebサービスを作成するのに適したソリューションですか？

Question

私はCRUD webserviceを持っており、データベースがダウンしたときにデータが失われないようにする方法を見つけようとしています。誰もが、データベースがダウンすると、「読み込み」を取得することはできないが、データの損失がないことを確認する操作の特定のサブセットについては、誰もが認識しています。

私はこれが0MQ、RabbitMQ、またはMicrosoft MQサービスの1つのようなサービスによってカバーされているという印象を与えられました。読書や調査の数日後には、私たちがMQサービスで話しているメッセージにデータベース操作が含まれていることさえ確信していません。しかし、100％確信していますが、私がこれまでに望むことのできるくらい多くのこんにちは世界を並べることができます。

メッセージキューを使用してデータベースに保護層を追加することができれば、私はラビットに頼るだろう（クラッシュによって永続するように見えるため）。ターゲットはMicrosoft SQLサーバーのデータベースなのでそのソリューション（SQL Service BrokerやMSMQなど）がより適切です。

私がまだ確信していない本当の根本的な質問は、私がカードの正しいデッキでプレイしているかどうかということです。

データベースがダウンした場合でも機能し続ける高可用性のWebサービスが必要な場合、Webサービスとデータベースの間にRabbit MQインスタンスを配置するのは意味がありますか？ RabbitMQにWebサーバーにメッセージを送信させるのがチェーンの正しいリンクでしょうか？

これを達成するための解決策がいくつかありますか？現時点では、データベース停止や何かのイベントでウェブログをロールアップする方法を見つけ出すというアイデアは数多くあります...しかし、私たちはまだ十分早い段階にあります（少なくとも私には）私はするつもりです。

メッセージキューは適切なソリューションですか？

Answer 1

サービスとデータベースの間でメッセージキューイングを導入することは、確かにサービスの可用性を向上させる1つの方法です。ローカルキューへの書き込みは、常に安価で、データベースに書き込むよりも利用可能です。

さらに、キューイングを使用すると、データベースがピーク時に処理する必要があるデータベーストラフィックの量を制御できます。

ただし、これを行うには、データベースの書き込みが実行されるときに要求がキューに入れられず、オフラインで配信され、処理されることに注意する必要があります。

これがほぼ即座に発生する状況であっても、現在のサービスの同期性によって可能になる利点が失われています。その利点は、サービスコンシューマー（またはWebクライアント）が、操作が成功したかどうかを常に知ることができることです。

私はhereの前にこの件について書いています。質問を投稿したユーザーも同様の懸念を抱いていました。あなたがそうするかどうかは、あなたがしなければならない決定です。

あなたが考えているテクノロジスタックについては、0MQは実際にはメッセージキューシステムではなく、ステロイドソケットのようなものです。

あなたが言及している他のMQプラットフォームのうち、すべてがシステムクラッシュによる耐久性をサポートしています。 MSMQはrabbitMQ（AMQPプロトコルを実装しており、メッセージングパターンをサポートしています）よりはるかに軽量です。

サービスブローカーはデータベーステクノロジであり、SqlDependency、またはStreamInsightプラットフォームで有効になっている通知と呼ばれるものを除き、コードとうまく統合されません。

MSMQ（トランザクションキューを介した耐久性のあるメッセージングをサポートしています）は軽量でWindowsの一部であり、コアの.netライブラリをサポートしています。