Как ограничить очередь на выполнение только 200 задач в час?

Question

[Webspec]

Всем привет!

Сделал отправку E-mail уведомлений пользователей через асинхронное выполнение задач (компонент Message фреймворка).

Почта отправляется через smtp сервер mail.ru, который имеет примерное ограничение на отправку писем в 200 штук в час.

Как мне ограничить выполнение очереди под эти лимиты? Может есть какие-либо настройки под это дело?

Answer 1

[Максим]

Подключите нормальный почтовик без ограничений и не выдумывайте.

Уведомления, чаще всего, должны быть практически синхронными иначе в некоторых из них теряется смысл. Используя ограничение 200 сообщений вы лишаете возможности человека получать актуальные уведомления при превышении лимита. Рано или поздно этот лимит будет много раз перекрыт и ваши уведомления никогда не дойдут до пользователя.

Кроме того, через почтовик могут быть и другие важные сообщения, например, восстановления пароля. Имея лимит — Ваши пользователи могут оказаться в той ситуации когда восстановить пароль не получится. И это будет не самым хорошим впечатлением отвалку системе, а так же не нужными сообщениями в службе поддержке.

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

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

Comments

[Flying]

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

Хотя, как я указал в своём ответе, я согласен с вашим ответом, однако этот момент предложил бы поправить, поскольку "позже" и "никогда" - это, всё-таки, разные вещи.

[Webspec]

Спасибо! Пойду этим путём.

[Максим]

Flying,

Другими словами, если в час будет сгенерировано 300 уведомлений, то 200 будут отправлены в первый час, а 100 - во второй, но отправлены будут все 300.

1. А что у вас система остановит свою работу на час?) Нет. Она за этот час ещё может дать ещё 300 уведомлений. Тогда Вы за два часа отправите уже 400 сообщений, а 200 будут опять висеть. И это число может нарастать.
2. Вы учитываете лимиты только тех сообщений, которые идут через Messenger, но ведь сообщения могут отправлены напрямую. Тогда как вы будете учитывать сколько у вас ещё осталось сообщений в час? Тогда вам придется делать таблицу, где будете учитывать сколько сообщений было отправлено через этот почтовик. Чтобы не нарушить лимиты
3. 200 сообщений в уведомления закладывать нельзя, потому что есть более важные сообщения, как я уже написал. Поэтому этот лимит придется понизить искусственно до 100 чтобы был запас для важных сообщений.

И это я назвал лишь самые основные моменты. Тут ещё много чего можно найти)

Конечно, можно «накостылить» и придумать массу схем. Но решается всё очень просто — нормальный почтовик. При росте сообщений Вы в это упретесь. Особенно при организации рассылок/подписок/уведомлений.

Подключение почтовиков типа mail имеет смысл только тогда, когда вы организовываете работу в них через IMAP или у вас реально мало сообщений, при котором вы никогда не достигните лимита что бы не произошло.

[Максим]

Flying, Webspec, не помню как у маил, но нарушая лимиты почтовика на хостинге могут вообще заблокировать вашу услугу. Поэтому это того не стоит)

[Flying]

Максим, Повторюсь ещё раз что я с вами полностью согласен :)

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

[Максим]

Flying, да) Это я привёл самый крайний вариант. Когда-то, конечно, они могут и дойти. Всё зависит от частоты сообщений. Ночью, например, вряд ли есть какие-то сообщения. Но тут есть у майла ещё один лимит, о котором автор не говорит. 1000 сообщений в сутки) А это ещё негативней делает всю картину. Днём вам нужно 5 часов по 200 сообщений и ночи ждать не надо) Поэтому я сразу привёл пример, с которым сообщения никогда могут не дойти.

Везде индивидуально. Надо оценивать много чего, но это вообще никак того не стоит) Покупаешь нормальный сервер где есть почтовик без ограничений и думать не надо.

[Максим]

Flying, не обижайся) Я в целом понимаю, что это возможно. И вижу, что вроде бы сам понимаешь и попытался предложить какой-то другой вариант решения. Но тут важно чтобы ты и сам понял и другие. Я изначально ответил коротко и понятно, но когда ты включил свой ответ всё поменялось и я попытался обосновать почему не надо так как предложил ты. Со стороны кода это влечёт большие последствия, особенно, если нет понимания. Поэтому, если ты даёшь такое решение, то должен дать предостережения. Чтобы автор мог понять, какой вариант выбрать и какие последствия могут быть. Если идти твоим путём появится много лишнего кода, много лишних правил, условий и т.д. Моё же решение вообще никак не трогает код, соотвественно не будет костылей. Идя твоим путём можно только понимая всю картину. Автору, возможно, не понять. Поэтому ответ был коротким, остальное описывал чтобы ты понял к чему это может привести.

[Flying]

Максим, Обижаться на комментарии в интернете - довольно странное дело.

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

Банальный пример: сервис в защищённом периметре + админ-параноик, закрутивший гайки. Сейчас этот сценарий, конечно, маловероятен, но раньше с таким вполне можно было встретиться.

В конечном итоге вся информация, которой мы располагаем, давая ответы - это содержимое вопроса, там далеко не всегда есть вся информация, приходится строить предположения.

Ну а без понимания вообще можно при любых условиях нажить себе проблем. Сколько уже на хабре было статей вида "как мы потеряли NNNNN$ за полчаса"....

[Максим]

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

Я бы ваш вариант использовал в самую последнюю очередь. Когда ничего нельзя решить и только это остаётся) Это как с оптимизацией. Многие начинают сразу всё кэшировать, хотя во многих случаях можно переписать запросы расставить индексы и т.д.

Не будем углубляться. Мы друг друга поняли и автор нашел решение) Спасибо за диалог!)

Answer 2

[Flying]

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

На самом деле, поскольку вы используете Messenger - то вы уже весьма близки к цели, поскольку Messenger перезапускает обработку сообщения в случае неполной обработки. Просто настройте retry_strategy под свои нужды и оно будет работать. Надо только мониторить failed messages.

Также, если вы можете позволить себе использовать Symfony 5.2 - то в этой версии появился отдельный компонент RateLimiter, который специально предназначен для решения именно таких задач. Сделайте Messenger middleware для того чтобы помечать сообщения на отправку только если это разрешает RateLimiter, а для остальных бросайте RecoverableMessageHandlingException чтобы отменить обработку. Но, опять же, не забудьте про настройки retry strategy чтобы это не приводило к потерянным сообщениям.

Comments

[Максим]

Это не тот случай когда это нужно использовать. Как дополнительные познания - хорошо расписали. Как решение — не подходит. Разве что временный костыль. Дополнил в свой ответ обоснование.

[Максим Федоров]

Максим, это ответ технический
Ваш ответ (верный конечно) менеджерский

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

[Максим]

Максим Федоров,

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

вот такой вариант уже лучше обосновывает) Но в данном случае в этом нет необходимости, как и нет необходимости искать возможности вписаться в эти лимиты mail почтовика. Это того не стоит.

[Максим Федоров]

Максим, и все же — стоит или нет — менеджерский ответ
Тут ответ же технический и соответствует и тегу и описанию

[Максим]

Максим Федоров, спорить не буду)