2015-08-19 20 views
6

Sto costruendo un sistema di prenotazione in Rails 4.2 dove devo inviare una serie di email agli utenti a intervalli predefiniti (ad esempio che hanno una prenotazione imminente, un feedback dopo averlo fatto, un link per modificare/cancellare una prenotazione esistente, ecc.). Mi sono guardato intorno e ho trovato this e this, ma sto cercando di decidere tra gli approcci.Architettare un sistema per email di promemoria

Vedo due modi principali per costruire questo sistema.

  1. Utilizzo di un sistema di code come delayed_job. Ogni volta che qualcuno effettua una prenotazione, mettiamo in coda tutte le e-mail per l'orario corretto in cui devono essere inviate.

    Pro: una coda per tutte le e-mail. Logica automatica dei tentativi.

    Contro: Migliaia di e-mail finiranno per essere accodate nel sistema. È necessario disconnettersi ogni volta che qualcuno cancella una prenotazione (dipendente: distruggere le email relative ad esso potrebbe essere piuttosto facile). Una logica un po 'più complessa intorno a che ora abbiamo bisogno che le e-mail escano.

  2. cronrake attività che viene eseguita ad intervalli predefiniti (ogni ora? Ogni quindici minuti?) E controlla le e-mail che devono uscire. Esegue una query come "Trova tutte le prenotazioni tra tre giorni" e poi invia tutte le email.

    Pro: mettere tutto nella logica dell'applicazione, ridurre la quantità di stato di cui abbiamo bisogno per tenere traccia di.

    Con: È necessario tenere traccia di quali e-mail sono state inviate, il che è concettualmente simile a qualsiasi tabella di lavoro che abbiamo già creato sopra.

+0

Ho utilizzato il secondo approccio (perché non ho mai pensato al primo approccio: P), in qualche modo mi sembra che il secondo approccio sia più sicuro e più facile da gestire. Affidarsi a un lavoro ritardato è in qualche modo non così sicuro come il processo di lavoro potrebbe cadere e una logica più complessa come quello che hai menzionato. – nayiaw

risposta

0

secondo approccio è migliore (uso Heroku scheduler se su Heroku), le code sono più per "correre il più presto possibile" che "correre in questo particolare datetime"

0

L'unico buon vantaggio di 1) utilizzando delayed_job (o Sidekiq) è possibile aggiornare la pianificazione di un lavoro (o di un processo ricorrente) dal sito in modo dinamico.

È possibile fornire una pagina nel sito per aggiornare i lavori ricorrenti. Ora, delayed_job non consente realmente processi ricorrenti per impostazione predefinita. Ci sono gemme aggiuntive che potrebbero essere di interesse anche se delayed_job_recurring o sidekiq-scheduler. Se la potenza di calcolo non è un problema, preferirei sempre un vero processore di lavoro piuttosto che cron perché è solo più gestibile per me.

Problemi correlati