ML
Эти данные очень не желательно обрабатывать по два раза.
Так вам надо научиться их идемпотентно обрабатывать :)
Size: a a a
2021 January 31
AF
Эти данные очень не желательно обрабатывать по два раза.
Нежелательность может быть вызвана разными причнами. Например это очень долго. Или из-за этого деньги теряются. Вот от второго типа “нежелательности” нужно уходить, потому что обработать сообщение ровно один раз все равно не получится. Хотя бы из-за сбоев
AF
И тогда проблему дубликатов можно не решать 🙂
B
Он упадет и ты его потеряешь :)
В целом кстати если даже сервер перезагрузится.
То я могу на перезапуске запуржить очередь и влить туда новую пачку.
В таком случае максимум где будут дубли это те данные которые были в обработке и не успели промаркироваться. Короче очень приемлимый % потерь.
То я могу на перезапуске запуржить очередь и влить туда новую пачку.
В таком случае максимум где будут дубли это те данные которые были в обработке и не успели промаркироваться. Короче очень приемлимый % потерь.
B
Нежелательность может быть вызвана разными причнами. Например это очень долго. Или из-за этого деньги теряются. Вот от второго типа “нежелательности” нужно уходить, потому что обработать сообщение ровно один раз все равно не получится. Хотя бы из-за сбоев
Хотя в приложении решаются другие задачи. Суть очень похожа на кравлер, в котором нежелательно ходить по одним и тем же страницам иначе это может превратится в инфинити лупс.
B
В данном случае инфинити лупс не произойдет но вообщем что-то вроде
AF
я бы тоже делал эту логику избегания дублей на стороне продьюсера
B
Я думаю если очередь пуржить перед запуском сервиса, должно хорошо все быть.
AF
хотя идемпотентности консумеров, тоже можно достичь. тут уже от деталей сисемы зависит
B
Подумаю посижу, сделаю наверное на продюсере пока-что, так как сроки важнее )
B
Спасибо всем)
ML
Я думаю если очередь пуржить перед запуском сервиса, должно хорошо все быть.
Ты тем самым надеешься что и в очереди сообщений будут надежно храниться данные
AF
а не должны? я с кроликом не работал, но предполагал что он такие гарантии даёт
B
Ты тем самым надеешься что и в очереди сообщений будут надежно храниться данные
Нет я на очередь же наоборот никак не надеюсь.
Там сейчас вот так:
1. Запрос в Postgres.
2. Проверяет на уникальность(в стейте).
3. Закидывает в RabbitMQ.
4. По тику смотрит кол-во сообщений в очереди.
5. Подкидывает если их мало.
Если продюсер падает вместе со стейтом:
То на запуске он полностью пуржит всю очередь и грузит данные с постгри.
В таком случае дубликаты практически исключены.
Там сейчас вот так:
1. Запрос в Postgres.
2. Проверяет на уникальность(в стейте).
3. Закидывает в RabbitMQ.
4. По тику смотрит кол-во сообщений в очереди.
5. Подкидывает если их мало.
Если продюсер падает вместе со стейтом:
То на запуске он полностью пуржит всю очередь и грузит данные с постгри.
В таком случае дубликаты практически исключены.
B
source of truth - Postgres
B
а не должны? я с кроликом не работал, но предполагал что он такие гарантии даёт
Если кластер поднять, то нужно постараться, чтобы он упал.
B
Если на одном хосте то с ним случаются казусы. Но это уже наверное не его заслуга)
B
Там еще можно вроде сделать, снапшот чтобы он хранил на харде
AF
Там еще можно вроде сделать, снапшот чтобы он хранил на харде
Почитал документацию, в разделе про reliable delivery сказано, что бывают persistent очереди и сообщения. И для них общаны гарантии доставки.
Если этого не делать, то в варианте с дедупликацией в продьюсере могут (будут) возникать сообщения которые потеряны, но он не отправит их повторно до перезапуска.
Если этого не делать, то в варианте с дедупликацией в продьюсере могут (будут) возникать сообщения которые потеряны, но он не отправит их повторно до перезапуска.
AF
Возможно это будет нивелироваться какими-нибудь таймаутами или дедлайнами, если они там есть.