Назад | Перейти на главную страницу

Как распределить доставку электронной почты между 2 и более серверами

Мы предоставляем услуги электронного маркетинга через наше онлайн-приложение. У нас около 30 клиентов. И у каждого есть свой список рассылки (от 5 до 20 тысяч писем каждый).

Что мы действительно хотим, так это распределить доставку электронной почты между 2 или более серверами. Мне было интересно, какие подходы / решения использует MailChimp, Constant Contact для предоставления отличных услуг? использовать много серверов? много IP?

Наша политика в отношении спама приостанавливает действие ЛЮБОГО пользователя / клиента, у которого 10% отказов.

У нас есть 1 сервер на Планете

Dual Xeon Quad Core, com 12 GB of RAM

Processor #1 Vendor: GenuineIntel
Processor #1 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #1 speed: 1995.080 MHz
Processor #1 cache size: 6144 KB

Processor #2 Vendor: GenuineIntel
Processor #2 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #2 speed: 1995.080 MHz
Processor #2 cache size: 6144 KB

Processor #3 Vendor: GenuineIntel
Processor #3 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #3 speed: 1995.080 MHz
Processor #3 cache size: 6144 KB

Processor #4 Vendor: GenuineIntel
Processor #4 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #4 speed: 1995.080 MHz
Processor #4 cache size: 6144 KB

Processor #5 Vendor: GenuineIntel
Processor #5 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #5 speed: 1995.080 MHz
Processor #5 cache size: 6144 KB

Processor #6 Vendor: GenuineIntel
Processor #6 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #6 speed: 1995.080 MHz
Processor #6 cache size: 6144 KB

Processor #7 Vendor: GenuineIntel
Processor #7 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #7 speed: 1995.080 MHz
Processor #7 cache size: 6144 KB

Processor #8 Vendor: GenuineIntel
Processor #8 Name: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
Processor #8 speed: 1995.080 MHz
Processor #8 cache size: 6144 KB

Когда все наши клиенты проводят кампании одновременно (это происходит до памятных дат), мы получаем слишком много отклоненных писем из-за более высокого потока доставки. Мы меняем IP-адреса исходящей почты, используя 45 IP-адресов. И контролировать / ограничивать поток на хост (например: @hotmail, @gmail) с каждого IP-адреса.

Наш подход

  1. Наше приложение доставляет 300 писем на @ hotmail.com в 14:00.
  2. Приложение блокирует доставку на @ hotmail.com и начинает доставку на разные хосты, пока не поднимет ограничение на хост
  3. Приложение меняет исходящий IP-адрес почтового сервера (используя 45 разных IP-адресов) каждые 10 минут.

Я боюсь, поскольку бизнес растет и мы получаем больше клиентов, ПОТОК ПОСТАВКИ становится выше, и этот подход НЕУДАЕТ, будучи отклоненным хостами назначения.

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

Есть много вариантов реализации, но это будет зависеть от вашей конкретной среды.

Тем не менее, объем отправляемой почты не так велик для одного сервера.

В чем именно проблема?

Ваш объем недостаточен, чтобы оправдать разделение - я имею в виду, даже если все ваши 30 клиентов отправят 20000 писем одновременно, это не ТАК много - достаточно для ОДНОГО мощного сервера (и я не имею в виду сверхмощный - просто возьми несколько дисков и сформируй рейд за почтовую катушку).

Вы могли бы использовать несколько отправляющих серверов для постановки в очередь. Блок IP-адресов для всех почтовых серверов. Либо с помощью чего-то вроде MS Exchange для отправки (обмен отлично подходит для автоматического обслуживания серверных ферм), либо с помощью какого-либо механизма для кластеризации электронных писем между серверами (так, чтобы письма из одного домена оказывались на одном сервере - просто потому, что сервер затем может отправлять несколько писем в одном TCP-соединении).

Наличие нескольких интернет-провайдеров - не проблема. Не забывайте - мы говорим о слишком большом трафике для дешевой домашней ADSL линии. Как только вы получите бизнес-оценку, ваши серверы будут переведены в соответствующий центр обработки данных. Тогда время безотказной работы очень велико - для надлежащего (осторожно, некоторые действительно кажутся дешевыми). Даже если вещи упадут в день через 2-3 года, вы должны быть ДЕЙСТВИТЕЛЬНО большими или группироваться, чтобы иметь смысл. И даже тогда все может пойти очень плохо (например, Википедия недавно была закрыта в течение некоторого времени).

Основная проблема будет в том, что вам понадобятся выделенные серверы, построенные на основе спецификаций для обработки потока почты. Сетевого трафика не так уж и много. Но почтовая катушка будет плохо работать на ваших дисках. Если вы действительно получаете пики в 600 000 писем, лучше всего подходит RAID 10 из 4-8 высокоскоростных дисков (или: RAID 5 SSD). Как и во всех транзакционных системах баз данных, вашим пределом будет ввод-вывод. Я бы выбрал настраиваемую отформатированную файловую систему с нестандартным размером узла (64 КБ), позволяющую читать / записывать каждое электронное письмо на узле практически по гарантии. Обратите внимание, что это основано на использовании SPIKE - если все электронные письма не отправляются сразу, вы можете получить гораздо меньше.

Следующим шагом будет кластер серверов.