Zoals bij veel "grotere" architectuurvragen, is de beste oplossing er echt een van ... het hangt ervan af. Kunt u de implementatieomgeving beheren? Dat wil zeggen... kunt u elke e-mailserver gebruiken die u wilt, of bent u beperkt tot het gebruik van een die al is geïnstalleerd en gehost? Kun je code uitvoeren op dezelfde machine als de SMTP-service? Deze vragen, en vele andere, moeten worden overwogen om tot een (bijna) optimale architectuur te komen.
Daarom ga ik een aantal aannames doen en enkele ideeën aandragen waarvan ik denk dat ze het onderzoeken waard zijn...
U moet kijken naar een krachtig berichtensysteem. Kijk vooral eens naar RabbitMQ . RabbitMQ is betrouwbaar en efficiënt, en de verdeling van de werklast op basis van asynchrone inkomende gebeurtenissen is een patroon dat ze specifiek bespreken in hun (naar mijn mening zeer goede) tutorials.
Met een berichtenserver als deze heb je één proces dat de inkomende e-mail ontvangt. Bij voorkeur wordt dit gedaan als onderdeel van het SMTP-proces, of in ieder geval heel dichtbij - vooral met de werklast die je hebt genoemd. Als je geen andere keuze hebt, zullen je ideeën over het gebruik van cron om berichten via POP of IMAP te verzamelen voorlopig moeten werken.
Het e-mailverzamelproces zou dan berichten in de RabbitMQ-wachtrij duwen. (Misschien niet letterlijk de e-mails zelf, hoewel dat een mogelijkheid is, maar ik dacht meer aan verwijzingen naar waar de e-mail efficiënt wordt opgeslagen). Vervolgens voert u meerdere werkprocessen uit die zijn geabonneerd op een benoemde berichtenwachtrij. RabbitMQ (of welke berichtenservice je ook kiest) zou die berichten dan op een round-robin-manier verspreiden naar de individuele abonnees. Indien al geladen, kunnen werkprocessen het bericht NACKEN of hun eigen controlestroombericht terugsturen naar de service. Met een ZEER hoge werklast (nogmaals, zoals je hebt voorgesteld), zou ik ten zeerste een soort beheerproces aanbevelen dat de algehele gezondheid van het gedistribueerde systeem in de gaten houdt. De manager zou runtime-statistieken verzamelen (ZEER handig voor toekomstige groeiplanning, optimalisatie en refactoring van het algehele systeem) en de mogelijkheid hebben om nieuwe werkprocessen op te starten en af te sluiten. Voordat u die zeer hoge werklast bereikt en ervan uitgaat dat uw werkprocessen stabiel zijn en lang kunnen leven zonder geheugenfragmentatie, enz., zou het voldoende moeten zijn om de berichtenserver te gebruiken om werk te verdelen.
Voor wat het waard is, ik heb enige ervaring met het schrijven van e-mailprocessors (in het bijzonder xmail - een die ik zou aanraden als je net begint met je project en veel controle hebt over de vroege stadia). Ik gebruik momenteel RabbitMQ ook om een cachingsysteem voor resultaten met meerdere agenten te bouwen voor een groot wetenschappelijk computerraster.
Hoe dan ook... succes met je project!