メッセージキュー。データベースと専用MQ
私はメッセージのキューイングについてアドバイスを求めています。 「ジョブ」をメッセージキューに投稿する必要があります。
最初の提案は、SQL Serverインスタンスを使用して、そこからのメッセージを処理することでした。私がインターネットで読んだすべては、メッセージキューにデータベースを使用することはスケーラブルなソリューションではないことを示唆しています。このため、RabbitMQまたはその他のサードパーティMQを使用するという考えが提案されました。
もう1つ考慮すべきことは、「ジョブ処理」の要件が30秒以上になることはないため、ジョブを実行するプロセスは30秒ごとにデータベースをポーリングすることです。私には、これはそれほど悪くはないように思われ、おそらくデータベースに大きな負荷を追加しなくても大丈夫でしょう。
私たちはすでにクライアントにデータベースを用意しており、これに使用できるため、クライアントに必要な追加のサポートはあまり追加されませんが、サードパーティのMQを追加すると、ネットワーク構成などのサポートが追加されます。多くのユーザーがいることを考えると、かなりです。
私が検討していたもう1つのオプションは、ユーザーがどちらかを選択できるようにすることでした。小規模なユーザーの場合はSql Serverソリューションで問題ありませんが、大規模なユーザーの場合は、サードパーティのMQソリューションを構成できます。
私はどんな解決策でも売っていません、誰かが私が考慮またはアドバイスすべき何かがあるかどうか疑問に思っています。
私がインターネットで読んだすべては、Message Queueにデータベースを使用することはスケーラブルなソリューションではないことを示唆しています。
スケールしないため、「 使用しない[〜＃〜] x [〜＃〜]」によって無視されることが多い現実 "（リンクには、不快と思われる可能性のある言語が含まれています）群衆は、規模が必ずしも重要ではないということです。惑星の表面にあるすべてのアプリケーションをまとめて見ると、スケールはまれに重要だと私は言っています。
あなたのコメントは、毎日20,000メッセージの割合を引用しています。これは、毎秒0.23メッセージ（4.3秒ごとに1つ）の平均レートをサポートする必要があると考えていることを意味します。プロジェクトが予想よりも2桁以上成功していることが判明した場合、要件は毎秒23メッセージの処理にジャンプします。これは、4歳の携帯電話またはRaspberryに私が非常に快適に与えるタスクです。パイこれにさらに数桁を追加しても、これはまだ大規模なアプリケーションではありません。
私は（幸運にも、傍観者から）プロジェクトがひどく終了するのを見てきました。プロジェクトがあまりにも早く時間をかけすぎて、起こりそうもない規模に夢中になっているか、まったく時間をかけずに、結局は規模に押しつぶされたためです。他のすべてのように、幸せな媒体があります。アプリケーションの大規模なスケーリングが現実的な可能性であると考える場合、展開に費用がかからない非スケーラブルなパーツに関する十分な抽象化を組み込むために少量の追加作業を行うビジネスケースを作成することは難しくありませんnow。これを行うことは、後で、スケールの必要性が生じた場合に、それらの部品の卸売り交換をせずに卸売り交換する方法（および場合によっては収益）があることを意味しますシステム全体を再考する必要があります。
アプリケーションのメッセージボリュームによってデータベースやメッセージキューシステムが適度なハードウェアで汗を流すことはありませんが、メッセージトランザクションの処理方法について、おそらくどちらかがより適切な選択となる他の要件があるはずです。これらの要件は、評価する必要があるものです。
メッセージキューは、メッセージキューが多数あり、それらの間でメッセージをルーティングしたり、複数のコンシューマーにファンアウトしたりすると、実際に独自のものになります。
「オフライン」で処理したいものの「ジョブキュー」が1つしかない場合は、SQLテーブルで問題ありません。
ジョブに進行中のマークを付け、古いジョブを一掃し、システムが停止したときに警告する方法があることを確認することを忘れないでください。ただし、単一のキューの場合、これらを手動で管理する方が、個別のキューソリューションを維持するよりも作業が少なくなります。
他の人が言及したように、規模はおそらくここでは重要ではありません。 2つの異なるストレージメカニズムの使用に関する問題は、トランザクションの整合性です。
専用のメッセージキューを使用する場合、障害が発生した場合に次のいずれかを選択する必要があります。
- データはmbにあるが、dbにはないことを許可する
- データはdbにはあるがmbにはないことを許可する
- 複雑になる可能性のあるDBとMQの間の2フェーズコミットまたは分散トランザクションのセットアップ
通常のトランザクションを使用して1か所にのみデータを保存すれば、これらの問題はすべてなくなります。このため、dbをタスクキューとして使用することは、完全に適切なソリューションです。
実用性のために、メッセージキューを使用する主な理由は次のとおりです。
- 車輪を再発明する必要はありませんでした。データベースを使用して最も単純なメッセージキューを設計する場合でも、少なくとも数時間の思考、数時間のコーディングなどが必要です。メッセージキューの実装と比較して、構成および/または構成の自動化に必要な時間は取るに足らない
- メッセージキューには、プロデューサーとコンシューマー向けのわかりやすい明確なインターフェイスがあります。これはおそらくアプリケーションを書く上で最も重要なことです。インターフェイスがない場合、メッセージキューは基本的に単なるデータのコレクションです
- メッセージキューにより、将来必要になる可能性のある機能が増えます
ユーザーが選択できるようにすることに関しては、これは実際にはユーザーが気にする必要のない実装の詳細です。ユーザーは同じインターフェイスを取得する必要があり、データベースまたはメッセージキューが使用されている場合でもユーザーに違いはありません。単一の設計が設定されたら、ユーザーの可能性は、ニーズに対応するために展開する必要があるノードの数です。
パフォーマンステストによると、毎秒2万回の操作を処理できるMssqlメッセージキューソリューションを作成しました。ほとんどの場合、10 /秒が必要です。実際に優先度を組み込むことができるのは、専用メッセージキューにはない機能だと思います。そして、これは私の場合の主要な要件でした。