Артем Рудневский - Exactly-once в микросервисной среде
Vložit
- čas přidán 5. 09. 2024
- Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Если вы разрабатываете монолитное приложение с одной БД, и у вас нет вызовов внешних сервисов по отношению к вашей системе, то скорее всего, вы никогда не столкнетесь с проблемами, обсуждаемыми на этом докладе.
Но в системе из нескольких сервисов и под высокой нагрузкой сложно добиться:
- чтобы логические и бизнесовые транзакции выполнялись однократно;
- чтобы клиентам гарантированно отправлялось одно и только одно уведомление или выдавался один и только один промокод.
Проблема решается за счёт проектирования идемпотентных сервисов. Доклад будет о том, как решались эти проблемы на примере высоконагруженного сервиса, и как в этом помогали Kafka и Redis.
Скачать презентацию: squidex.jugru....
На 23:30 как-то сложно с промежуточной очередью, обычно для ускорения outbox сообщение отправляют просто после коммита транзакции (и если удалось - удаляют из outbox). Тогда фоновый процесс будет заниматься доотправкой только того, что не удалось отправить из-за ошибки, большинство сообщений будут отправляться сразу же (но точно также проходить через коммит в outbox).
После коммита будут теряться сообщения
@@timramone наверно имеется ввиду, что мы в транзакции выполняем полезную работу и сохраняем в аутбокс сообщение, которое нужно отправить, и комитим транзакцию. Тут все как везде) а дальше в этом же потоке пытаемся сразу отправить данное сообщение и удалить его из аутбокса, тогда демону, который разгребает аутбокс, нужно будет доотправлять только упавшие сообщения
@@want2sleeptt понятно, тоже интересный подход!
@@timramone не просто интересный, а логичный, ведь он сильно оптимизирует happy path.
@@AgentFire0 ответ через год конечно смешно, но тем не менее :) не всегда это можно себе позволить, например если ты находишься в критическом пути, или если то, что должно происходиить в обработке outbox'а сильно дороже обработки исходного сообщения (и соответственно должно масштабироваться по-другому как-то)
Прикольно
-- Говорит, что хотят работать с transactional outbox быстрее, при этом предлагает уровень изоляции serializable
-- У kafka если exactly-once гарантия на уровне продюсера, это упрощает всю схему
-- Самое главное, exactly-once на стороне консьюмера все равно не работает :D
1. А где? Вообще не предлагаю, предлагаю снапшот))
2. Как именно? По-моему не упрощает.
3. На стороне консьюмера единственный вариант чтобы работала, в этом весь смысл.
Не совсем понятен один момент. Сначала говорится что эвентов много и rdbms не подходит под такую нагрузку. При этом далее говорится что при создании клиента его данные и эвент о создании коммитятся в рамках одной транзакции (outbox). Тогда получается что если будет много клиентов система прикурить из-за проблем масштабируемости rdbms и далее видимо придётся шардить
всё так. в докладе имеется ввиду, что мы не будем делать таблицу транзакций, из которых потом вычитывать пачку и отправлять её в кафку, так как это как раз очередь на базе. вместо этого мы пишем в настояющую очередь, и читаем из базы по ключу, что гораздо лучше масштабируется (параллелится)
У RabbitMQ есть и кластер и репликации
А есть какие-то примеры продакшн использования, которые прям можно почитать/посмотреть? Мы с кластером бились довольно долго, и так и не добились надёжной работы, поэтому и переходим на кафку везде, с ней никаких проблем пока не встретили.
Если честно, я не оч в контексте, какие именно проблемы там были, могу на работе поспрашивать, но на сколько я помню, ноды вылетали и кластер разваливался.
@@timramone Kafka и RabbitMQ - это инструменты под разные сценарии использования. Kafka это по сути хранилище с функцией очень быстрого стриминга (миллионы сообщений в секунду вполне достижимо), RabbitMQ (без функций Streams) - это продвинутый брокер сообщений, который позволяет настроить роутинг сообщений и гарантировать их доставку (но на порядок медленнее, чем Kafka). Есть смысл использовать Kafka для лого-подобных сообщений, а RabbitMQ для более объемных транзакций.