La mia applicazione crea processi di resque che devono essere elaborati in sequenza per utente e devono essere elaborati il più velocemente possibile (ritardo di 1 secondo).Resque: lavori time-critical eseguiti sequenzialmente per utente
Un esempio: job1 e job2 vengono creati per utente1 e job3 per utente2. Resque può elaborare job1 e job3 in parallelo, ma job1 e job2 devono essere elaborati in modo sequenziale.
ho pensieri diversi per una soluzione:
- ho potuto utilizzare diverse code (ad esempio queue_1 ... queue_10) e avviare un lavoratore per ogni coda (ad esempio
rake resque:work QUEUE=queue_1
). Gli utenti vengono assegnati a una coda/lavoratore in fase di esecuzione (ad esempio all'accesso, ogni giorno ecc.) - Potrei usare "code utente" dinamiche (ad es. Queue _ # {user.id}) e provare ad estendere resque che solo 1 operatore può elaborare una coda alla volta (come richiesto in Resque: one worker per queue)
- È possibile inserire i lavori in una coda non resque e utilizzare un "meta job per utente" con resque-lock (https://github.com/defunkt/resque-lock) che gestisce tali processi.
Hai qualche esperienza con uno di questi scenari nella pratica? Oppure hanno altre idee che potrebbero valere la pena di pensare? Gradirei qualsiasi input, grazie!
il problema è che job1 non deve sapere esplicitamente di job2 dal momento che essi non sono creati allo stesso tempo (che potrebbe creati in diverse richieste, ecc). – lacco
nel qual caso userei resque-retry, su job2, per eseguire un controllo se job1 è terminato e se non ri-accodare in seguito - resque-retry può essere impostato per utilizzare backoff esponenziali o trys limitati, se necessario. – TomDunning
In che modo job2 sa che job1 è in corso per un utente specifico? – lacco