Ich baue ein Reservierungssystem in Rails 4.2, wo ich eine Reihe von E-Mails an Benutzer in vordefinierten Intervallen senden muss (zum Beispiel, dass sie eine bevorstehende Reservierung haben, Feedback nachdem es fertig ist, einen Link) um eine bestehende Reservierung zu ändern/zu stornieren usw.). Ich habe mich umgesehen und gefunden this und this, aber ich versuche, zwischen den Ansätzen zu entscheiden.Ein System für Erinnerungs-E-Mails entwickeln
Ich sehe zwei Hauptwege zum Aufbau dieses Systems.
Verwenden eines Warteschlangensystems wie delayed_job. Wenn jemand eine Reservierung vornimmt, stellen wir alle E-Mails zur richtigen Zeit in die Warteschlange, wenn sie gesendet werden sollen.
Pro: Eine Warteschlange für alle E-Mails. Automatische Wiederholungslogik
Con: Tausende von E-Mails werden schließlich in das System eingereiht werden. Müssen entfernt werden, wenn jemand eine Reservierung storniert (abhängig: E-Mails damit zu zerstören, könnte ziemlich einfach sein). Etwas komplexere Logik um welche Zeit wir brauchen, um die E-Mails zu löschen.
cron+rakeAufgabe, die in einem vordefinierten Intervall ausgeführt wird (stündlich? Alle fünfzehn Minuten?) Und prüft, ob die E-Mails ausgehen müssen. Es wird eine Abfrage wie "Alle Reservierungen in drei Tagen ab jetzt suchen" ausgeführt und anschließend werden alle E-Mails gesendet.Pro: Setzen Sie alles in Anwendungslogik, reduzieren Sie die Menge an Zustand, den wir verfolgen müssen.
Con: Sie müssen verfolgen, welche E-Mails gesendet wurden. Dies ist konzeptionell ähnlich zu der Tabelle, die wir oben bereits erstellt haben.
Ich benutzte den zweiten Ansatz (weil ich nie an den ersten Ansatz gedacht hatte: P), irgendwie fühle ich mich wie der zweite Ansatz sicherer und einfacher zu verwalten ist. Sich auf einen verzögerten Job zu verlassen, ist irgendwie nicht so sicher, wie der Jobprozess fallen könnte, und komplexere Logik als das, was Sie erwähnt haben. – nayiaw