メッセージキュー。データベースと専用MQ

メッセージのキューイングに関するアドバイスを求めています。「ジョブ」をメッセージキューに投稿する必要があります。

最初の提案は、SQL Serverインスタンスを使用して、そこからのメッセージを処理することだけでした。インターネットで読んだことはすべて、Message Queueにデータベースを使用することはスケーラブルなソリューションではないことを示唆しています。このため、RabbitMQまたは他のサードパーティMQを使用するというアイデアが提案されました。

もう1つ考慮すべきことは、「ジョブ処理」の要件が30秒以上にならないことです。したがって、ジョブを実行するプロセスは30秒ごとにデータベースをポーリングします。私には、これはそれほど悪くはないようで、おそらくデータベースに大きな負荷をかけなくても大丈夫でしょう。

クライアントに必要な追加サポートを追加しないように、これに使用できるデータベースが既にクライアントに配置されていますが、サードパーティMQを追加した場合、ネットワーク構成などの追加サポートがあります。多くのユーザーがいることを考えると、かなりの数です。

私が検討していたもう1つのオプションは、ユーザーがどちらかを選択できるようにすることでした。小さいユーザーの場合、SQL Serverソリューションは問題ありませんが、大きいユーザーの場合、サードパーティのMQソリューションを構成できます。

私はソリューションで販売されていません。誰かが私が考慮すべきことやアドバイスを持っているかどうか疑問に思っています。

インターネットで読んだことはすべて、Message Queueにデータベースを使用することはスケーラブルなソリューションではないことを示唆しています。

「スケールしないためXを使用しない」（リンクには不快な言語が含まれる可能性があります）群衆によって頻繁に無視される現実は、スケールが必ずしも重要ではないということです。惑星の表面にあるすべてのアプリケーションを総合的に見てみると、規模が重要になることはめったにないと言えます。

あなたのコメントは、毎日20,000メッセージのレートを引用しています。つまり、1秒あたり平均0.23メッセージ（4.3秒ごとに1メッセージ）をサポートする必要があると考えています。プロジェクトが予想よりも2桁成功した場合、要件は1秒あたり23メッセージの処理にジャンプします。これは、4歳の携帯電話やRaspberryに与えるのが非常に快適なタスクですパイ これに加えて、さらに数桁の規模を追加しても、これはまだ大規模なアプリケーションではありません。

私は（幸いなことに、傍観者から）プロジェクトがひどく終わるのを見てきました。なぜなら、彼らはあまりにも早くスケールに夢中になりすぎているか、それともまったく時間がないために時間を費やし、最終的にスケールに押しつぶされたからです。他のすべてのように、幸せな媒体があります。アプリケーションの大規模な拡張が現実的な可能性であると考える場合、現在展開するのに安価な拡張不可能な部分の周りに十分な抽象化を構築するために少量の追加作業を行うビジネスケースを作ることは難しくありません。これを行うと、後で規模の必要性が生じた場合に、システム全体を再考することなく、これらの部品の大規模な交換を行う方法（および場合によっては収益）が得られます。

アプリケーションのメッセージボリュームによって、データベースやメッセージキューイングシステムが控えめなハードウェア上でも汗をかくことはありませんが、おそらく、メッセージトランザクションの処理方法には他の要件があり、どちらかがより良い選択になります。これらの要件は、評価すべきものです。

メッセージキューは、多数ある場合に実際に機能し、それらの間でメッセージをルーティングしたり、複数のコンシューマにファンアウトしたりします。

「オフライン」で処理したいものの「ジョブキュー」が1つだけの場合は、SQLテーブルで十分です。

進行中のジョブをマークし、古いジョブをクリーンアップし、システムが停止したときに警告する何らかの方法があることを忘れないでください。しかし、単一のキューでは、これらのことを手動で管理する方が、個別のキューソリューションを維持するよりも作業が少なくなります。

他で言及したように、ここではおそらく規模は重要ではありません。2つの異なるストレージメカニズムの使用に伴う問題は、トランザクションの完全性です。

専用のメッセージキューを使用する場合は、障害が発生した場合に次のいずれかを選択する必要があります。

1. データはmbにあるがdbにはないことを許可する
2. データはdbにあるが、mbにはないことを許可する
3. dbとmqの間に2フェーズコミットまたは分散トランザクションをセットアップする

通常のトランザクションを使用してデータを1か所に保存するだけで、これらの問題はすべてなくなります。このため、dbをタスクキューとして使用することは完全に優れたソリューションです。

実際には、メッセージキューを使用する主な理由は次のとおりです。

• 車輪を再発明する必要はありませんでした。データベースを使用して最も単純なメッセージキューを設計する場合でも、少なくとも数時間の思考、数時間のコーディングなどが必要です。メッセージキューの実装と比較して、構成の構成や自動化に必要な時間はわずかです
• メッセージキューには、プロデューサーとコンシューマー向けのわかりやすいインターフェイスがあります。これはおそらく、アプリケーションを作成する上で最も重要なことです。インターフェイスがない場合、メッセージキューは基本的にデータのコレクションにすぎません
• メッセージキューは、将来必要になる可能性のある機能をさらに提供します

ユーザーが選択できるようにすることに関して、それは実際にはユーザーが気にするべきではない実装の詳細です。ユーザーは同じインターフェイスを取得する必要があり、データベースまたはメッセージキューを使用する場合、ユーザーに違いはありません。単一の設計が設定されると、ユーザーが選択する可能性があるのは、ニーズに対応するために展開する必要があるノードの数です。

パフォーマンステストによると、1秒あたり20,000の操作を処理できるMssqlメッセージキューソリューションを作成しました。ほとんどの場合、10 /秒が必要です。実際に優先順位を組み込むことができるという事実は、専用メッセージキューにはない機能だと思います。そして、これは私の場合の主要な要件でした。