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

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

S>·>... часть разработки.
S>Ну, ок
S>·>Что за смешанный статус? Есть "начали резервацию", "закончили резервацию".
S>А что у нас между первым и вторым? Когда половина позиций зарезервирована, а половина — нет.
S>Оплату мы тоже берём по частям?
Продолжаем резервацию до победного конца. Ты ж сам тут всё описывал: https://rsdn.org/forum/design/9057018

Автор: Sinclair
Дата: 16.02 19:51

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

S>·>Не понятно тогда зачем тебе именно надо в данной задаче объединять операции в одну ACID-группу. Из обоснований я пока заметил лишь: "SQL прекрасен батч-операциями".
S>Прекрасность SQL играет тогда, когда мы приняли решение объединять операции. Во время обработки этой ACID-группы нам противопоказаны любые коммуникации, т.к. они ведут к неограниченным задержкам.
А зачем мы приняли такое решение?

S>·>Мы вроде рассматриваем вариант "просто добавляется ещё один предикат во where". Неудача и откат тут будет лишь в случае системной ошибки.
S>Да, это способ развернуть задачу задом наперёд — когда мы, к примеру, резервируем за одно обращение группу позиций по одному и тому же товару для ряда заказов.
Именно. Когда мы не принимаем такие решения на пустом месте, у нас появляется свобода выбора и простор для различных оптимизаций.

S>>>Увеличиваем латентность, уменьшаем throughput.
S>·>Почему уменьшаем?? Для мелких ордеров throughput увеличится засчёт уменьшения числа раундтрипов.
S>За счёт накладных расходов на "переоркестрацию" заказов.
Эти накладные расходы не требуют сетевых операций или блокировок. А значит практически нулевые, наносекундного диапазона.

S>·>Ах, вспомнил. Ты же говорил — workflow, который у тебя уже есть всё равно. Вот его и достаточно. Машина состояний, реагирует на сообщения, меняет внутреннее состояние, посылает сообщения.
S>Набор гарантий для такой машины очень небольшой. Доказать, что в такой системе любой заказ рано или поздно станет либо "отказанным", либо "зарезервированным" — то ещё упражнение.
S>Даже если отказаться от гарантий liveness и сосредоточиться на safety — что мы никогда не получим дедлок — это представляет собой крайне сложную задачу, для которой нет общего решения.
Почему? Чем это будет отличаться от того, что ты там выше по пунктам расписывал?

S>·>"привычную" — ключевое слово.
S>Именно.

S>·>Трейдинг он разный..
S>Ну, когда в руках молоток — всё кажется гвоздями. И это, к сожалению, работает для любого подхода.
S>Когда в руках reader_writer_lock, то кажется, что невозможно обойтись без захвата/отпускания N*M блокировок, где N — количество позиций заказов в системе, а M — количество стадий конвеера обработки заказа.
S>Когда в руках — LMAX Disruptor, то кажется, что любую деятельность можно представить как цепочку очередей событий.
S>И гарантии, которые в одном подходе легко и элегантно обеспечиваются "по построению", в другом подходе представляют собой нетривиально доказываемую (если вообще доказуемую) теорему.
S>И, соответственно, наоборот.
Как раз не молоток. "Это другое". Если вспомнить историю, то этот подход популяризировался на базе Mechanical Sympathy. То есть не построили красивую абстрактность из мира идей того что "нам привычно" и пошли размахивать как молотком, мол, все наши пользователи пойдут в один сервер, или пусть идут нафик. Вот и HTTP, REST у нас, а потом совершенно ВНЕЗАПНО появились Keep Alive, pipelining, WebSocket, QUIC.
А Mechanical Sympathy — это как раз шаг к тому, как реально работают реальные системы в физическом мире. Потому это и есть дорога к сабж.

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

S>·>Что за смешанный статус? Есть "начали резервацию", "закончили резервацию".
S>А что у нас между первым и вторым? Когда половина позиций зарезервирована, а половина — нет.
S>Оплату мы тоже берём по частям?
Продолжаем резервацию до победного конца. Ты ж сам тут всё описывал: https://rsdn.org/forum/design/9057018

Автор: Sinclair
Дата: 16.02 19:51

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

S>·>Не понятно тогда зачем тебе именно надо в данной задаче объединять операции в одну ACID-группу. Из обоснований я пока заметил лишь: "SQL прекрасен батч-операциями".
S>Прекрасность SQL играет тогда, когда мы приняли решение объединять операции. Во время обработки этой ACID-группы нам противопоказаны любые коммуникации, т.к. они ведут к неограниченным задержкам.
А зачем мы приняли такое решение?

S>·>Мы вроде рассматриваем вариант "просто добавляется ещё один предикат во where". Неудача и откат тут будет лишь в случае системной ошибки.
S>Да, это способ развернуть задачу задом наперёд — когда мы, к примеру, резервируем за одно обращение группу позиций по одному и тому же товару для ряда заказов.
Именно. Когда мы не принимаем такие решения на пустом месте, у нас появляется свобода выбора и простор для различных оптимизаций.

S>>>Увеличиваем латентность, уменьшаем throughput.
S>·>Почему уменьшаем?? Для мелких ордеров throughput увеличится засчёт уменьшения числа раундтрипов.
S>За счёт накладных расходов на "переоркестрацию" заказов.
Эти накладные расходы не требуют сетевых операций или блокировок. А значит практически нулевые, наносекундного диапазона.

S>·>Ах, вспомнил. Ты же говорил — workflow, который у тебя уже есть всё равно. Вот его и достаточно. Машина состояний, реагирует на сообщения, меняет внутреннее состояние, посылает сообщения.
S>Набор гарантий для такой машины очень небольшой. Доказать, что в такой системе любой заказ рано или поздно станет либо "отказанным", либо "зарезервированным" — то ещё упражнение.
S>Даже если отказаться от гарантий liveness и сосредоточиться на safety — что мы никогда не получим дедлок — это представляет собой крайне сложную задачу, для которой нет общего решения.
Почему? Чем это будет отличаться от того, что ты там выше по пунктам расписывал?

S>·>"привычную" — ключевое слово.
S>Именно.

S>·>Трейдинг он разный..
S>Ну, когда в руках молоток — всё кажется гвоздями. И это, к сожалению, работает для любого подхода.
S>Когда в руках reader_writer_lock, то кажется, что невозможно обойтись без захвата/отпускания N*M блокировок, где N — количество позиций заказов в системе, а M — количество стадий конвеера обработки заказа.
S>Когда в руках — LMAX Disruptor, то кажется, что любую деятельность можно представить как цепочку очередей событий.
S>И гарантии, которые в одном подходе легко и элегантно обеспечиваются "по построению", в другом подходе представляют собой нетривиально доказываемую (если вообще доказуемую) теорему.
S>И, соответственно, наоборот.
Как раз не молоток. "Это другое". Если вспомнить историю, то этот подход популяризировался на базе Mechanical Sympathy. То есть не построили красивую абстрактность из мира идей того что "нам привычно" и пошли размахивать как молотком, мол, все наши пользователи пойдут в один сервер, или пусть идут нафик. Вот и HTTP, REST у нас, а потом совершенно ВНЕЗАПНО появились Keep Alive, pipelining, WebSocket, QUIC.
А Mechanical Sympathy — это как раз шаг к тому, как реально работают реальные системы в физическом мире. Потому это и есть дорога к сабж.