Кто-нибудь использует RabbitMQ или что подобное для межсерверных событий?
Пока разбираюсь...
Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
S>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
Есть стандартный механизм подтверждения: Consumer Acknowledgements.
Т.е. подписались на очередь, получили сообщение, обработали, подтвердили (ack), RMQ удалил сообщение.
Если ack не было, RMQ будет считать, что сообщение не доставлено и попробует доставить его снова.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
Если вы начнёте копать вглубь, то вам откроются бездны. В общем случае — всё плохо.
Здравствуйте, Shmj, Вы писали:
S>Кто-нибудь использует RabbitMQ или что подобное для межсерверных событий?
S>Пока разбираюсь...
S>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
я писал финансовый exchange на rabbitmq
1) добавляй в заголовок автоинкремент. если потеряется сообщение то желающие об этом узнают.
2) Юзай Health Check для обхода косяков с транспортом.
RD>>Если ack не было, RMQ будет считать, что сообщение не доставлено и попробует доставить его снова. S>Когда?
It depends
Если предположить, что автоматический ack у нас отключен.
И что наша конфигурация: 1 очередь -> 1 consumer (в случае потока событий это обычно так), то
1) Если ack не было, потому что отвалился канал (порвалось соединение, упал клиент), то практически сразу после переподключения.
2) Если ack/nack не было, потому что клиент тупит и не шлет его, то... никогда.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано
Зачем?
S> — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
Есть. Не посылать Ack пока обработка не завершена, и посылать Nack если при обработке произошла ошибка, требующая повторной попытки.
И, кстати, тут никакой специфики кролика нет, в ServiceBus ровно та же стратегия, только терминология другая.
Здравствуйте, VladCore, Вы писали:
VC>Здравствуйте, Shmj, Вы писали:
S>>Кто-нибудь использует RabbitMQ или что подобное для межсерверных событий?
S>>Пока разбираюсь...
S>>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
VC>я писал финансовый exchange на rabbitmq VC>1) добавляй в заголовок автоинкремент. если потеряется сообщение то желающие об этом узнают. VC>2) Юзай Health Check для обхода косяков с транспортом.
amqp-heartbit + tcp-keepalive — не решают проблему транспорта?
Здравствуйте, Sazon, Вы писали:
S>>>Кто-нибудь использует RabbitMQ или что подобное для межсерверных событий?
S>>>Пока разбираюсь...
S>>>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
VC>>я писал финансовый exchange на rabbitmq VC>>1) добавляй в заголовок автоинкремент. если потеряется сообщение то желающие об этом узнают. VC>>2) Юзай Health Check для обхода косяков с транспортом.
S>amqp-heartbit + tcp-keepalive — не решают проблему транспорта?
хз. та биржа с которой я имел дело, давала так называемый application level heartbeat. встроенным не пользовались
S>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
Может упасть всё и везде надо подложить соломку.
Во-первых, кластер. Как минимум три ноды.
Надо включать confirmation на отправке, чтобы клиент был уверен, что брокер принял сообщение.
Надо делать mirrored очереди, чтобы при потере ноды сообщения остались.
Надо включать durable для очередей И для сообщений чтобы они пережили рестарт брокера 🤦♂️
Надо включать lazy чтобы сообщения не оставались в памяти, иначе при внезапном отключении вы потеряете сообщения, по которым получили confirmation ack.
Надо делать обработку deadletter'ов.
Надо прописать alternate у exchange и мониторить очередь с ним, чтобы отлавливать мусор.
Крайне желательно использовать push модель, они сделали медленный вариант pull модели, поэтому остаётся только push.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, agos, Вы писали:
A>>Может упасть всё и везде надо подложить соломку.
НС>Точно? Всегда? Вне зависимости от требований?
Ок, ок, если можно терять, то не везде стелить соломку
Здравствуйте, Shmj, Вы писали:
S>Кто-нибудь использует RabbitMQ или что подобное для межсерверных событий?
S>Пока разбираюсь...
S>Вопрос такой. Допустим, сгенерено событие, мы его отловили и начали обработку. Если перед обработкой отметить что событие уже обработано — то есть риск так и не завершить обработку. Какой-то там стандартный механизм есть — кто сталкивался?
оффтоп. используй redis гугли reliable queue pattern. использую в проектах с сотнями тыс сообщений в час, один инстанс редиса тянет, годами никаких проблем. кафками и геарманами наелся.
опа опа мы воюем с нато
любит хавать этот кал
путинская вата
Здравствуйте, agos, Вы писали:
НС>>Точно? Всегда? Вне зависимости от требований? A>Ок, ок, если можно терять, то не везде стелить соломку
Это вообще не бинарная величиа можно/нельзя. SLA выражается числом. И если SLA SaaS очереди, к примеру, 99%, а требуемый SLA сервиса — 95, то рвать попу на британский флаг совсем не обязательно.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Слава, Вы писали:
С>>Если вы начнёте копать вглубь, то вам откроются бездны. В общем случае — всё плохо.
S>А подробнее?
Если подробюнее то есть понятия delivery guarantee, если мы говорим о очередях то их две:
1. at most once
2. at least once
первое — вы получите одно и то же сообщение максимум раз, достигается посылкой ACK сразу после принятия сообщения и до егшо обработки. Соответственно если обработка сообщения свалилась, например потому что доступ к базе данных пропал то сообщение потеряно.
второе — ACK посылается после того как сообщение обработано, но есть риск в том что послать ACK вы не сможете (упала сеть, машина итп), соответственно есть риск получить одно и то же сообщение дважды и код должен это учитывать.
Соответственно, для приложенияй которым данные более менее важны всегда используется вариант 2 и код всегда должен писаться (но на это часто забивают) так что бы учитывать что любое сообщение может прийти несколько раз.
Если хочется exactly once/effectively once то стоит смотреть в сторону систем распределённого лога, Apache Kafka, Apache Pulsar
