kue
v0.11.6
Veuillez voir par exemple le taureau comme une alternative. Merci!
Kue est une file d'attente de travail prioritaire soutenue par redis, construite pour node.js.
Protip C'est la dernière documentation KUE, assurez-vous de lire également le ChangeList.
Dernière version:
$ npm install kue
Master Branch:
$ npm install http://github.com/Automattic/kue/tarball/master
Créez d'abord une Queue d'attente avec kue.createQueue() :
var kue = require ( 'kue' )
, queue = kue . createQueue ( ) ; Appeler queue.create() avec le type de travail ("e-mail"), et les données de travail arbitraires renvoient un Job , qui peut ensuite être save() ED, l'ajoutant à Redis, avec un niveau de priorité par défaut "normal". La méthode save() accepte éventuellement un rappel, répondant avec une error en cas de problème. La clé title est spéciale et s'affichera dans les listes d'emplois dans l'interface utilisateur, ce qui facilite la recherche d'un travail spécifique.
var job = queue . create ( 'email' , {
title : 'welcome email for tj'
, to : '[email protected]'
, template : 'welcome-email'
} ) . save ( function ( err ) {
if ( ! err ) console . log ( job . id ) ;
} ) ; Pour spécifier la priorité d'un travail, invoquez simplement la méthode priority() avec un numéro, ou nom de priorité, qui est mappé à un nombre.
queue . create ( 'email' , {
title : 'welcome email for tj'
, to : '[email protected]'
, template : 'welcome-email'
} ) . priority ( 'high' ) . save ( ) ;La carte de priorité par défaut est la suivante:
{
low : 10
, normal : 0
, medium : - 5
, high : - 10
, critical : - 15
} ; Par défaut, les travaux n'ont qu'une seule tentative, c'est-à-dire à ce moment-là qu'ils échouent, ils sont marqués en échec et restent ainsi jusqu'à l'intervention. Cependant, Kue vous permet de spécifier cela, ce qui est important pour des emplois tels que le transfert d'un e-mail, qui en échec, peut généralement réessayer sans problème. Pour ce faire, invoquez la méthode .attempts() avec un nombre.
queue . create ( 'email' , {
title : 'welcome email for tj'
, to : '[email protected]'
, template : 'welcome-email'
} ) . priority ( 'high' ) . attempts ( 5 ) . save ( ) ; Les tentatives de réessayer de l'emploi sont effectuées dès qu'ils échouent, sans retard, même si votre travail avait un délai défini via Job#delay . Si vous souhaitez retarder les réattades de l'emploi lors des échecs (connus sous le nom de Backoff), vous pouvez utiliser la méthode Job#backoff de différentes manières:
// Honor job's original delay (if set) at each attempt, defaults to fixed backoff
job . attempts ( 3 ) . backoff ( true )
// Override delay value, fixed backoff
job . attempts ( 3 ) . backoff ( { delay : 60 * 1000 , type : 'fixed' } )
// Enable exponential backoff using original delay (if set)
job . attempts ( 3 ) . backoff ( { type : 'exponential' } )
// Use a function to get a customized next attempt delay value
job . attempts ( 3 ) . backoff ( function ( attempts , delay ) {
//attempts will correspond to the nth attempt failure so it will start with 0
//delay will be the amount of the last delay, not the initial delay unless attempts === 0
return my_customized_calculated_delay ;
} )Dans le dernier scénario, la fonction fournie sera exécutée (via EVAL) sur chaque récession pour obtenir la prochaine valeur de retard, ce qui signifie que vous ne pouvez pas référencer les variables externes / contextuelles en lui.
Les producteurs d'emploi peuvent définir une valeur d'expiration pour le moment où leur travail peut vivre à l'état actif, de sorte que si les travailleurs n'ont pas répondu en temps opportun, Kue l'échouera avec TTL exceeded le message d'erreur empêchant que ce travail ne soit coincé à l'état actif et gâchait TTL concurrence.
queue . create ( 'email' , { title : 'email job with TTL' } ) . ttl ( milliseconds ) . save ( ) ; Les journaux spécifiques au travail vous permettent d'exposer des informations à l'interface utilisateur à tout moment de la vie de l'emploi. Pour ce faire, invoquez simplement job.log() , qui accepte une chaîne de messages ainsi que des arguments variables pour le support de type Sprintf:
job . log ( '$%d sent to %s' , amount , user . name ) ;ou toute autre chose (utilise util.inspect () en interne):
job . log ( { key : 'some key' , value : 10 } ) ;
job . log ( [ 1 , 2 , 3 , 5 , 8 ] ) ;
job . log ( 10.1 ) ; Les progrès de l'emploi sont extrêmement utiles pour des emplois de longue date tels que la conversion vidéo. Pour mettre à jour les progrès de l'emploi, invoquez simplement job.progress(completed, total [, data]) :
job . progress ( frames , totalFrames ) ;Les données peuvent être utilisées pour transmettre des informations supplémentaires sur le travail. Par exemple, un message ou un objet avec des données contextuelles supplémentaires à l'état actuel.
Des événements spécifiques à l'emploi sont licenciés sur les cas Job via Redis Pubsub. Les événements suivants sont actuellement pris en charge:
enqueue le travail est maintenant en file d'attentestart le travail est maintenant en cours d'exécutionpromotion Le travail est promu d'un état retardé à la file d'attenteprogress les progrès de l'emploi allant de 0 à 100failed attempt du travail a échoué, mais a encore des tentativesfailed le travail a échoué et n'a pas de tentatives restantescomplete le travail a terminéremove le travail a été suppriméPar exemple, cela peut ressembler à ce qui suit:
var job = queue . create ( 'video conversion' , {
title : 'converting loki's to avi'
, user : 1
, frames : 200
} ) ;
job . on ( 'complete' , function ( result ) {
console . log ( 'Job completed with data ' , result ) ;
} ) . on ( 'failed attempt' , function ( errorMessage , doneAttempts ) {
console . log ( 'Job failed' ) ;
} ) . on ( 'failed' , function ( errorMessage ) {
console . log ( 'Job failed' ) ;
} ) . on ( 'progress' , function ( progress , data ) {
console . log ( 'r job #' + job . id + ' ' + progress + '% complete with data ' , data ) ;
} ) ;Notez que les événements au niveau de l'emploi ne sont pas garantis pour être reçus lors des redémarrages de processus, car le processus Node.js redémarré perdra la référence à l'objet de travail spécifique. Si vous voulez un gestionnaire d'événements plus fiable, consultez les événements de file d'attente.
Remarquez Kue stocke les objets de travail en mémoire jusqu'à ce qu'ils soient terminés / n'étaient pas en mesure d'émettre des événements sur eux. Si vous avez une concurrence énorme dans les travaux inachevés, éteignez cette fonctionnalité et utilisez des événements au niveau de la file d'attente pour une meilleure mise à l'échelle de la mémoire.
kue . createQueue ( { jobEvents : false } ) Alternativement, vous pouvez utiliser les events de fonction au niveau du travail pour contrôler si les événements sont licenciés pour un emploi au niveau du travail.
var job = queue . create ( 'test' ) . events ( false ) . save ( ) ; Les événements au niveau de la file d'attente permettent d'accès aux événements au niveau de l'emploi mentionnés précédemment, mais élaboré à l'instance Queue pour appliquer la logique au niveau "global". Un exemple de ceci est de supprimer les travaux terminés:
queue . on ( 'job enqueue' , function ( id , type ) {
console . log ( 'Job %s got queued of type %s' , id , type ) ;
} ) . on ( 'job complete' , function ( id , result ) {
kue . Job . get ( id , function ( err , job ) {
if ( err ) return ;
job . remove ( function ( err ) {
if ( err ) throw err ;
console . log ( 'removed completed job #%d' , job . id ) ;
} ) ;
} ) ;
} ) ;Les événements disponibles sont les mêmes que ceux mentionnés dans les "événements de l'emploi", mais préfixés avec "Job".
Des travaux retardés peuvent être prévus pour être mis en file d'attente pour une distance arbitraire à temps en invoquant la méthode .delay(ms) , passant le nombre de millisecondes par rapport à maintenant . Alternativement, vous pouvez passer un objet JavaScript Date avec une heure spécifique dans le futur. Cela signale automatiquement le Job comme "retardé".
var email = queue . create ( 'email' , {
title : 'Account renewal required'
, to : '[email protected]'
, template : 'renewal-email'
} ) . delay ( milliseconds )
. priority ( 'high' )
. save ( ) ;Kue vérifiera les travaux retardés avec une minuterie, en les faisant la promotion si le retard prévu a été dépassé, défautant à une vérification des 1000 top 1000 chaque seconde.
Les travaux de traitement sont simples avec Kue. Créez d'abord une instance Queue comme nous le faisons pour créer des travaux, nous offrant un accès à redis, etc., puis invoquez queue.process() avec le type associé. Notez que contrairement à ce que le nom createQueue suggère, il renvoie actuellement une instance Queue singleton. Vous pouvez donc configurer et utiliser un seul objet Queue dans votre processus Node.js.
Dans l'exemple suivant, nous passons le rappel done par email , lorsqu'une erreur se produit, nous invoquons done(err) pour dire à Kue que quelque chose s'est produit, sinon nous invoquons done() uniquement lorsque le travail est terminé. Si cette fonction répond par une erreur, elle sera affichée dans l'interface utilisateur et le travail sera marqué en échec. L'objet d'erreur transmis à fait, devrait être d' Error de type standard.
var kue = require ( 'kue' )
, queue = kue . createQueue ( ) ;
queue . process ( 'email' , function ( job , done ) {
email ( job . data . to , done ) ;
} ) ;
function email ( address , done ) {
if ( ! isValidEmail ( address ) ) {
//done('invalid to address') is possible but discouraged
return done ( new Error ( 'invalid to address' ) ) ;
}
// email send stuff...
done ( ) ;
} Les travailleurs peuvent également transmettre le résultat du travail comme le deuxième paramètre à done(null,result) pour stocker cela dans la clé Job.result . result est également passé par des gestionnaires d'événements complete afin que les producteurs d'emplois puissent le recevoir s'ils le souhaitent.
Par défaut, un appel à queue.process() n'acceptera qu'un seul travail à la fois de traitement. Pour les petites tâches comme l'envoi d'e-mails, ce n'est pas idéal, nous pouvons donc spécifier les travaux actifs maximaux pour ce type en passant un numéro:
queue . process ( 'email' , 20 , function ( job , done ) {
// ...
} ) ; Les travailleurs peuvent s'arrêter temporairement et reprendre leur activité. Autrement dit, après avoir appelé pause ils ne recevront aucun travail dans leur rappel jusqu'à ce que resume soit appelé. La fonction pause ferme gracieusement ce travailleur et utilise les mêmes fonctionnalités internes que la méthode shutdown dans l'arrêt gracieux.
queue . process ( 'email' , function ( job , ctx , done ) {
ctx . pause ( 5000 , function ( err ) {
console . log ( "Worker is paused... " ) ;
setTimeout ( function ( ) { ctx . resume ( ) ; } , 10000 ) ;
} ) ;
} ) ; Remarque Le paramètre ctx de Kue >=0.9.0 est le deuxième argument de la fonction de rappel de processus et done est idiomatiquement toujours le dernier
Remarque La signature de la méthode pause est modifiée de Kue >=0.9.0 pour déplacer la fonction de rappel vers le dernier.
Pour un "vrai" exemple, disons que nous devons compiler un PDF à partir de nombreuses diapositives avec des canaux de nœuds. Notre travail peut être composé des données suivantes, notez qu'en général, vous ne devez pas stocker de grandes données dans le travail, il est préférable de stocker des références comme des ID, de les tirer pendant le traitement.
queue . create ( 'slideshow pdf' , {
title : user . name + "'s slideshow"
, slides : [ ... ] // keys to data stored in redis, mongodb, or some other store
} ) ; Nous pouvons accéder à ces mêmes données arbitraires dans un processus distinct lors du traitement, via la propriété job.data . Dans l'exemple, nous rendons chaque diapositive un par un, la mise à jour du journal et des progrès du travail.
queue . process ( 'slideshow pdf' , 5 , function ( job , done ) {
var slides = job . data . slides
, len = slides . length ;
function next ( i ) {
var slide = slides [ i ] ; // pretend we did a query on this slide id ;)
job . log ( 'rendering %dx%d slide' , slide . width , slide . height ) ;
renderSlide ( slide , function ( err ) {
if ( err ) return done ( err ) ;
job . progress ( i , len , { nextSlide : i == len ? 'itsdone' : i + 1 } ) ;
if ( i == len ) done ( )
else next ( i + 1 ) ;
} ) ;
}
next ( 0 ) ;
} ) ; Queue#shutdown([timeout,] fn) signale tous les travailleurs pour arrêter le traitement après la fin de leur travail actif actuel. Les travailleurs attendront timeout des millisecondes pour leur travail actif pour être appelé ou marquer le travail actif failed avec une raison d'erreur de fermeture. Lorsque tous les travailleurs disent à Kue qu'ils sont arrêtés, fn est appelé.
var queue = require ( 'kue' ) . createQueue ( ) ;
process . once ( 'SIGTERM' , function ( sig ) {
queue . shutdown ( 5000 , function ( err ) {
console . log ( 'Kue shutdown: ' , err || '' ) ;
process . exit ( 0 ) ;
} ) ;
} ) ; Notez que la signature de la méthode shutdown est modifiée de Kue >=0.9.0 pour déplacer la fonction de rappel vers le dernier.
Toutes les erreurs dans la bibliothèque client redis ou la file d'attente sont émises dans l'objet Queue . Vous devez lier les événements error pour empêcher les exceptions non revues ou déboguer les erreurs de Kue.
var queue = require ( 'kue' ) . createQueue ( ) ;
queue . on ( 'error' , function ( err ) {
console . log ( 'Oops... ' , err ) ;
} ) ; Kue marque un travail complet / échoué lorsque done êtes appelé par votre travailleur, vous devez donc utiliser une gestion des erreurs appropriée pour empêcher les exceptions non apprises dans le code de votre travailleur et le processus Node.js qui sort avant dans les travaux de manche. Cela peut être réalisé de deux manières:
queue . process ( 'my-error-prone-task' , function ( job , done ) {
var domain = require ( 'domain' ) . create ( ) ;
domain . on ( 'error' , function ( err ) {
done ( err ) ;
} ) ;
domain . run ( function ( ) { // your process function
throw new Error ( 'bad things happen' ) ;
done ( ) ;
} ) ;
} ) ;Avis - Les domaines sont obsolètes des NodeJ avec stabilité 0 et il n'est pas recommandé de l'utiliser.
Il s'agit de la solution la plus douce et la meilleure, mais n'est pas intégrée avec Kue. Veuillez vous référer à cette discussion. Vous pouvez commenter cette fonctionnalité dans le problème de Kue ouvert connexe.
Vous pouvez également utiliser des promesses pour faire quelque chose comme
queue . process ( 'my-error-prone-task' , function ( job , done ) {
Promise . method ( function ( ) { // your process function
throw new Error ( 'bad things happen' ) ;
} ) ( ) . nodeify ( done )
} ) ;Mais cela n'attrapera pas des exceptions dans votre pile d'appels asynchrones comme le font les domaines.
uncaughtException et à arrêter gracieusement le Kue, mais ce n'est pas un idiome de gestion d'erreur recommandé en JavaScript car vous perdez le contexte d'erreur. process . once ( 'uncaughtException' , function ( err ) {
console . error ( 'Something bad happened: ' , err ) ;
queue . shutdown ( 1000 , function ( err2 ) {
console . error ( 'Kue shutdown result: ' , err2 || 'OK' ) ;
process . exit ( 0 ) ;
} ) ;
} ) ;Kue utilise actuellement la gestion de l'état d'emploi côté client et lorsque Redis se bloque au milieu de ces opérations, certains travaux bloqués ou incohérences d'index se produiront. La conséquence est qu'un certain nombre d'emplois seront bloqués et ne seront retirés que par les travailleurs uniquement lorsque de nouveaux emplois seront créés, si plus de nouveaux emplois ne sont créés, ils sont restés pour toujours. Nous vous suggérons donc fortement d'exécuter un chien de garde pour résoudre ce problème en appelant:
queue . watchStuckJobs ( interval ) interval est en millisecondes et par défaut à 1000 ms
Kue sera refactorisée à la gestion de l'état d'emploi entièrement atomique à partir de la version 1.0 et cela se produira par les scripts LUA et / ou la combinaison BRPOPLPUSH. Vous pouvez en savoir plus ici et ici.
La file d'attente a deux types de méthodes pour vous parler du nombre de travaux dans chaque état
queue . inactiveCount ( function ( err , total ) { // others are activeCount, completeCount, failedCount, delayedCount
if ( total > 100000 ) {
console . log ( 'We need some back pressure here' ) ;
}
} ) ;Vous pouvez également interroger sur un type de travail spécifique:
queue . failedCount ( 'my-critical-job' , function ( err , total ) {
if ( total > 10000 ) {
console . log ( 'This is tOoOo bad' ) ;
}
} ) ;Et itérer sur les identifiants d'emploi
queue . inactive ( function ( err , ids ) { // others are active, complete, failed, delayed
// you may want to fetch each id to get the Job object out of it...
} ) ; Cependant, le second ne s'étend pas sur de grands déploiements, vous pouvez y utiliser des méthodes statiques Job plus spécifiques:
kue . Job . rangeByState ( 'failed' , 0 , n , 'asc' , function ( err , jobs ) {
// you have an array of maximum n Job objects here
} ) ;ou
kue . Job . rangeByType ( 'my-job-type' , 'failed' , 0 , n , 'asc' , function ( err , jobs ) {
// you have an array of maximum n Job objects here
} ) ;Notez que les deux dernières méthodes sont susceptibles de changer dans les versions KUE ultérieures.
Si vous n'en avez rien fait ci-dessus dans la section de gestion des erreurs ou que votre processus a perdu des travaux actifs, vous pouvez vous remettre d'eux lorsque votre processus est redémarré. Une logique aveugle serait de repeindre tous les travaux coincés:
queue . active ( function ( err , ids ) {
ids . forEach ( function ( id ) {
kue . Job . get ( id , function ( err , job ) {
// Your application should check if job is a stuck one
job . inactive ( ) ;
} ) ;
} ) ;
} ) ;Remarque Dans un déploiement en cluster, votre demande doit être consciente de ne pas impliquer un travail valide, actuellement en cours de traitement par d'autres travailleurs.
Les données de l'emploi et les index de recherche mangent un espace mémoire Redis, vous aurez donc besoin d'un processus de maintien du travail dans les déploiements réels. Votre première chance consiste à utiliser la suppression automatique des travaux à la fin.
queue . create ( ... ) . removeOnComplete ( true ) . save ( ) Mais si vous avez finalement / temporellement besoin de données d'emploi terminées, vous pouvez configurer un script de suppression de travail à la demande comme ci-dessous pour supprimer les travaux complets du Top n :
kue . Job . rangeByState ( 'complete' , 0 , n , 'asc' , function ( err , jobs ) {
jobs . forEach ( function ( job ) {
job . remove ( function ( ) {
console . log ( 'removed ' , job . id ) ;
} ) ;
} ) ;
} ) ; Notez que vous devriez fournir suffisamment de temps pour que les appels .remove
Par défaut, Kue se connectera à Redis à l'aide des paramètres par défaut du client (le port par défaut est 6379 , l'hôte par défaut est à 127.0.0.1 , le préfixe par défaut est q ). Queue#createQueue(options) accepte les options de connexion Redis dans la touche options.redis .
var kue = require ( 'kue' ) ;
var q = kue . createQueue ( {
prefix : 'q' ,
redis : {
port : 1234 ,
host : '10.0.50.20' ,
auth : 'password' ,
db : 3 , // if provided select a non-default redis db
options : {
// see https://github.com/mranney/node_redis#rediscreateclient
}
}
} ) ; prefix contrôle les noms de clés utilisés dans Redis. Par défaut, c'est simplement q . Le préfixe ne doit généralement pas être modifié sauf si vous avez besoin d'utiliser une instance redis pour plusieurs applications. Il peut également être utile pour fournir un bilan d'essai isolé sur votre application principale.
Vous pouvez également spécifier les informations de connexion en tant que chaîne d'URL.
var q = kue . createQueue ( {
redis : 'redis://example.com:1234?redis_option=value&redis_option=value'
} ) ; Étant donné que Node_redis prend en charge les sockets de domaine UNIX, vous pouvez également dire à Kue de le faire. Voir Unix-Domain-Socket pour votre configuration Redis Server.
var kue = require ( 'kue' ) ;
var q = kue . createQueue ( {
prefix : 'q' ,
redis : {
socket : '/data/sockets/redis.sock' ,
auth : 'password' ,
options : {
// see https://github.com/mranney/node_redis#rediscreateclient
}
}
} ) ; Toute bibliothèque client Node.js Redis conforme (ou lorsqu'elle est adaptée) à l'API Node_redis peut être injectée dans Kue. Vous ne devez fournir qu'une fonction createClientFactory comme une usine de connexion Redis au lieu de fournir des options de connexion Node_redis.
Vous trouverez ci-dessous un exemple de code pour permettre à Redis-Sentinel de se connecter à Redis Sentinel pour le basculement automatique maître / esclave.
var kue = require ( 'kue' ) ;
var Sentinel = require ( 'redis-sentinel' ) ;
var endpoints = [
{ host : '192.168.1.10' , port : 6379 } ,
{ host : '192.168.1.11' , port : 6379 }
] ;
var opts = options || { } ; // Standard node_redis client options
var masterName = 'mymaster' ;
var sentinel = Sentinel . Sentinel ( endpoints ) ;
var q = kue . createQueue ( {
redis : {
createClientFactory : function ( ) {
return sentinel . createClient ( masterName , opts ) ;
}
}
} ) ; Notez que tous les codes clients <0.8.x doivent être refactorisés pour transmettre des options redis pour Queue#createQueue au lieu de remplacer le style de singe de redis#createClient ou ils seront brisés à partir de Kue 0.8.x
var Redis = require ( 'ioredis' ) ;
var kue = require ( 'kue' ) ;
// using https://github.com/72squared/vagrant-redis-cluster
var queue = kue . createQueue ( {
redis : {
createClientFactory : function ( ) {
return new Redis . Cluster ( [ {
port : 7000
} , {
port : 7001
} ] ) ;
}
}
} ) ; L'interface utilisateur est une petite application express. Un script est fourni en bin/ pour exécuter l'interface en tant qu'application autonome avec des paramètres par défaut. Vous pouvez transmettre des options pour le port, redis-url et préfixe. Par exemple:
node_modules/kue/bin/kue-dashboard -p 3050 -r redis://127.0.0.1:3000 -q prefix
Vous pouvez également le déclencher à partir d'une autre application:
var kue = require ( 'kue' ) ;
kue . createQueue ( ... ) ;
kue . app . listen ( 3000 ) ;Le titre par défaut "Kue", pour modifier cette invoque:
kue . app . set ( 'title' , 'My Application' ) ; Notez que si vous utilisez des options Kue non défaut, kue.createQueue(...) doit être appelé avant d'accéder kue.app .
Vous pouvez également utiliser l'interface Web Kue-UI apportée par Arnaud Bénard
Avec l'interface utilisateur, Kue expose également une API JSON, qui est utilisée par l'interface utilisateur.
Des travaux de requête, par exemple "get / job / search? Q = vidéo avi":
[ "5" , "7" , "10" ] Par défaut, Kue index l'intégralité de l'objet de données de travail pour la recherche, mais cela peut être personnalisé via l'appel Job#searchKeys pour dire à Kue quelles clés sur les données du travail pour créer l'index pour:
var kue = require ( 'kue' ) ;
queue = kue . createQueue ( ) ;
queue . create ( 'email' , {
title : 'welcome email for tj'
, to : '[email protected]'
, template : 'welcome-email'
} ) . searchKeys ( [ 'to' , 'title' ] ) . save ( ) ; La fonction de recherche est désactivée par défaut de Kue >=0.9.0 . En savoir plus ici. Vous devez activer les index de recherche et ajouter des rouges dans vos dépendances si vous en avez besoin:
var kue = require ( 'kue' ) ;
q = kue . createQueue ( {
disableSearch : false
} ) ; npm install reds --save
Répond actuellement avec le nombre d'État et le temps d'activité des travailleurs en millisecondes:
{ "inactiveCount" : 4 , "completeCount" : 69 , "activeCount" : 2 , "failedCount" : 0 , "workTime" : 20892 } Obtenez un emploi par :id :
{ "id" : "3" , "type" : "email" , "data" : { "title" : "welcome email for tj" , "to" : "[email protected]" , "template" : "welcome-email" } , "priority" : - 10 , "progress" : "100" , "state" : "complete" , "attempts" : null , "created_at" : "1309973155248" , "updated_at" : "1309973155248" , "duration" : "15002" } Obtenez un travail :id :
[ 'foo' , 'bar' , 'baz' ] Obtenez des emplois avec la plage spécifiée :from :to : par exemple "/jobs/0..2", où :order peut être "ASC" ou "DESC":
[ { "id" : "12" , "type" : "email" , "data" : { "title" : "welcome email for tj" , "to" : "[email protected]" , "template" : "welcome-email" } , "priority" : - 10 , "progress" : 0 , "state" : "active" , "attempts" : null , "created_at" : "1309973299293" , "updated_at" : "1309973299293" } , { "id" : "130" , "type" : "email" , "data" : { "title" : "welcome email for tj" , "to" : "[email protected]" , "template" : "welcome-email" } , "priority" : - 10 , "progress" : 0 , "state" : "active" , "attempts" : null , "created_at" : "1309975157291" , "updated_at" : "1309975157291" } ] Identique à ci-dessus, restreindre par :state qui est l'un des:
- active
- inactive
- failed
- complete
Identique à ci-dessus, aussi restreint à :type et :state .
Supprimer le travail :id :
$ curl -X DELETE http://local:3000/job/2
{"message":"job 2 removed"}
Créer un travail:
$ curl -H "Content-Type: application/json" -X POST -d
'{
"type": "email",
"data": {
"title": "welcome email for tj",
"to": "[email protected]",
"template": "welcome-email"
},
"options" : {
"attempts": 5,
"priority": "high"
}
}' http://localhost:3000/job
{"message": "job created", "id": 3}
Vous pouvez créer plusieurs travaux à la fois en passant un tableau. Dans ce cas, la réponse sera également un tableau, préservant la commande:
$ curl -H "Content-Type: application/json" -X POST -d
'[{
"type": "email",
"data": {
"title": "welcome email for tj",
"to": "[email protected]",
"template": "welcome-email"
},
"options" : {
"attempts": 5,
"priority": "high"
}
},
{
"type": "email",
"data": {
"title": "followup email for tj",
"to": "[email protected]",
"template": "followup-email"
},
"options" : {
"delay": 86400,
"attempts": 5,
"priority": "high"
}
}]' http://localhost:3000/job
[
{"message": "job created", "id": 4},
{"message": "job created", "id": 5}
]
Remarque: Lors de l'insertion de plusieurs travaux en vrac, si une insertion échoue, Kue continuera à traiter les travaux restants dans l'ordre. Le tableau de réponse contiendra les ID des travaux ajoutés avec succès, et tout élément échoué sera un objet décrivant l'erreur: {"error": "error reason"} .
L'exemple ci-dessous montre comment vous pouvez utiliser le cluster pour répartir la charge de traitement du travail à travers les processeurs. Veuillez consulter la documentation du module de cluster pour des exemples plus détaillés sur son utilisation.
Lorsque Cluster .isMaster le fichier est exécuté dans le contexte du processus maître, auquel cas vous pouvez effectuer des tâches que vous voulez une seule fois, comme le démarrage de l'application Web groupé avec Kue. La logique du bloc else est exécutée par travailleur .
var kue = require ( 'kue' )
, cluster = require ( 'cluster' )
, queue = kue . createQueue ( ) ;
var clusterWorkerSize = require ( 'os' ) . cpus ( ) . length ;
if ( cluster . isMaster ) {
kue . app . listen ( 3000 ) ;
for ( var i = 0 ; i < clusterWorkerSize ; i ++ ) {
cluster . fork ( ) ;
}
} else {
queue . process ( 'email' , 10 , function ( job , done ) {
var pending = 5
, total = pending ;
var interval = setInterval ( function ( ) {
job . log ( 'sending!' ) ;
job . progress ( total - pending , total ) ;
-- pending || done ( ) ;
pending || clearInterval ( interval ) ;
} , 1000 ) ;
} ) ;
} Cela créera un processeur d'emploi email (travailleur) pour chacun de vos cœurs de processeur de machine, avec chacun, vous pouvez gérer 10 travaux de messagerie simultanés, ce qui conduit à 10 * N travaux de messagerie simultanés traités dans votre machine N Core.
Maintenant, lorsque vous visitez l'interface utilisateur de Kue dans le navigateur, vous verrez que les emplois sont traités à N près plus rapidement! (Si vous avez N cœurs).
Grâce à l'utilisation du montage des applications, vous pouvez personnaliser l'application Web, activer TLS ou ajouter des middleware supplémentaires comme basic-auth-connect .
$ npm install --save basic-auth-connect var basicAuth = require ( 'basic-auth-connect' ) ;
var app = express . createServer ( { ... tls options ... } ) ;
app . use ( basicAuth ( 'foo' , 'bar' ) ) ;
app . use ( kue . app ) ;
app . listen ( 3000 ) ; Activez le mode de test pour pousser tous les travaux dans un tableau jobs . Faire des affirmations contre les emplois de ce tableau pour garantir que le code testé est correctement en train de faire des travaux.
queue = require ( 'kue' ) . createQueue ( ) ;
before ( function ( ) {
queue . testMode . enter ( ) ;
} ) ;
afterEach ( function ( ) {
queue . testMode . clear ( ) ;
} ) ;
after ( function ( ) {
queue . testMode . exit ( )
} ) ;
it ( 'does something cool' , function ( ) {
queue . createJob ( 'myJob' , { foo : 'bar' } ) . save ( ) ;
queue . createJob ( 'anotherJob' , { baz : 'bip' } ) . save ( ) ;
expect ( queue . testMode . jobs . length ) . to . equal ( 2 ) ;
expect ( queue . testMode . jobs [ 0 ] . type ) . to . equal ( 'myJob' ) ;
expect ( queue . testMode . jobs [ 0 ] . data ) . to . eql ( { foo : 'bar' } ) ;
} ) ;IMPORTANT: Par défaut, les travaux ne sont pas traités lorsqu'ils sont créés en mode test. Vous pouvez activer le traitement du travail en passant fidèle à TestMode.enter
before ( function ( ) {
queue . testMode . enter ( true ) ;
} ) ; Nous aimons les contributions!
Lorsque vous contribuez, suivez les règles simples:
(La licence MIT)
Copyright (c) 2011 Learnboost <[email protected]>
L'autorisation est accordée gratuitement par la présente à toute personne qui obtient une copie de ce logiciel et des fichiers de documentation associés (le `` logiciel ''), pour traiter le logiciel sans restriction, y compris sans limiter les droits d'utilisation, de copier, de modifier, de fusionner , publier, distribuer, sous-licencier et / ou vendre des copies du logiciel, et pour permettre aux personnes à qui le logiciel est fourni pour le faire, sous réserve des conditions suivantes:
L'avis de droit d'auteur ci-dessus et le présent avis d'autorisation sont inclus dans toutes les copies ou des parties substantielles du logiciel.
Le logiciel est fourni «tel quel», sans garantie d'aucune sorte, express ou implicite, y compris, mais sans s'y limiter, les garanties de qualité marchande, d'adéquation à un usage particulier et de non-contrefaçon. En aucun cas, les auteurs ou les titulaires de droits d'auteur ne seront pas responsables de toute réclamation, dommage ou autre responsabilité, que ce soit dans une action de contrat, de délit ou autre, découlant de, hors du logiciel ou de l'utilisation ou d'autres transactions dans le LOGICIEL.
