Анализ электронной почты и обработка архитекторов

Как и многие вопросы архитектуры «большой картины», лучшим решением на самом деле является один из них … это зависит. Можете ли вы контролировать среду развертывания? То есть … можете ли вы использовать любой сервер электронной почты, который вам нужен, или вы ограничены тем, что используете тот, который уже установлен и размещен? Можете ли вы запустить код на том же компьютере, что и служба SMTP? Эти вопросы и многие другие следует учитывать при создании (близкой) оптимальной архитектуры.

Учитывая это, я собираюсь сделать пару предположений и предложить некоторые идеи, которые, я думаю, стоит изучить …

Вы должны заглянуть в высокопроизводительную систему обмена сообщениями. В частности, взгляните на RabbitMQ . RabbitMQ является надежным и эффективным, а распределение рабочей нагрузки на основе асинхронных входящих событий – это шаблон, который они специально обсуждают в своих (на мой взгляд, очень хороших) учебниках.

С сервером обмена сообщениями, подобным этому, у вас есть один процесс, который получает входящую электронную почту. Предпочтительно это делается как часть процесса SMTP или, по крайней мере, очень близко к нему, особенно с упомянутой вами нагрузкой. Если у вас нет другого выбора, ваши идеи об использовании cron для сбора сообщений через POP или IMAP должны будут работать, пока.

Затем процесс сбора электронной почты будет толкать сообщения в очередь RabbitMQ. (Возможно, не буквально сами электронные письма, хотя это и есть возможность, но я больше думал о ссылках на то, где электронное письмо эффективно хранится). Затем вы запускаете несколько рабочих процессов, которые подписаны на именованную очередь сообщений. RabbitMQ (или любой другой сервис обмена сообщениями, который вы решаете) будет распространять эти сообщения циклически для отдельных подписчиков. Если он уже загружен, рабочие процессы могут выполнить NACK сообщение или отправить свое сообщение потока управления обратно в службу. С ОЧЕНЬ высокой рабочей нагрузкой (опять же, как и вы предложили), я настоятельно рекомендую какой-то процесс управления, который будет следить за общим состоянием распределенной системы. Менеджер собирал статистику времени выполнения (ОЧЕНЬ полезный для будущего планирования роста, оптимизации и рефакторинга всей системы), а также возможность разворачивать и закрывать новые рабочие процессы. Прежде чем вы перейдете к этой очень высокой нагрузке и считаете, что ваши рабочие процессы стабильны и могут длительное время прожить без фрагментации памяти и т. Д., Достаточно просто использовать сервер сообщений для распространения работы.

Для чего это стоит, у меня был некоторый опыт написания почтовых процессоров (в частности, xmail – тот, который я бы рекомендовал, если вы только начинаете свой проект и имеете большой контроль над его ранними этапами). Кроме того, в настоящее время я использую RabbitMQ для создания многоагентной системы кэширования результатов для крупной научной вычислительной сети.

В любом случае … удачи в вашем проекте!