architecture - タスクキューシステムを確認する

Question

私はレビューシステムを実装しています。このシステムでは、ユーザーがレビューが必要なデータアイテムをアップロードし、レビュー担当者がそれをレビューしてコメントを提供します。各データ項目は、3人のレビューアがレビューする必要があります。

アイテムは多かれ少なかれ順番に処理する必要があります。理想的には、アイテムAがシステムに追加され、レビュー担当者1、2、および3がそれをレビューして、ユーザーに返されます。次に、アイテムBがシステムに追加され、レビュー担当者2、5、1がレビューします。もちろん、レビュー担当者は同時に作業でき、3人以上のレビュー担当者がいるため、システムは同時にレビューされる複数のアイテムをサポートする必要があります（もちろん、異なるレビュー担当者によって）。

データアイテムリポジトリを実装する方法がわかりません。要件は次のとおりです。

• アイテムは複数のライターによって追加されます。
• 各アイテムは3人の異なるリーダーによって読み取られます。
• 読者がアイテムを取るとき、それは読者が最初に見なかった最初のアイテムを取るべきです。

SQLデータベースを使用してこれらすべてを実装できますが、拡張性はあまり高くありません。

このようなものをサポートする既製のキューイングシステムはありますか（基本的に、基準に適合しない最初のアイテムをポップします）？または、これを既存のキューイングシステムに追加する方法はありますか？

Answer 1

SQL データベースが多くのエンタープライズ規模のシステムの根底にあることを考えると、「あまりうまく拡張できない」という主張には根拠がないと思います。大規模なエンタープライズ システムが専用のキューイング システムの恩恵を受けるのは事実ですが、これらのシステムは、たとえば、小売銀行が 1 日に処理するすべてのトランザクションを処理しています。レビューするアイテムが非常に多く、同時レビュー担当者が非常に多いため、この要件が標準の SQL データベースに負担をかけることになるのではないかと私は懐疑的です。もちろん、私はあなたの要件の規模について推測しているので、それらが何であるかを聞くのは興味深いかもしれません.

ただし、これを一連のキューとして実装することの概念的な利点は理解できます。その場合の原則的な要件は、「このキューからまだレビューしていない次のアイテムを提供する」機能です。

JMS セレクターを使用すると、ヘッダー フィールドの内容に基づいてレコードを選択できるため、Reviewer1 および Reviewer2 ヘッダー フィールドをメッセージに追加すると、次に利用可能なアイテムを効率的に選択できるようになります。したがって、JMS 準拠のキューイング システムで十分だと思います。