Wie bei vielen "Big Picture"-Architekturfragen ist die beste Lösung wirklich eine davon ... es kommt darauf an. Können Sie die Bereitstellungsumgebung steuern? Das heißt ... können Sie einen beliebigen E-Mail-Server verwenden, oder sind Sie darauf beschränkt, einen bereits installierten und gehosteten Server zu verwenden? Können Sie Code auf demselben Computer wie den SMTP-Dienst ausführen? Diese Fragen und viele andere sollten berücksichtigt werden, um eine (nahezu) optimale Architektur zu finden.
In Anbetracht dessen werde ich ein paar Annahmen treffen und einige Ideen anbieten, von denen ich denke, dass sie es wert sind, untersucht zu werden ...
Sie sollten sich nach einem leistungsstarken Messaging-System umsehen. Sehen Sie sich insbesondere RabbitMQ an . RabbitMQ ist zuverlässig und effizient, und die Verteilung der Arbeitslast basierend auf asynchron eingehenden Ereignissen ist ein Muster, das sie speziell in ihren (meiner Meinung nach sehr guten) Tutorials diskutieren.
Bei einem Nachrichtenserver wie diesem haben Sie einen Prozess, der die eingehende E-Mail empfängt. Vorzugsweise geschieht dies als Teil des SMTP-Prozesses oder zumindest sehr nahe daran - insbesondere bei der von Ihnen erwähnten Arbeitslast. Wenn Sie keine andere Wahl haben, müssen Ihre Ideen zur Verwendung von Cron zum Sammeln von Nachrichten über POP oder IMAP vorerst funktionieren.
Der E-Mail-Sammelprozess würde dann Nachrichten in die RabbitMQ-Warteschlange verschieben. (Vielleicht nicht buchstäblich die E-Mails selbst, obwohl das eine Möglichkeit ist, aber ich dachte eher an Hinweise darauf, wo die E-Mails effizient gespeichert werden). Anschließend führen Sie mehrere Worker-Prozesse aus, die eine benannte Nachrichtenwarteschlange abonniert haben. RabbitMQ (oder für welchen Messaging-Dienst Sie sich auch entscheiden) verteilt diese Nachrichten dann im Round-Robin-Verfahren an die einzelnen Abonnenten. Wenn sie bereits geladen sind, können Worker-Prozesse die Nachricht NACKEN oder ihre eigene Ablaufsteuerungsnachricht an den Dienst zurücksenden. Bei einer SEHR hohen Arbeitslast (wiederum, wie Sie vorgeschlagen haben) würde ich dringend eine Art Verwaltungsprozess empfehlen, der den Gesamtzustand des verteilten Systems im Auge behält. Der Manager würde Laufzeitstatistiken sammeln (SEHR nützlich für die zukünftige Wachstumsplanung, Optimierung und Umgestaltung des Gesamtsystems) und die Möglichkeit haben, neue Worker-Prozesse hoch- und herunterzufahren. Bevor Sie diese sehr hohe Arbeitslast erreichen und vorausgesetzt, dass Ihre Arbeitsprozesse stabil sind und lange Zeit ohne Speicherfragmentierung usw. leben können, sollte die Verwendung des Nachrichtenservers zur Verteilung der Arbeit ausreichen.
Für das, was es wert ist, habe ich einige Erfahrung mit dem Schreiben von E-Mail-Prozessoren (insbesondere xmail ). - eine, die ich empfehlen würde, wenn Sie gerade erst mit Ihrem Projekt beginnen und viel Kontrolle über die frühen Phasen haben). Außerdem verwende ich derzeit RabbitMQ, um ein Ergebnis-Caching-System mit mehreren Agenten für ein großes wissenschaftliches Rechengrid zu erstellen.
Wie auch immer ... viel Glück mit Ihrem Projekt!
