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

•  Локальный cron вызывает локальный скрипт
•  Скрипт заходи на отдельный MySQL сервер и получает от туда данные
•  Скрипт постепенно скармливает письма в Amazon SES/

В идеальных условиях скрипт работает как часы, но есть проблема, связанные с инфраструктурой работы серверов:
Production может состоять из несколько серверов-клонов. Сервера клонируются полностью: cron, скрипты, конфиги и т.п.. В связи с этим, каждую минуту на каждом сервере локальный cron запускает локальный скрипт, получает общие данные и начинает ими пичкать SES. В результате синхронной работы мы:

•  На каждый email уходит столько писем, сколько у нас серверов.
•  Нагружаем SES выше нормы (а скрипт как раз и балансирует нагрузку)

Первоначально была идея блокировать таблицу. Я предполагал, что один из скриптов опередит другие на людю секунды и заблокирует таблицу, не давая другим работать с ней. Но на практике оказалось, что другие скрипты будут просто ждать своей очереди и отработаются, когда будет снаята блокировку.
Есть у кого-нибудь идеи, как обойти эти проблемы?

Может вовсе не крон юзать, а например, php-daemon? Тогда не должно вызываеться несколько экземпляров скриптов...

мде.
Гениально, что я могу сказать...
Советую еще раз перечитать вопрос.




Есть два варианта.
1. помечать в БД мыло как уже обработанное.
Минус в том, что можно поиметь тормоза связанные с БД

2. каждому серверу присвоить свои номер и скрипты на сервере должны брать почтовые адреса только если некая f(ID) будет выдавать этот номер.

Т.е. например 
f = ID % 10
Тогда нам нужно 10 серверов, где 1й будет обрабатывать адреса с ID = 1,11,21,31 ...
7й адреса с ID = 7,17,27 ...

Минус в том, что при масштабировании нужно будет менять код на многих серверах сразу.

Добавлено через 1 минуту и 21 секунду
нагрузка же балансируется банальным разнесением задач крона по времени на каждой машине.
на 1ной стартует в 6ть утра
на 2й в 8 утра и т.д.

Добавлено через 4 минуты и 6 секунд
Кстати, вопрос масштабирования серверов легко решается двумя путями:
или автоматическим деплоем (который подстраивает конфиги скриптов)
или немного более усложненным алгоритмом определения номера сервера (например опираясь на какую-нибудь аппаратную часть) чтобы не зависеть от конфига

Не прокатит. Все сервера получают доступ к записи почти одновременно - разница миллисекунды. Пока самый быстрый скрипт дойдет до инструкции апдейта записи, остальные уже успеют ее прочитать.



Вы сами отмели этот вариант. Погрязать в "технических долгах" нет желания.

У нас на проекте есть аналогичный функционал, мы решаем этот вопрос именно так:

Пока в голове крутиться решение - поднять микро-сервер и вынести код рассылки туда, чтоб он функционировал как отдельное приложение, работающие с общей базой. Но я бы хотел найти более быстрое ришение.

Добавлено через 9 минут и 55 секунд

Окей. Так мы решим проблему дублирования почты, но весь парк серверов по прежнему получит свою порцию писем и разом примется за их рассылку. В то время, как скорость рассылки одного сервера расчитана на полную загрузку Amazon SES. Если серверов будет несколько - Amazon SES не выдержит нагрузки (если быть точным, просто откажет нам в столь стремительной рассылке)

Транзакции вам на что?

Добавлено через 2 минуты и 2 секунды

Я его не отмел. 

Просто для него нужна система автоматического деплоя или, как я уже писал выше, немного усложненный алгоритм, который будет самостоятельно получать уникальный ИД сервера.

Добавлено через 4 минуты и 45 секунд

Если не в состоянии реализовать балансировку отправки по серверам, то ставьте все письма в очередь.
И отправляйте из нее уже с одной машины, контролируя скорость отправки.

Вообще я не понимаю сути вопроса. Если даже один сервер загружает ваш Амазон под завязку, то много серверов вам зачем?