Артем Рудневский - Exactly-once в микросервисной среде

[@xQiizYx]

На 23:30 как-то сложно с промежуточной очередью, обычно для ускорения outbox сообщение отправляют просто после коммита транзакции (и если удалось - удаляют из outbox). Тогда фоновый процесс будет заниматься доотправкой только того, что не удалось отправить из-за ошибки, большинство сообщений будут отправляться сразу же (но точно также проходить через коммит в outbox).

[@timramone]

После коммита будут теряться сообщения

[@want2sleeptt]

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

[@timramone]

@@want2sleeptt понятно, тоже интересный подход!

[@AgentFire0]

@@timramone не просто интересный, а логичный, ведь он сильно оптимизирует happy path.

[@timramone]

​@@AgentFire0 ответ через год конечно смешно, но тем не менее :) не всегда это можно себе позволить, например если ты находишься в критическом пути, или если то, что должно происходиить в обработке outbox'а сильно дороже обработки исходного сообщения (и соответственно должно масштабироваться по-другому как-то)

[@denispetukhov9869]

Не совсем понятен один момент. Сначала говорится что эвентов много и rdbms не подходит под такую нагрузку. При этом далее говорится что при создании клиента его данные и эвент о создании коммитятся в рамках одной транзакции (outbox). Тогда получается что если будет много клиентов система прикурить из-за проблем масштабируемости rdbms и далее видимо придётся шардить

[@timramone]

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

[@BatShvit]

Прикольно -- Говорит, что хотят работать с transactional outbox быстрее, при этом предлагает уровень изоляции serializable -- У kafka если exactly-once гарантия на уровне продюсера, это упрощает всю схему -- Самое главное, exactly-once на стороне консьюмера все равно не работает :D

[@timramone]

1. А где? Вообще не предлагаю, предлагаю снапшот)) 2. Как именно? По-моему не упрощает. 3. На стороне консьюмера единственный вариант чтобы работала, в этом весь смысл.