Comments 14
Ну зачем, зачем снова этот АО «Велосипедстрой»?! Тем более на Хабре, с которого все будут копипастить. Есть же Mailchimp, Mandrill или Amazon SES (для любителей хардкора). 200 000 — это еще не тот объём, при котором стоит изобретать свою поделку. А через указанные сервисы он вообще разлетается меньше, чем за час и даёт статистику, насколько злостным спаммером вы являетесь.
У нас используется персонализированная рассылка, поэтому каждое сообщение рендерится отдельно. Следовательно, подобные сервисы нам не подходят. А еще это бесплатно и, как было указано в статье, просто и без излишеств.
Mandrill бы вам подошёл. Но для каждого пользователя пришлось бы точно так же посылать отдальный email через beanstalkd. Mandrill бы взял на себя только обязанности отслеживать открытие писем, обрабатывать unsubscribe из списка рассылки.
Mailchimp же полностью занимается рассылкой, но он совсем не гибкий для некоторых целей. Когда-то использовал ту же схему. Mailchimp: неудача. Mandrill: через job-сервер. SES наверное, больше похож на Mandril.
Mailchimp же полностью занимается рассылкой, но он совсем не гибкий для некоторых целей. Когда-то использовал ту же схему. Mailchimp: неудача. Mandrill: через job-сервер. SES наверное, больше похож на Mandril.
Что будете делать если воркер случайно упадёт, из-за бага в коде/сетевых проблем, или сбоя сервера?
Попытается ли beanstalkd повторить это задание? Как же быть если в одном задании 100 пользователей?
Или такие сценарии не рассматриваются (вместо этого код воркера должен быть суперстабильным)?
Неужели он на столько тормознут? Работал с другими системами, никаких проблем с 200к заданий не наблюдалось…
Попытается ли beanstalkd повторить это задание? Как же быть если в одном задании 100 пользователей?
Или такие сценарии не рассматриваются (вместо этого код воркера должен быть суперстабильным)?
Методом подбора мы пришли к цифре 100 пользователей на job.
Неужели он на столько тормознут? Работал с другими системами, никаких проблем с 200к заданий не наблюдалось…
За инфу про Mandrill спасибо, будем думать насчет него в будущем.
При падении воркера он перезапустится автоматически, если будет падать систематически из-за ошибки, мы увидим это через лог — туда отправляется весь его вывод.
Если ошибка произойдет в процессе выполнения job'а, это не критично, т.к. для каждого пользователя непосредственно перед отправкой проверяется, не получил ли он уже такое сообщение (еще одна забота функции email_messages_model->can_send).
В самом худшем сценарии job останется «висеть» в статусе «reserved» — в этом случае beanstalkd будет держать ее там до истечения таймаута, а затем вернет в статус «ready». До тех пор воркер, который получил этот job, не сможет получать новые job'ы из очереди.
При падении воркера он перезапустится автоматически, если будет падать систематически из-за ошибки, мы увидим это через лог — туда отправляется весь его вывод.
Если ошибка произойдет в процессе выполнения job'а, это не критично, т.к. для каждого пользователя непосредственно перед отправкой проверяется, не получил ли он уже такое сообщение (еще одна забота функции email_messages_model->can_send).
В самом худшем сценарии job останется «висеть» в статусе «reserved» — в этом случае beanstalkd будет держать ее там до истечения таймаута, а затем вернет в статус «ready». До тех пор воркер, который получил этот job, не сможет получать новые job'ы из очереди.
С mandrill на самом деле не все так радужно, как это описывается.
Если вы не работали с базой адресов и не чистили ее несуществующих ящиков, тогда после первой же рассылки рискуете получить high bounce rate с лимитом на отправку 20-30 писем в час и непонятной перспективой убрать этот лимит.
Из-за таких вот фокусов сами уходим от них на другой сервис.
Если вы не работали с базой адресов и не чистили ее несуществующих ящиков, тогда после первой же рассылки рискуете получить high bounce rate с лимитом на отправку 20-30 писем в час и непонятной перспективой убрать этот лимит.
Из-за таких вот фокусов сами уходим от них на другой сервис.
Что за сервис, если не секрет?
Это не проблема, а дополнительная работа. Мы в первую очередь сами хотели не спамить.
Гораздо хуже было бы настроить свой сервер, иметь баги в unsubscribe механизме, отсылать почту на несуществующие адреса (если бы сами за этим следить не могли), в итоге бы письма оказывались в спаме, и это было бы гораздо сложнее пофиксить.
Лимит, на сколько я помню, с непонятной перспективой, растёт постепенно, если что случится — возвращается в норму некоторое время, но суппорт отказывается разглашать точный алгоритм. Но у нас с ним проблем не было, кроме тех что мы пытались выяснить у саппорта алгоритм его работы.
Гораздо хуже было бы настроить свой сервер, иметь баги в unsubscribe механизме, отсылать почту на несуществующие адреса (если бы сами за этим следить не могли), в итоге бы письма оказывались в спаме, и это было бы гораздо сложнее пофиксить.
Лимит, на сколько я помню, с непонятной перспективой, растёт постепенно, если что случится — возвращается в норму некоторое время, но суппорт отказывается разглашать точный алгоритм. Но у нас с ним проблем не было, кроме тех что мы пытались выяснить у саппорта алгоритм его работы.
Реализация механизма unsubscribe, opens/clicks не сильно сложнее интеграции с системой и разработки webhook/callback сервиса на вашей стороне.
Для того, чтобы обеспечить своим клиентам сервис достаточного уровня качества желательно знать и расчитывать риски по основным направлениям и интеграциям, чтобы потом для вас не оказалось неожиданностью факт того, что рассылка прекратилась из-за секретных алгоритмов сервиса и повлиять на решение этой проблемы вы никак не сможете.
Более того, этот момент практически нигде у таких сервисов не прописан. Перспективы радужные. Но в какой-то прекрасный момент вы получаете такой вот сюрприз, как это и произошло в нашем случае.
Для того, чтобы обеспечить своим клиентам сервис достаточного уровня качества желательно знать и расчитывать риски по основным направлениям и интеграциям, чтобы потом для вас не оказалось неожиданностью факт того, что рассылка прекратилась из-за секретных алгоритмов сервиса и повлиять на решение этой проблемы вы никак не сможете.
Более того, этот момент практически нигде у таких сервисов не прописан. Перспективы радужные. Но в какой-то прекрасный момент вы получаете такой вот сюрприз, как это и произошло в нашем случае.
Реализация механизма unsubscribe, opens/clicks не сильно сложнее интеграции с системой и разработки webhook/callback сервиса на вашей стороне.
Вот здесь не слоглашусь. Будет сложнее (но, кстати без web callback обошлись — там было какре-то другое api)
потом для вас не оказалось неожиданностью факт того, что рассылка прекратилась из-за секретных алгоритмов сервиса и повлиять на решение этой проблемы вы никак не сможете
На самом деле, как я понял выбор невелик: факап (не те email, повторные email, спам итд) vs прекратившаяся рассылка.
Ну и вообще, в нашем случае прерванная рассылка — это было не очень критична. Не одними рассылками компания жила.
Простите, а в чем сложности добавить в письмо ссылку на отписку
Сделать обработчик на сайте и при вызове ссылки отписывать человека. Это действительно настолько сложно?
В вашем случае остановка рассылки возможно и не критичная вещь, однако другие к таким вещам могут относиться достаточно трепетно.
http://вашсайт/unsubscribe?msg_id=xxxxxxxxxx
Сделать обработчик на сайте и при вызове ссылки отписывать человека. Это действительно настолько сложно?
В вашем случае остановка рассылки возможно и не критичная вещь, однако другие к таким вещам могут относиться достаточно трепетно.
Кроме unsubscribe, как Вы сами изначально заметили есть ещё open/clicks — создание ссылок, подсчитывающих клики, статистика в виде графиков.
Может захотеться кроме ссылки unsubscribe, иметь List-Unsubscribe, или отписывать если bounce/спам.
Очень даже может быть :) Для некоторых вообще — не послать email юзеру — катастрофа. А вот послать 10 раз одни и тот же по ошибке, тому кто уже сделал unsubscribe — мелочь.
Может захотеться кроме ссылки unsubscribe, иметь List-Unsubscribe, или отписывать если bounce/спам.
В вашем случае остановка рассылки возможно и не критичная вещь, однако другие к таким вещам могут относиться достаточно трепетно.
Очень даже может быть :) Для некоторых вообще — не послать email юзеру — катастрофа. А вот послать 10 раз одни и тот же по ошибке, тому кто уже сделал unsubscribe — мелочь.
За поддержанием работоспособности worker'a следит supervisord и если worker по каким-то причинам падает, то supervisord обязательно это заметит и поднимет его. В остальном же добавлю немного конкретики про то, как это работает. Worker'ы не поднимают SMTP соединения и не отправляют данные напрямую пользователю все происходит немного сложнее. На самом деле worker отправляет письмо с помощью sendmail'a в postfix, который в свою очередь в многопоточном режиме через SMTP отправляет все в SendGrid, откуда уже письмо попадает пользователю.
Таким образом у нас имеется возможность отслеживать различную статистику по отправленным письмам, а также отписывать тех пользователей, которые попадают в разряд bounces с помощью SendGrid API.
Таким образом у нас имеется возможность отслеживать различную статистику по отправленным письмам, а также отписывать тех пользователей, которые попадают в разряд bounces с помощью SendGrid API.
Sign up to leave a comment.
Использование сервера очередей beanstalkd для распределения нашей почтовой рассылки