Подобно на много въпроси за архитектурата на „голяма картина“, най-доброто решение наистина е едно от тези... зависи. Можете ли да контролирате средата за внедряване? Това е... можете ли да използвате какъвто и да е имейл сървър, който искате, или сте ограничени да използвате такъв, който вече е инсталиран и хостван? Можете ли да стартирате код на същата машина като SMTP услугата? Тези въпроси, както и много други, трябва да бъдат разгледани, за да се създаде (почти) оптимална архитектура.
Предвид това, ще направя няколко предположения и ще предложа някои идеи, които смятам, че си струва да бъдат проучени...
Трябва да разгледате високопроизводителна система за съобщения. По-конкретно, разгледайте RabbitMQ . RabbitMQ е надежден и ефективен, а разпределението на работното натоварване въз основа на асинхронни входящи събития е модел, който те специално обсъждат в своите (според мен много добри) уроци.
С сървър за съобщения като този, имате един процес, който получава входящата поща. За предпочитане е това да се прави като част от SMTP процеса или поне много близо до него - особено с работното натоварване, което споменахте. Ако нямате друг избор, тогава вашите идеи за използване на cron за събиране на съобщения чрез POP или IMAP засега ще трябва да работят.
След това процесът на събиране на имейли ще изтласква съобщенията в опашката на RabbitMQ. (Може би не буквално самите имейли, въпреки че това е възможност, но мислех по-скоро като препратки към това къде имейлът се съхранява ефективно). След това изпълнявате множество работни процеси, които са абонирани за наименувана опашка от съобщения. RabbitMQ (или каквато и да е услуга за съобщения, която решите) след това ще разпредели тези съобщения по кръгова система до отделните абонати. Ако вече са заредени, работните процеси могат да NACK съобщението или да изпратят свое собствено съобщение за контролен поток обратно към услугата. С МНОГО голямо работно натоварване (отново, както предложихте), силно препоръчвам някакъв вид процес на управление, който следи цялостното здраве на разпределената система. Мениджърът ще събира статистически данни за времето на изпълнение (МНОГО полезно за бъдещо планиране на растеж, оптимизиране и рефакторинг на цялостната система) и ще има способността да стартира и изключва нови работни процеси. Преди да стигнете до това много голямо натоварване и ако приемем, че работните ви процеси са стабилни и могат да живеят дълго време без фрагментация на паметта и т.н., тогава просто използването на сървъра за съобщения за разпределяне на работата би трябвало да е достатъчно.
За какво си струва, имах известен опит в писането на имейл процесори (по-специално xmail - такъв, който бих препоръчал, ако току-що започвате своя проект и имате много контрол върху ранните му етапи). Освен това в момента използвам RabbitMQ, за да създам система за кеширане на резултати с множество агенти за голяма научна изчислителна мрежа.
Както и да е... успех с вашия проект!
