Som många "storbilds" arkitekturfrågor, är den bästa lösningen verkligen en av dessa...det beror på. Kan du styra distributionsmiljön? Det vill säga...kan du använda vilken e-postserver du vill, eller är du tvungen att använda en som redan är installerad och värd? Kan du köra kod på samma maskin som SMTP-tjänsten? Dessa frågor och många andra bör övervägas för att komma fram till en (nästan) optimal arkitektur.
Med tanke på det kommer jag att göra ett par antaganden och ge några idéer som jag tycker är värda att utforska...
Du bör undersöka ett högpresterande meddelandesystem. Mer specifikt, ta en titt på RabbitMQ . RabbitMQ är pålitligt och effektivt, och fördelningen av arbetsbelastningen baserat på asynkrona inkommande händelser är ett mönster som de specifikt diskuterar i sina (enligt min mening, mycket bra) handledningar.
Med en meddelandeserver som denna har du en process som tar emot det inkommande e-postmeddelandet. Helst görs detta som en del av SMTP-processen, eller åtminstone mycket nära den - speciellt med den arbetsbelastning som du har nämnt. Om du inte har något annat val måste dina idéer om att använda cron för att samla in meddelanden via POP eller IMAP fungera, tills vidare.
E-postinsamlingsprocessen skulle sedan skicka meddelanden till RabbitMQ-kön. (Kanske inte bokstavligen själva e-postmeddelandena, även om det är en möjlighet, men jag tänkte mer som referenser till var e-posten lagras effektivt). Du kör sedan flera arbetsprocesser som prenumererar på en namngiven meddelandekö. RabbitMQ (eller vilken meddelandetjänst du än bestämmer dig för) skulle sedan distribuera dessa meddelanden på ett round-robin-sätt till de enskilda prenumeranterna. Om de redan är laddade kan arbetsprocesser NACKA meddelandet eller skicka sina egna kontrollflödesmeddelanden tillbaka till tjänsten. Med en MYCKET hög arbetsbelastning (igen, som du har föreslagit), skulle jag starkt rekommendera någon form av hanteringsprocess som håller koll på det distribuerade systemets allmänna hälsa. Chefen skulle samla in körtidsstatistik (MYCKET användbar för framtida tillväxtplanering, optimering och omstrukturering av det övergripande systemet), och ha förmågan att snurra upp och stänga av nya arbetsprocesser. Innan du kommer till den mycket höga arbetsbelastningen, och om du antar att dina arbetsprocesser är stabila och kan leva länge utan minnesfragmentering etc., borde det räcka med att bara använda meddelandeservern för att distribuera arbete.
För vad det är värt, jag har haft lite erfarenhet av att skriva e-postbehandlare (särskilt xmail - en som jag skulle rekommendera om du precis har börjat ditt projekt och har mycket kontroll över dess tidiga skeden). Dessutom använder jag för närvarande RabbitMQ för att bygga ett multi-agent resultatcachesystem för ett stort vetenskapligt datornät.
Hur som helst...lycka till med ditt projekt!