Новое сообщение в форум Архитектура программного обеспечения

Форум	Архитектура программного обеспечения
Тема	Как правильно задавать вопросы

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ·, Вы писали:

G>>>>>В основном товары со склада продает. Вот и надо продать не больше чем есть.
G>>>·>Для этого нет необходимости транзакционно обновлять состояние корзины с резервов на складе.
G>>>Ты не понимаешь суть задачи
G>>>две сущности Order (id, status, lines(product_id, q)) и Stock (product_id, reserverd, limit). При смене статуса в Order мы меняем состояние резервов в Stock.
G>>>При подтверждении заказа - увеличиваем reserved в stock для каждого line в order. А при отмене уменьшаем.
G>>>Если мы это не делаем в одной транзакции, то как ты потом уменьшишь, если статус не удалось сменить? 
G>·>Так же, как если клиент набрал кучу товаров, они зарезервировались, но не смог оплатить. Резерв нужно откатывать.
G>Нужно, это другой сценарий. Далеко не то же самое, что откат незавершенной резервации.

G>>>Сохранишь копию order в то же базе в той же тразакции, да?
G>>>Ты наверное начнешь разговор что так делать не надо. Но озону надо. Потому что разница limit-reserverd отображается в интерфейсе приложения как "сколько осталось" и это отображается прямо в результатах поиска, то есть надо быстро получать это число для любого количества товаров. 
G>·>Сохранять копии? Конечно, не надо.
G>А что тогда делать для отката незавершенной резервации?

G>>>·>Зато будет работать хотя бы.
G>>>Не лучше, чем в одной базе. Прям строго математически не лучше.
G>·>В крупных магазинах такое вообще работать не будет.
G>Ты можешь как-то обосновать свои слова?

G>>>·>Это эквивалентно ситуации: клиент наполнил корзину и ушел плюнув, потому что левая пятка зачесалась. Код отката брони на складе ты будешь писать в любом случае.
G>>>Не эквивалентно и не придется такое писать. Это твои фантазии
G>·>Как не придётся? Что делать, когда корзина создана, товары зарезервированы, а пользователь закрыл браузер и ушел с концами?
G>Это другой сценарий, мы его сейчас не рассматриваем.
G>Не надо придумывать новые кейсы, придумай как сделать хорошо один. Потом будем другие рассматривать.
G>Пока у тебя ничего внятного не получилось.

G>>>>>Идемпотентной такую операцию уже не сделаешь и автоповтор со стороны клиента тоже. 
G>>>·>Почему? Присваиваешь заявке на бронирование uuid и долбишь склад до посинения.
G>>>То ест мало того, что для обработки отмены ты вынужден будешь сохранить почти весь order в в той же транзакции, что и обновление остатков, так еще и дополнишь его полем ключа идемпотентности :facepalm:
G>·>Зачем его сохранять? Заявка - это сообщение. Ты вообще что-ли не понимаешь как делают идемпотентность?
G>Я понимаю как делают идемпотентность. Я не понимаю как ты её хочешь сделать.
G>Можешь привести пример кода?

G>>>>>Так в том и дело, что у СВНа не было преимуществ перед Гит. У Гита был один недостаток - сложность использования, до сих пор два из трех программистов не умеют в гит.
G>>>·>Многие носились с номерами ревизий. Коммит 23414 выглядит на порядок лучше, чем 21f0c36f3cef976789d9c65c16198a7c14f7b272. А ещё отдельные чекауты подветок, локи, явные переименования, и т.п. Многие заявляют "нам нужно".
G>>>Я уверен что и сейчас svn найдет сторонников, потому что он все еще в разы проще git. Аргументы будут самые неразумные.
G>·>А совсем проще всего - вообще не использовать системы контроля версий. 
G>Альтернатива какая? передавать архивами и мерить вручную?

G>>>>>·>Речь о другом - процесс не один. Можно иметь две субд, в каждой свои локальные транзакции.
G>>>>>И что это даст? Неатомарное, несогласованное, неизолированное изменение данных? В чем смысл?
G>>>·>Чтоб работало.
G>>>Только оно не рабоает.
G>·>Ну ты хочешь чтобы я тут описывал как строятся МСА системы? Мне очень лень, но можешь почитать, например, тут: https://medium.com/@CodeWithTech/the-saga-design-pattern-coordinating-long-running-transactions-in-distributed-systems-edbc9b9a9116
G>Не надо ссылок, просто приведи пример кода как бы ты сделал резервацию заказа.

G>>>И? они все еще на Postgres с одним мастером, и все работает
G>·>В смысле? У них postgres в режиме deprecated. Т.к. дорого всё распилить, т.к. надо переделывать всё. Сказано же: "no longer allow adding new tables". Кто-то гениальный запилил им монолит, вот теперь страдают.
G>Да уж, страдают.... :)))

G>>>·>Но в главном-то ты прав: "все приходят в итоге на одни сервер". :))
G>>>Там где не нужна целостность всегда можно вынести. Но мы же рассматриваем задачу где она нужна.
G>·>Ну у них не получилось. Все эти многослойные кеши и реплики - это уже отказ от целостности.
G>Если ты не пишешь данные, на основе результатов чтения из отстающей реплики, то нарушения целостности нет.

G>>>·>Ты, видимо, сервер и сервис путаешь. Один сервис может работать как несколько инстансов, нет требования монолитности. И внезапно надёжность сервиса выше, если он работает на нескольких серверах.
G>>>Это ты путаешь stateless и stateful. В stateless сервисе ты можешь поднять несколько инстансов на разных серверах и если один перестанет отвечать другие смогут ответить.
G>>>Но когда мы рассматриваем stateful (а база данных это statful сервис), то при нескольких экземплярах мы наталкиваемся на CAP ограничения - мы можем или терять консистентность (что запрещено по условиям задачи) или доступность.
G>·>В задаче корзина-склад - достаточно eventual consistency.
G>Покажи пример кода

G>>>Причем потерю доступности можно посчитать. Доступность системы из двух stateful узлов равна произведению доступности серверов, которая меньше доступности одного сервера. Априори считаем все серверы имеют одинаковую доступность.
G>>>Поэтому чтобы не заниматься сложной схемой отказоустойчивости и распределенными транзакциями выбирают обычную master-slave репликацию, когда все записи приходят в одну ноду. 
G>·>Такое требуется в очень редких задачах. И там обычно используют какой-нибудь event sourcing, а не acid субд.
G>Именно, а в более простых случаях вполне достаточно одного мастера. Вот у OpenAI простой случай. Я правда не представляю у кого он не простой.

G>>>>>Чтобы пользователь придя за своим товаром получил его.
G>>>·>Для этого не требуется обновлять корзину и склад в одной транзакции.
G>>>Я уже выше описал почему требуется. Не повторяй эту глупость уже
G>·>Ещё раз. Если выполнять вначале транзакцию резервации, потом другую транзакцию для смены статуса заказа - то мы гарантируем, что товар будет в наличии после оплаты заказа.
G>·>Существует только проблема того, что товар зарезервирован, но не оплачен. Нужен ещё процесс отмены резерва. И твоя транзакция ничем не помогает, никакую проблему она не решает.
G>Да ты сначала сделай процесс резервирования надежным, потом про оплату поговорим.

G>>>·>Можно продолжать работать с корзиной, например, позволять добавлять товары ещё, обновлять адрес доставки, применять скидки и купоны и т.п.
G>>>Лол, а зачем? 
G>·>Ага. Раз такого в Озоне нет, то это никому не нужно.
G>Так мы сейчас про конкретную задачу говорим, как в озоне.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail