Простой способ организации очереди e-mail с помощью Zend_Mail

[@voff]

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

[@Nilov_A]

Поясните пожалуйста.

[@voff]

Я бы использовал полиморфизм, работая с нужным потомком абстрактного класса, в зависимости от типа БД, кто-то другой, делал бы запросы средствами ZF, но использование родных ф-ций php для работы с базой — ограничит ваше приложение только базой MySql. Как я уже сказал для примера — норм, в реальных приложениях — слабое место. Учитывая, что остальной код вполне себе ООП

[@gen]

Слабое место тут как раз не столько в использовании pure php, сколько в том, что нет никакой обработки критических ситуаций. Например, как уже спрашивал markPnk, что будет, если отправка письма вдруг заняла больше минуты? Или что будет, если скрипт умрёт после того как mail() отработала, но запись ещё не удалилась из базы? Или письмо было отклонено почтовым сервером?

[@pav]

А почему сам файл который по крону пускается на plain php? Помоему было бы логичнее что же ZF использовать. Или это просто пример?

[@Nilov_A]

Вы правы, это просто пример. К тому же данное решение не обязательно должно работать на зенде. Zend_Mail можно «прикрутить» к любому фреймворку или самопису. У меня, например, подобное решение работает на Yii и на самописном фреймворке.

[@zerkms]

А почему вы почту не отправляете Zend_Mail и с базой не работаете классами зенда? На чём именно вы пытались сэкономить в этом случае?

Любой MTA, тот же сендмейл, лучше управится с очередью писем, чем `if ($isSent) {` + mail()

[@Nilov_A]

«А почему вы почту не отправляете Zend_Mail » — потому, что данные записанные в БД уже подготовлены Zend_Mail и обрабатывать их повторно абсолютно бессмысленно.

«На чём именно вы пытались сэкономить в этом случае?» — не вижу смысла подключать фреймворк, если требуется сделать цикл по базе и вызвать функцию mail(). Данный файл вызывается с периодичностью раз в минуту, поэтому, чем меньше он будет потреблять ресурсов за раз, тем лучше.

[@zerkms]

Эм, кого обрабатывать? Как подготовлены?

А вы пробовали измерять разницу? Подключаемые файлы, которые, кстати говоря, будут закешированы оптимизатором, будут загружаться, ну, к примеру 0.01. А сколько вы времени потратили, используя pure php, а не ZF? ;-)

Вам теперь нужно поддерживать 2 кодовых базы, в то время как в случае с единым — вы просто могли re-use те же самые классы. Не?

На том ли вы экономите?

[@Nilov_A]

«А вы пробовали измерять разницу?» — зачем? я могу поспорить, что код на нативном php будет работать быстрее и потреблять меньше памяти.

«Вам теперь нужно поддерживать 2 кодовых базы, в то время как в случае с единым — вы просто могли re-use те же самые классы. Не?» — Блин, код элементарный, в десять строчек! Реализация таких мелочей не требует мощи фрейморка.

[@zerkms]

> зачем? я могу поспорить, что код на нативном php будет работать быстрее и потреблять меньше памяти.

Процессорное время стоит дешевле работы программиста. Зачем вы в принципе тогда пользуетесь фреймворками?
Почему там, где это действительно нужно (фронтенд — куча запросов) вы не экономите на спичках, а в бэкграундной задаче, которая (просто невероятно!) запускается раз в минуту — считаете это экономией? Всё таки определитесь, вам важен или качественный поддерживаемый код, тогда используем фреймворк везде и пишем нормальный код с нормальными логгерами, а не echo без перевода строки непонятно куда, или экономим спички везде и выкидываем фреймворк совсем.

[@zerkms]

> Блин, код элементарный, в десять строчек

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

[@ezj]

Разве оптимизатор будет работать в консольном режиме? (я надеюсь вы скрипты в кроне запускаете именно в консольном режиме, а не дергаете их каким нибудь wget`ом)

[@zerkms]

Кстати отличный вопрос. Почему-то всегда думал, что он будет работать и там, но только после вашего коммента задумался, что хранить закешированный опкод ему негде (точнее говоря — некому). Так что да, мой косяк.

[@VolCh]

Если демонизировать, то будет :)

[@zerkms]

`attempts = '. $row['attempts'] + 1. ' `

==

`attempts = attempts + 1`

[@dfuse]

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

[@Nilov_A]

Дельное замечание. Можно добавить в таблицу поле «in_process» и перед mail() выполнять апдейт соответствующей строки: mysql_query('UPDATE email_queue SET in_process = 1 WHERE id = '. $row['id']); И получать массив писем из БД с учётом этого значения (in_process = 0).

[@Nilov_A]

Внёс соответствующие изменения в статью.

[@gen]

P.S. В примерах я использовал Zend Framework 2.0, которая на момент написания статьи ещё находится на стадии бета-тестирования. Если вы работаете с версией 1.*, то нужно переименовать классы ...

Вы уверены что этот код работает в zf2? Что-то я не нахожу public function _sendMail() {… }
в Zend/Mail/Transport/Sendmail.php.

[@Nilov_A]

Да, уверен, см. \Zend\Mail\Transport\Sendmail либо \Zend\Mail\AbstractTransport

[@gen]

Тогда наверное нужно уточнить, что ваш код для версии <= 2.0.0beta-1, которая вышла почти год назад. Не пойму, статья была написана в тоже время? Потому как с beta-2 уже нет _sendMail(), a 3 дня назад уже вышел rc7.

[@Nilov_A]

Да, вы правы. Видимо, давно не обновлял библиотеку. Код актуален для версии 1.*. Я внесу исправления в статью.

[@AlexPres]

С интересом прочитал, т.к. делал что-то похожее.

1. Вместо in_process было введено поле status типа ENUM('new', 'in progress', 'sent', 'failed') + поле error_message, куда записывается текст ошибки в случае status=failed. Очень удобно потом в PhpMyAdmin клацать «показать уникальные значения» и смотреть сколько сообщений каждого типа.

2. У вас никогда вот тут код не ломался?

$db->beginTransaction()

Ситуация: у вас открылась транзакция, апдейт завалился — залогировали, сделали continue, опять вызовется $db->beginTransaction() и будет исключительная ситуация.