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

G>·>Реальные физические акторы физически разделены и физически невозможно обеспечить 100% надёжную коммуникацию между ними.
G>Как связаны реальны акторы и информационная система?
Информационная система — это модель реальных акторов. Чем модель точнее, тем лучше работает.

G>·>Поэтому в CAP будет присутствовать компонента P, хочется тебе того или нет.
G>Как связаны реальные акторы и CAP?
Вот там тебе писали пример: "Потому что с утра жахнули при разгрузке два холодоса об асфальт, а списать еще не списали".

G>>>О какой проблеме идет речь?
G>·>"задачу, которая откатывает незавершенные резервы".
G>Эта проблема решается транзакциями в БД.
G>Если ты уверен что нет, то наверное можешь показать пример как СУБД с ACID гарантиями не откатывает незавершенные транзакции.
Читай внимательно: "незавершенные резервы" != "незавершенные транзакции".

G>>>И что? Нам поэтому нужно сделать отдельные базы для Заказа, Склада и Пользователя, чтобы соответствовало существительным?
G>·>Не чтобы соответствовало существительным, а чтобы сабж.
G>А зачем это? Самоцель сделать микросервисы? Потребителю пофиг сколько у вас сервисов.
Цель: правильно спроектировать.

G>>>А как в 1С конфигурации УНФ это все в одной базе существует? Оно как-то неправильно работает?
G>>>В 1С вообще это все решалось в рамках одной базы задолго до появления термина "микросервисы". В чем они неправы?
G>·>Хреново 1С работает. Не знаю как оно изменилось с тех пор, но раньше это был просто ад — все ломятся через RDP на один гигасервер и простейшие операции работают минуты. И если что-то где-то упало, то всё и сразу лежит.
G>Показывает уровень понимания 1С...
Наверное. Но никогда не слышал, что 1С отличалась скоростью работы и стабильностью. Десяток пользователей как правильно уложат любой крутой 1С сервак.

G>Давай проще, я в статье описал пример кода, который в одной базе сохраняет заказы и меняет остатки транзакционно https://habr.com/ru/articles/955714/ Без RDP работает.
Ну честно говоря в ретейле я давно не работал. А для трейдинга это какие-то смешные показатели перформанса.
Вот недавно как раз завершили decomission старой системы с субд, acid и прочим. Время отклика уменьшилось с 300мс до 3мс.

G>Можешь прям в коде показать где там проблемы, которые я игнорирую?
Честно говоря, всё читать лень, но вот эту, например: "резерв полностью прошел но оплата не прошла".

G>>>Важно. В монолите это все не нужно. Монобаза тебе обеспечивает атомарность, вообще всегда.
G>·>Если после 2-го пункта произойдёт какая-либо ошибка, как тебе поможет твоя атомаронсть?
G>Про какой второй пункт речь?
Второй из этих:
G>>>·>1. Пользователь создаёт заказ
G>>>·>2. Склад резервирует заказ
G>>>·>3. Пользователь завершает заказ
Пользователь завершает заказ после оформления доставки, оплаты и прочего. Обычно может длиться от нескольких минут до нескольких месяцев.

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

G>·>Реальные физические акторы физически разделены и физически невозможно обеспечить 100% надёжную коммуникацию между ними.
G>Как связаны реальны акторы и информационная система?
Информационная система — это модель реальных акторов. Чем модель точнее, тем лучше работает.

G>·>Поэтому в CAP будет присутствовать компонента P, хочется тебе того или нет.
G>Как связаны реальные акторы и CAP?
Вот там тебе писали пример: "Потому что с утра жахнули при разгрузке два холодоса об асфальт, а списать еще не списали".

G>>>О какой проблеме идет речь?
G>·>"задачу, которая откатывает незавершенные резервы".
G>Эта проблема решается транзакциями в БД.
G>Если ты уверен что нет, то наверное можешь показать пример как СУБД с ACID гарантиями не откатывает незавершенные транзакции.
Читай внимательно: "незавершенные резервы" != "незавершенные транзакции".

G>>>И что? Нам поэтому нужно сделать отдельные базы для Заказа, Склада и Пользователя, чтобы соответствовало существительным?
G>·>Не чтобы соответствовало существительным, а чтобы сабж.
G>А зачем это? Самоцель сделать микросервисы? Потребителю пофиг сколько у вас сервисов.
Цель: правильно спроектировать.

G>>>А как в 1С конфигурации УНФ это все в одной базе существует? Оно как-то неправильно работает?
G>>>В 1С вообще это все решалось в рамках одной базы задолго до появления термина "микросервисы". В чем они неправы?
G>·>Хреново 1С работает. Не знаю как оно изменилось с тех пор, но раньше это был просто ад — все ломятся через RDP на один гигасервер и простейшие операции работают минуты. И если что-то где-то упало, то всё и сразу лежит.
G>Показывает уровень понимания 1С...
Наверное. Но никогда не слышал, что 1С отличалась скоростью работы и стабильностью. Десяток пользователей, как правило, уложат любой крутой 1С сервак.

G>Давай проще, я в статье описал пример кода, который в одной базе сохраняет заказы и меняет остатки транзакционно https://habr.com/ru/articles/955714/ Без RDP работает.
Ну честно говоря в ретейле я давно не работал. А для трейдинга это какие-то смешные показатели перформанса.
Вот недавно как раз завершили decomission старой системы с субд, acid и прочим. Время отклика уменьшилось с 300мс до 3мс.

G>Можешь прям в коде показать где там проблемы, которые я игнорирую?
Честно говоря, всё читать лень, но вот эту, например: "резерв полностью прошел но оплата не прошла".

G>>>Важно. В монолите это все не нужно. Монобаза тебе обеспечивает атомарность, вообще всегда.
G>·>Если после 2-го пункта произойдёт какая-либо ошибка, как тебе поможет твоя атомаронсть?
G>Про какой второй пункт речь?
Второй из этих:
G>>>·>1. Пользователь создаёт заказ
G>>>·>2. Склад резервирует заказ
G>>>·>3. Пользователь завершает заказ
Пользователь завершает заказ после оформления доставки, оплаты и прочего. Обычно может длиться от нескольких минут до нескольких месяцев.