ситуация, что сообщение из очереди, тригеррит отправку пушей пользователю, пуши нужно отправлять только 1 раз на 1 сообщение.
Есть 2 Дата Центра, и, в каждом ДЦ есть нода кролика и 2 ноды сервиса, гарантия доставки at least once, есть достаточно шансов, что сообщение будет отправлено несколько раз = обработано = отправлены пуши.
Я однажды решал такую проблему, и решил это с помощью блокировок в БД. Пришло сообщение(у каждого сообщения есть уникальный correlationId), я его ловлю preprocess hookом реббита(Не помню название класса), сохраняю в таблицу, где есть unique констрейнт на correlationId и отправляю в метод-листнер. Таким образом обработать сообщение может только 1 листнер, который смог сохранить сообщение в БД, остальные упадут с ошибкой ConstraintIntegrityViolation, которую мы обработаем.
Может кто знает более элегантное решение?
кажется, можно переложить эту проблему на гугл и эпл. Например, у эпла есть параметр пуша - apns-collapse-id, который должен помочь в случае дублирования одного и того же сообщения
А бд где лежит?
В одном из 2х ДЦ
а сейчас плохо работает?
Нет, тот подход, что описал я использовал на другом проекте, там всё работает ок, просто, может, кто-то решал эту проблему по-другому, было бы интересно узнать как
ну я бы не трогал, то что работает. принципиально по другому с кроликом наверное сложно решить. вместо бд можно взять распределенный сервис блокировок, консул/зукипер/etcd - но я бы их тащил только если вам дополнительно для чего-то это нужно. а если есть уже постгресс и он работает - я бы не трогал
Обсуждают сегодня