7

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

これは、0MQ、RabbitMQ、または Microsoft MQ サービスの 1 つなどのサービスによってカバーされるものであるという印象を受けました。数日間読んで調査した結果、MQ サービスで話しているメッセージにデータベース操作が含まれているかどうかさえ確信が持てませんでした。しかし、期待できる限り多くの hello world をキューに入れることができると 100% 確信しています。

データベースに保護層を追加するためにメッセージ キューを使用できる場合は、Rabbit に傾倒します (クラッシュしても持続するように見えるため) が、ターゲットは Microsoft SQL サーバー データベースであるため、おそらくそのソリューションの 1 つです (そのようなSQL Service Broker または MSMQ として) がより適切です。

私がまだ確信が持てない本当の基本的な問題は、私が正しいデッキでプレイしているかどうかです (いわば)。

データベースがダウンしても機能し続ける高可用性 Web サービスが必要な場合、Web サービスとデータベースの「間に」Rabbit MQ インスタンスを配置することは理にかなっていますか? おそらく、チェーンの正しいリンクは、RabbitMQ にメッセージを Web サーバーに送信させることでしょうか?

または、これを達成するための他の解決策はありますか？現時点では、データベースが停止したり何かが発生した場合にウェブログをロールアップする方法を見つけることに関して、多くの失われたアイデアがあります.するつもりです。

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

4

1 に答える 1

3

サービスとそのデータベース操作の間にメッセージ キューイングを導入することは、確かにサービスの可用性を向上させる 1 つの方法です。ストア アンド フォワードシナリオでのローカルの一時キューへの書き込みは、リモート データベース サーバーへの書き込みよりも、常にローカル操作であるというだけで、より可用性が高くなります。

さらに、キューイングを使用することで、データベースがピーク時に処理しなければならないデータベース トラフィックの量と性質をより細かく制御できます。データベースの書き込みは、別の順序でキューに入れたり、ルーティングしたり、コミットしたりすることもできます。

ただし、これを行うには、データベースへの書き込みが実行されるときにオフラインで処理されることに注意する必要があります。これがほぼ瞬時に発生する状況下でも、現在のサービスの同期的な性質がもたらす利点、つまり、データベースの書き込み操作が成功したかどうかをサービスの利用者が常に知ることができるという利点が失われます。

この件については以前ここに書いたことがあります。質問を投稿したユーザーは、あなたと同様の懸念を持っていました。これを行うかどうかは、これが消費者に関心があるかどうかに基づいて決定する必要があります。

テクノロジー スタックに関しては、このオフライン モデルは、コードとうまく統合されないサービス ブローカーを除いて、ほぼすべてのモデルで実装可能であると考えています (こちらの回答を参照してください: https://stackoverflow .com/a/45690344/569662 )。

Windows を使用していて、移行する必要がほとんどない場合は、軽量で Windows の一部であるため、MSMQ (トランザクション キューを介した永続的なメッセージングをサポートする) を選択します。

于 2012-08-30T09:05:30.740 に答える