Comme beaucoup de questions d'architecture "grandes images", la meilleure solution est vraiment l'une d'entre elles... ça dépend. Pouvez-vous contrôler l'environnement de déploiement ? Autrement dit... pouvez-vous utiliser le serveur de messagerie de votre choix ou êtes-vous contraint d'en utiliser un qui est déjà installé et hébergé ? Pouvez-vous exécuter du code sur la même machine que le service SMTP ? Ces questions, et bien d'autres, doivent être prises en compte pour arriver à une architecture (quasi) optimale.
Compte tenu de cela, je vais faire quelques hypothèses et proposer quelques idées qui, à mon avis, valent la peine d'être explorées...
Vous devriez vous pencher sur un système de messagerie performant. Plus précisément, jetez un œil à RabbitMQ . RabbitMQ est fiable et efficace, et la répartition de la charge de travail basée sur des événements entrants asynchrones est un modèle dont ils discutent spécifiquement dans leurs (à mon avis, très bons) tutoriels.
Avec un serveur de messagerie comme celui-ci, vous avez un processus qui reçoit le courrier électronique entrant. De préférence, cela se fait dans le cadre du processus SMTP, ou du moins très près de celui-ci - en particulier avec la charge de travail que vous avez mentionnée. Si vous n'avez pas d'autre choix, alors vos idées sur l'utilisation de cron pour collecter des messages via POP ou IMAP devront fonctionner, pour l'instant.
Le processus de collecte des e-mails pousserait alors les messages dans la file d'attente RabbitMQ. (Peut-être pas littéralement les e-mails eux-mêmes, bien que ce soit une possibilité, mais je pensais plutôt à des références à l'endroit où l'e-mail est efficacement stocké). Vous exécutez ensuite plusieurs processus de travail qui sont abonnés à une file d'attente de messages nommée. RabbitMQ (ou tout autre service de messagerie que vous choisissez) distribuerait ensuite ces messages de manière circulaire aux abonnés individuels. S'ils sont déjà chargés, les processus de travail peuvent NACKer le message ou renvoyer leur propre message de flux de contrôle au service. Avec une charge de travail TRÈS élevée (encore une fois, comme vous l'avez proposé), je recommanderais fortement une sorte de processus de gestion qui garde un œil sur la santé globale du système distribué. Le gestionnaire recueillerait des statistiques sur le temps d'exécution (TRÈS utiles pour la planification de la croissance future, l'optimisation et la refactorisation de l'ensemble du système) et aurait la capacité de lancer et d'arrêter de nouveaux processus de travail. Avant d'arriver à cette charge de travail très élevée, et en supposant que vos processus de travail sont stables et peuvent vivre longtemps sans fragmentation de la mémoire, etc., il suffit d'utiliser le serveur de messages pour répartir le travail.
Pour ce que ça vaut, j'ai une certaine expérience dans l'écriture de processeurs de messagerie (en particulier xmail - celui que je recommanderais si vous venez de démarrer votre projet et avez beaucoup de contrôle sur ses premières étapes). De plus, j'utilise actuellement RabbitMQ pour créer un système de mise en cache des résultats multi-agents pour une grille de calcul scientifique majeure.
Quoi qu'il en soit... bonne chance pour votre projet !
