Как организовать работу оповещений на сервисе?

Question

[twopizza]

Есть необходимость в зависимости от состояний объектов отсылать пользователю оповещения.
Сейчас есть cron скрипт, который проверяет состояния объектов и отсылает нужные оповещения. При этом после отправки он устанавливает флаг у объекта, что оповещение данного типа отправлено. Думаю это не очень красиво. Как можно решить задачу иначе? Может есть какой-то паттерн? На ум приходит только создание отдельной общей таблицы со всеми уведомлениями или отдельной под каждую сущьность.

Answer 1

[Сергей Протько]

Думаю это не очень красиво.

1) при изменении состояния объекта кидайте ивент об этом или явно вызывайте нотификатор
2) нотификатор добавляет в очередь задачу (beanstalkd, rabbitmq, etc)
3) очередь ответственна за отслеживание статуса задачи
4) воркеры берут задачи из очереди и собственно занимаются отправкой.

Comments

[twopizza]

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

[Сергей Протько]

twopizza: зависит от задачи. Например нам важно отслеживать статус (прочитал чувак оповещение или нет), но если мы говорим о email-ах то в этом уже нет смысла так как... если он доставлен отслеживанием этого статуса будет заниматься email клиент.

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

[twopizza]

Меня интересует в т.ч. и внутренние, со статусами. Как в таком случае оптимально их хранить?

[Сергей Протько]

twopizza: ну мол после того как воркер успешно доставил сообщение добавлять в базу данных в лог информацию об этом. Ну или держать отдельную таблицу для нотификаций и менять им статус (но как по мне это странно). Словом... cron не нужен. нужны очереди. А все остальное зависит от деталей задачи.

[twopizza]

Ок, про cron понял, спасибо. Тогда получается что статусы придется определять по логам, тоже ведь не менее странно :)

[Сергей Протько]

twopizza: вы объясните зачем вам их вообще "определять"? Статус задачи хранится в очереди. Как только задача получает статус done она вылетает из очереди.

[twopizza]

Я не про статусы задач, а про статусы оповещений

[Сергей Протько]

twopizza: оповещение = задача.

[Сергей Протько]

twopizza: ну мол доставлено/в ожидании.

Answer 2

[xmoonlight]

Это триггер состояний.
Сущности: оповещение, канал (оповещения), статус доставки, статус обработки, время повторного действия, кол-во повторов
По триггеру создаётся экземпляр сущности "оповещение" и присваивается "канал".
Далее, канальный воркер (каждый воркер для своего канала и они синхронны):
1. забирает пакет оповещений длиной N-штук и проставляет статус: sending
2. пытается отправить.
3. когда всё обработано - проставляет статус обработки, согласно обработке (success,fail,retry + sendAt:timestamp + retryCount++ - сам добавляет в очередь)
4. Когда все отправлено - переходит к выборке следующего пакета данных.
Если есть возможность проверки доставки - поле изменяется с помощью входящего события о доставке (за это отвечает протокол канала доставки).
5. После успешной обработки оповещения (статусы все success), можно или просто "убить" оповещение из очереди или поместить в архивную таблицу оповещений (если этого требует бизнес-процесс).