Крон, электронная почта, производительность - PullRequest
1 голос
/ 21 сентября 2009

Я строю систему для своего клиента. Это очень похоже на www.getafreelancer.com. Существует 2 типа пользователей: поставщик услуг и покупатель услуг. Сервис Покупатели размещают проекты. Поставщики услуг уведомляются о любых новых опубликованных проектах, которые соответствуют их классификации.

Предположим: Есть около 100 квалификаций. Поставщик услуг может выбрать 10-15 квалификаций. Сейчас около 100 проектов публикуются ежедневно. И есть 1 миллион поставщиков услуг. И проблема в том, что мы должны отправлять уведомления по электронной почте поставщикам услуг в соответствии с выбранной квалификацией в соответствии с категорией проекта. (Для всех 100 проектов ежедневно).

Это было бы как продолжение пользователя за пользователем. Проверка их квалификации с категорией проекта и отправка им по электронной почте. Как я могу отправлять 20 * 1 миллион = 20 миллионов писем в день?

(В настоящее время пользователей не будет 1 миллион. Но программирование должно выполняться с учетом будущих требований)

Пожалуйста, предоставьте несколько предложений.

Мой вопрос: понадобится ли мне какое-то специальное оборудование для отправки 1 миллиона писем?

Ответы [ 2 ]

1 голос
/ 21 сентября 2009

Это лот электронной почты. Во-первых, маловероятно, что вы когда-нибудь будете отправлять столько электронных писем, поэтому я бы не разработал вашу систему для такого объема. Вам следует подумать о настройке своего сервиса таким образом, чтобы было необходимо меньше писем (ежедневная сводка, более избирательный таргетинг, RSS-каналы). Но даже если вы отправляете 500 000 электронных писем в день, вам понадобится мощная инфраструктура или вы заплатите ESP, как VerticalResponse, лот денег. Бесплатные агенты передачи почты (MTA) включают Postfix и SendMail. Коммерческие варианты включают Strongmail и PowerMTA. С таким большим количеством писем вам, вероятно, придется остерегаться жалоб на спам (в зависимости от того, как проходит процесс проверки вашего проекта). ReturnPath полезен для этого.

1 голос
/ 21 сентября 2009

Исходя из того, как вы задаете вопрос, немного сложно понять, чего вы хотите.

Если вы хотите отправлять электронную почту практически в реальном времени, жизнь довольно проста. У некоторых покупателей есть потребность, и как только они публикуют ее, вы отправляете кучу уведомлений. Это будет трудно измерить, но боль придет со стороны доставки электронной почты. Простое создание списка провайдеров для информирования довольно тривиально, если предположить, что ваша база данных и инфраструктура не так уж ужасны.

Если это то, что вы делаете, вы просто хотите убедиться, что ваша платформа доставки электронной почты настроена разумно. Спроектируйте свою инфраструктуру так, чтобы ваша базовая система могла легко делегировать пакеты электронной почты на N подчиненных серверов, которые могут обрабатывать некоторые операции слияния и обеспечивать достаточную пропускную способность SMPT.

Если вы хотите периодически отправлять электронную почту, чтобы поставщики получали только одно электронное письмо с несколькими заданиями, вам следует подумать о вещах немного по-другому.

В этом случае рассмотрим архитектуру, основанную на сегментации списка поставщиков и репликации базы данных для обработки нагрузки чтения.

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

Вам нужно будет уточнить детали повторного сегментирования ваших провайдеров, когда вы подключите новую систему уведомлений в Интернете. Например, когда вы добавляете третью систему уведомлений, она должна обслуживать примерно 1/3 нагрузки от каждого из двух существующих.

...