4

テーブルを使用してキューを実装する必要があります。ビジネス要件は、次のジョブを取得するために 5 ～ 10 個のボックスがアクセスする単一のキューを持つことです。1 日あたり 5000 以上のジョブはありません。また、ジョブのバッチは一度に「デキュー」する必要があります。

以前に行ったことがないので、私が遭遇する可能性のある問題領域と問題は何なのかと思っています。誰かがこれに直面した/これを以前に行ったことがある場合は、設計/サンプルの実装、または対処する必要がある問題を教えてください。

ありがとう

4

4 に答える 4

3

汎用キューイングまたはメッセージング サービスが多数あります。独自のシステムを実装したい場合でも、他のいくつかを見てみることができます。最初に思い浮かぶのは、 Apache ActiveMQ、OpenJMS、またはJBoss Messagingなどの実装を備えたJMS ( Java Message Service )です。それから、オープンソース以外の製品もたくさんあります。

2 番目に思い浮かぶのは、Amazon Simple Queue Serviceです。django-queue-service のように、同じ種類のインターフェースを実装する製品がいくつかあります。

幸運を ！

于 2008-11-11T10:33:36.933 に答える
2

問題のある領域:

  • 同時実行
  • 安全
  • スピード
  • エンコーディング
  • 独自性

そしてもちろんこれ：

  • 問題領域の特定が不明確

ハッピーコーディング！

于 2008-11-11T10:37:29.653 に答える
2

これは難しいことではありません。ジョブが入力されるたびにソートできるタイムスタンプを含めるだけです。データベースによっては、このフィールドに現在のタイムスタンプを自動入力できます。

ジョブをフェッチするときは、SELECT および DELETE ステートメントをトランザクションに入れるのと同じくらい簡単です。不快に感じる場合は、次のようにするとよいでしょう。

UPDATE tblQueue SET mark = <unique application id> WHERE mark IS NULL ORDER BY timestamp ASC LIMIT 1
SELECT * FROM tblQueue WHERE mark = <unique app id>
DELETE FROM tblQueue WHERE mark = <unique app id>

この設定を使用することで、トランザクションが怖がっている場合でもトランザクションを回避できます。

バッチの定義はやや不明確です。一度に 10 個のアイテムを処理できる必要があるというだけの場合は、最初のクエリの LIMIT 1 句を LIMIT 10 に変更してください。

ジョブをグループ化できるという意味であれば、おそらくジョブ キューが必要であり、サブアイテムを別のテーブル (キューではなく、ジョブ アイテムを指す外部キーを持つ通常のテーブル) に配置する必要があります。

于 2008-11-11T12:17:11.373 に答える
0

ありがとうベガード。

ただし、提案したアプローチでは、ジョブを実行したシステムが失敗/クラッシュした場合に、ジョブ リクエストが失われます。

次の列を持つキューテーブルを考えていました

  • RequestID/MessageID (主キー)
  • LockedBy (誰がリクエストに取り組んでいるか)
  • LockedTime (リクエストが処理のためにロックされている場合)
  • RequestedTime (リクエストがキューに追加されたとき)
  • CompletionTime (いつリクエストが完了したか)
  • ステータス (保留/処理済み)
  • RequestMessage (私の場合はシリアル化された Java オブジェクト)
  • リクエスタ (リクエストをキューに入れた人)

[GetNextItemsInQueue]たとえば 10 個のリクエストのリストを返し、Locked By と Locked Time を設定するストアド プロシージャを作成できます。ロックされた時間が指定された制限を増やすと、レコードを保留状態に戻すことができます。

これに問題はありますか？

于 2008-11-11T13:57:44.353 に答える