Здравствуйте, Sinclair, Вы писали:
S>·>Ок. Выглядит совсем не так, как в предыдущем примере 
И вроде нету "заказ распадается на reserved и residual".
S>Простите. Это я что-то начал подтупливать — тяжёлая неделя.
S>Это у нас код all or nothing и в монолите. Распиливание пополам выглядит в деталях по-другому, но принцип тот же.
Да, ты похоже, не на тот вопрос ответил
Я тут речь завёл о том, чтобы распилить транзакцию произвольного размера на множество мелких транзакций фиксированного размера. Тут:
https://rsdn.org/forum/design/9057463Автор: ·
Дата: 17.02 19:55
S>·>Ну вроде речь о МСА шла, а у тебя тут orders и stock в одной транзакции. В МСА же будет некий условный json на резервацию. И тут начнутся проблемы с передачей массивных объектов целиком. Скажем, в kafka размер сообщения жестко ограничивается.
S>А, если в MCA то всё ещё проще. Просто отдаём JSON и получаем обратно не такой же объект, как был — и уже при обработке респонса пилим свой order на reserved часть и всё остальное.
Вопрос о том, как сервис резервации будет взаимодейтсвовать с субд. Получил сервис резервации гигантский объект и пока его жуёт — все остальные должны ждать на блокировках.
Представь себе, есть куча заказов одной популярной сковородки. И большинство заказов из одной позиции именно на эту сковородку. И тут кто-то запулливает гигантский ордер, среди позиций есть эта сковородка. Придётся ждать всем!
Да и вообще неясно в чём преимущество заталкивать всё в одну транзакцию.
S>Опять же, это распиливание мы можем сделать безо всяких раундтрипов, передав в СУБД список успешно зарезервированных позиций в удобном для неё виде.
Как без раундрипов резервировать с успехом/неуспехом каждую позицию?
S>Размеры сообщений — это какая-то надуманная проблема. Если кафка не может передать сообщение нужного размера, то нужно выкинуть кафку.
Тут дело принципиальное — чтобы система была responsive, надо гонять мелкие сообщения. Пока кафка передаёт гигантское сообщение — другим сообщениям придётся ждать своей очереди. Ждут все! А если большое сообщение разбить на мелкие части, то ждать будет только тот, кому надо много.
S> Описанный мной способ не полагается на внешние exactly-once системы доставки.
Тут нужен at-least-once. Да, и при redelivery тоже придётся гигантское сообщение дублировать.
