File d'attente à l'aide de la table

Question

Je dois implémenter une file d'attente à l'aide de la table. L'exigence de l'entreprise est d'avoir une seule file d'attente qui sera accessible par 5-10 boîtes pour obtenir le prochain travail/emplois. Il n'y aura pas plus de 5000 emplois par jour. En outre, un lot de travaux doit être "retiré" en même temps.

Je me demandais quels sont les problèmes et les problèmes que je pourrais rencontrer car je ne l'ai jamais fait auparavant. Si quelqu'un a déjà fait face à cela/fait cela avant, pouvez-vous s'il vous plaît me diriger vers un design/exemple de mise en œuvre ou des problèmes qui doivent être pris en charge.

Merci

Answer 1

Il y a beaucoup de faire la queue à usage général ou les services de messagerie. Même si vous voulez implémenter votre propre système, vous pouvez essayer d'en voir quelques autres. La première chose qui vient à l'esprit est JMS (Java Message Service) avec des implémentations comme Apache ActiveMQ, OpenJMS ou JBoss Messaging. Ensuite, vous avez aussi beaucoup d'offres non-opensource.

La deuxième chose qui vient à l'esprit est Amazon Simple Queue Service. Il y a quelques produits qui implémentent le même type d'interface, comme django-queue-service.

Bonne chance!

---

Answer 2

Problématiques:

• Concurrency
• sécurité
• Vitesse
• encodage
• Unicité

Et bien sûr, celui-ci:

• spécification du domaine Incertain problème

Bonne programmation!

Answer 3

Cela ne semble pas trop dur; Indiquez simplement un horodatage que vous pouvez trier chaque fois que des travaux sont entrés. Selon la base de données, ce champ peut être rempli automatiquement avec l'horodatage en cours.

Lors de l'extraction de travaux, il est aussi simple que de placer les instructions SELECT et DELETE dans une transaction. Si vous vous sentez inconfortable, quelque chose comme ça pourrait le faire:

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> 

En utilisant cette configuration, vous pouvez éviter les transactions, si elles vous font peur.

Votre définition d'un lot n'est pas très claire; Si vous voulez simplement dire que je devrais être capable de traiter 10 éléments à la fois, changez simplement la clause LIMIT 1 de la première requête en LIMIT 10.

Si vous voulez dire que les tâches peuvent être groupées, vous avez probablement besoin d'une file d'attente et placez des sous-éléments dans une autre table (qui n'est pas une file d'attente, juste une table régulière avec une clé étrangère pointant vers l'élément de travail).

Answer 4

Merci Vegard.Mais l'approche que vous avez suggérée entraînera une perte de demandes de travail dans le cas où le système qui a pris le travail échoue/se bloque.

Je pensais à une table de file d'attente avec des colonnes suivantes

• RequestID/MessageID (clé primaire)
• LockedBy (qui travaille à la demande)
• LockedTime (lorsque la demande est bloquée pour le traitement)
• RequestedTime (lorsque la demande est ajouté à la file d'attente)
• CompletionTime (quand est terminé demande)
• Etat (attente/Transformé)
• RequestMessage (sérialisé objet java dans mon cas)
• de Requestor (qui en file d'attente la demande)

Je peux écrire une procédure stockée [GetNextItemsInQueue] qui retourne une liste de laisse dire 10 demandes, définit le temps verrouillé et verrouillé. Si Locked Time augmente une limite spécifiée, l'enregistrement peut être remis à l'état En attente.

Des problèmes avec celui-ci?