Порядок работы Почтовой Выхухоли

Порядок работы Почтовой Выхухоли.

Имея верно установленный скрипт на хосте, не выдающий никаких эрроров, и зная, как правильно конфигурировать задание Крону, и что в нём писать, перед созданием реальных служб Вам необходимо чётко себе представлять, как именно будет происходить рассылка. То есть что случается при обращении крона в URL cron.php

А происходит в точности вот что:

1. При запуске Кроном рассыльщика (cron.php) тот в первую очередь проверяет, включен ли скрипт. Если через админку он установлен в режим отладки, то есть выключен, никакие письма, естественно, посылаться не могут, да и не должны.

   Чтобы админ знал причину бездеятельности скрипта, рассыльщиком на админский емайл не чаще одного раза в час будет засылаться письмо совершенно прозрачного содержания:

   Subject: Script is off

   Не могу приступить к рассылке писем.
   Скрипт стоит в режиме отладки.
   Зайдите в админку и переключите скрипт в рабочий режим.

   
   

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

   Если такие рассылки обнаружены (не важно, одна или несколько), то рассыльщик проверяет, наступило ли время выхода хоть одной из них. Ибо время выхода рассылки может быть задано произвольно, и до наступления оного рассылка тихонько сидит в засаде, и ждёт своего звёздного часа.

   Если выясняется, что этот час уже настал, рассыльщик производит проверку, присутствует ли на сервере код письма, подлежащего рассылке, а также список подписчиков, сформированный из одной или нескольких служб. И если вдруг окажется, что слать нечего или некому (какой-то из нужных файлов потерян по всё равно какой причине), это задание на рассылку просто уничтожается как неадекватное.

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

   Новостийная рассылка продолжится с этого места при следующем запуске рассыльщика.

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

   Кроме того, на админский email будет отослано письмо с рапортом о завершившейся новостийной рассылке, причём на русском языке. Его смысл, суть и происхождения должны быть понятны без всяких объяснений.

   
   

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

   Однако для работы с серийными рассылками необходимо, чтобы соответствующая служба была включена.

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

   Subject: all dispatchs is off

   Все серийные службы находятся в выключенном состоянии.

   
   

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

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

   Только что включенная служба автоматически ставится в начало очереди, если она была отключена длительное время, либо включается впервые. И не меняет своего положения в очереди, если Вы отключили службу, и тут же включили её обратно.

   То есть никакого способа заставить рассыльщика работать с конкретной службой нет.
   Все службы обслуживаются рассыльщиком на равных правах, паритетно.

   
   

5. Сколько писем пошлёт рассыльщик для выбранной службы серийных рассылок?
   Не более, чем указано в настройке "Серийные службы, слать писем за раз"
   Однако далее есть варианты.

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

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

   
   

6. Разговор про таймаут тут зашёл не случайно.

   Если при протекании процессов, описанных в пунктах 2 и 5, выяснится, что время работы скрипта почти исчерпано, рассыльщик прекратит свою деятельность, даже не выработав лимит на отправку писем.

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

   Это означает, что если не предпринимать никаких специальных мер, то в следующем цикле работы он не вспомнит, чем занимался, и начнёт рассылку писем тем же юзерам. И, будучи снова отрубленным хостером, в следующем цикле повторит всё то же самое, тупо зациклившись.

   Чтобы такого не проистекало, рассыльщик детектирует каждый случай его отключения хостером, при этом самоблокируясь, и шлёт на админский email соответствующие предупреждения о нештатной ситуации:

   Subject: script is down by hoster

   Работа скрипта ранее была прервана хостером.
   Для возобновления рассылки писем необходимо:
   - зайти в админку;
   - переключить скрипт в режим отладки:
   - вернуть его обратно, в рабочий режим.
   Это выведет скрипт из состояния блокировки.

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

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

   
   

7. Если же таймаут выставлен верно, и ничто не мешает сендеру работать штатным образом, то, после отсылки пачки писем в рамках серийной рассылки, скрипт также проверяет, не имеется ли в базе этой службы подписчиков, которые ещё не верифицировали свой email в соответствии с общепринятой процедурой подписки на рассылки.

   При нахождении таких подписчиков им отсылается напоминание, эквивалентное письму с просьбой подтвердить подписку. Период отсылки напоминаний и их число регулируется двумя параметрами всё той же таблички основных настроек скрипта, которые к этому времени Вы должны уже знать наизусть.

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

   На этом же этапе удаляются подписчики службы, уже получившие все письма рассылки, если настройками этой службы велено поступать именно так (с такими настройками Вы пересечётесь чуть позднее).

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

   
   

8. Вот теперь уже весь цикл функционирования сендера полностью завершён, и он снимает блокировку с базы данных той службы, с которой работал в этом цикле.

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

   Естественно, такой вариант потенциально катастрофичен, так как может привести к краху базы и потере всех подписчиков. И, если Вы получаете от сендера письма вида:

   Subject: not can launch the sender
   Невозможно инициировать рассылку.
   Есть вероятность, что слетели права доступа.
   Попытка переименования файлов оказалась безрезультатной.
   Вполне возможно, что Вы натравливаете НЕСКОЛЬКО кронов на одну базу одновременно.

   
   
   Subject: not can terminate sender
   Никак не получается корректно завершить работу сендера.
   Сендер остановлен.

   то следует срочно проверить перечень заданий Крону.

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

   Для Вас не должно быть сюрпризом, что действия конкурентов и идиотов сложно согласуются со здравым смыслом, и обычно деструктивны. Ими легко может быть организована DoS атака на самое уязвимое приложение, как раз с целью чего-нибудь поломать. Ввиду чего Вы просто обязаны переименовать файл cron.php во что-нибудь очень сложное (с сохранением расширения файла), и адресовать Крон к URL-у этого файла со сложным именем. Чтобы конкуренты и идиоты не смогли догадаться, куда именно направлять DoS атаку.