Я бы сказал, что сагу можно назвать супер-оптимистичной транзакцией. :)
Настолько оптимистичной, что она перестает быть вообще транзакцией.
та же квантовая физика учит нас, что реальность не детерминирована.
Типичное заблуждение. Квантовое уравнение описывает эволюцию неклассического (квантового) состояния, которое по заданным начальным условиям точно определяет все события в будущем и прошлом.
Речь не про 100% детерминизм. Ведь в двухфазном коммите тоже нет детерминизма. Речь про консистентные переходы системы из одного состояния в другое. И саги тут решают проблему масштабируемости и переносят проблему консистентности на плечи пользовательского кода.
Вообще, это иллюзия, что двухфазный коммит тормозной. Я вот здесь как раз написал про это: "Достижимость нижней границы времени исполнения коммита распределенных отказоустойчивых транзакций" https://habr.com/post/353248/
Просто существует ряд иллюзий по поводу консистентности. Все возникает из-за недостаточной базы в распределенных системах.
Есть, но почему-то никто не пользуется. Слышал, что, дескать, все с ними сложно и они сильно тупят. Но мне кажется, рано или поздно к этому придем. Это лишь вопрос времени.
Должно быть так: вжух, и доказательство провалидировано. И все счастливы, а по вопросам веры следует обращаться в другую организацию.
Пора уже валидацию доказательств поручать машине. Слишком сложные доказательства становятся, надо иметь надежный фундамент для верификации доказательств. А то получается, что рассматриваются вопросы веры, а не реального положения дел.
Детерминированные алгоритмы дают транзакционное поведение с высокими гарантиями по консистентности. В то время как здесь нет транзакций. Нельзя же сказать, что саги бывают пессимистичными или оптимистичными. Да, они выглядят как оптимистичные транзакции, но градаций у них нет.
как система обрабатывает ситуацию, когда одна полу-транзакция отработала, закоммитилась, передала управление на вторую, а потом отразившая первую полутранзакцию база была утерена и восстановлена без следов этой полутранзакции?
Передачи управления не происходит, каждый участник коммитит и работает со своими полутранзакциями. При этом если после выполнения полутранзакции участник сразу падает, то затем после восстановления он проверяет, не была ли выполнена полутранзакция. Таким образом достигается идемпотентность операции: см. push_at_idempotent функцию.
тут ключевая оптимистичность в полном отказе от коммита
В моем понимании, если нет коммита, то говорить об оптимистичности не имеет смысла. Оптимистичность можно использовать в контексте транзакций.
Поэтому синхронизация не ситуативная, а вообще отсутствует.
Каждое действие является атомарным, а значит, синхронизация присутствует, но локально для этого действия. Т.е. разные саги над одним и тем же элементом будут синхронизированы.
сервис уже сам решает, какие поля ему обновлять, и что еще учесть. Никаких безусловных директив.
Ну тогда это не саги, а набор костылей, чтобы как-то работало. Саги имеют вполне понятную четкую и довольно жесткую семантику.
Современные исследования (например, An Evaluation of Distributed Concurrency Control. VLDB 2017) утверждают, что помочь может так называемый «оптимистический подход».
Двухфазный коммит совместим с оптимистичным подходом. Более того, оптимистичность в контексте VLDB 2017 статьи имеет очень далекое отношение к тому, что здесь описано. Дело в том, что оптимистичность — это про блокировки во время выполнения пользовательских операций. Они берутся только в последней фазе — во время коммита.
В то же время в приведенной статье ни о каких транзакциях речь не идет. Речь идет про атомарное исполнение на каждом этапе с возможностью отката изменений в случае, если последующая операция не имеет возможности выполнится.
К недостаткам такого подхода, как и другие масштабируемые подходы, можно отнести:
Отсутствии целостности данных. Т.е. в любой момент времени мы видим какое-то промежуточное состояние, причем не факт, что то, что мы видим, будет в реальности, из-за возможного отката действий. Т.е. тут налицо практически все нарушения консистентности, включая фантомные данные. Как правило, такое поведение усложняет пользовательский код, т.к. никакой инвариант не может быть гарантирован в любой момент времени.
Подразумевается, что откат действия происходит без сбоев. В простейших случаях все просто, в сложных — как нетрудно догадаться, все сложно. Например: мы применили действие, другая сага поверх этого действия еще что-то сделала, а потом надо откатить первое. Далеко не всегда это представляется возможным в случае конкурентного взаимодействия. Необходимо знать все способы изменения данных, что, конечно же, никто не делает, т.к. проект развивается. Поэтому откат транзакции может завершиться неудачей и никогда не откатить исходную транзакцию. Нужно следить внимательно, что все действия являются откатываемыми при любых конкурентных взаимодействиях ВСЕХ других транзакций.
В целом, подход очень похож на то, что я описал с статье "Гетерогенная конкурентная обработка данных в реальном времени строго один раз": https://habr.com/post/413817/
Например, мы записываем во внешнюю базу данных, при этом у нас at-most-once. Если при этом не получилось записать, то эту запись мы сохраняем для того, чтобы позже повторить. Можно, конечно, тут же потерять эту запись, но нам бы не хотелось этого делать. После этого можно крешнуться прямо во время записи, а затем, т.к. эта запись осталась в нашем состоянии, то после восстановления снова попытаться ее записать.
"Обеспечить идемпотентность может только фиксация факта учёта и увеличения счётчика в одной транзакции." — откуда следует это утверждение?
"Причём брокер действительно не может принципиально обеспечить exactly once." Что есть "брокер", и почему он "действительно не может принципиально обеспечить"? В статьях ничего такого не говорилось.
"Так что даже в этом случае exactly once в случае ошибок превращается в at least once." Как это следует из предыдущего?
"commit_snapshot(snapshot 1)". Что такое commit_snapshot и log_and_apply_transaction? Какое хранилище используется для хранения?
Есть ли понимание, что tx.open()… tx.commit() использует другое хранилище, внешнее, по отношению к движку обработки данных?
Хочется понять проблематику и более подробное описание, что означет приведенный код.
Пункт "Фундаментальность подхода" подробно описывает возможность разбиения транзакций на полутранзакции. Каждая полутранзакция — атомарная операция, суммарное действие полутранзакций составляет исходную транзакцию.
Данная статья в топе по запросу "Exactly once". Статья в целом воспринимается как вполне толковая, и кто-то может подумать даже подумать, что в ней есть глубокий смысл. А рассмотрение деталей позволяет прояснить многие ключевые моменты.
Чтобы понимать намерения, для этого не нужно читать мысли. Достаточно глядеть на машины вокруг и понимать ситуацию и возможные варианты. В подавляющем большинстве случаев все действия достаточно предсказуемы, если водители опытны и знают, что будут делать в следующую секунду.
A Paxos — это серия алгоритмов. Можно почитать, например, такую статью: "Byzantizing Paxos by Refinement", Leslie Lamport, 2010. Ключевое слово — Byzantizing.
Настолько оптимистичной, что она перестает быть вообще транзакцией.
Типичное заблуждение. Квантовое уравнение описывает эволюцию неклассического (квантового) состояния, которое по заданным начальным условиям точно определяет все события в будущем и прошлом.
Речь не про 100% детерминизм. Ведь в двухфазном коммите тоже нет детерминизма. Речь про консистентные переходы системы из одного состояния в другое. И саги тут решают проблему масштабируемости и переносят проблему консистентности на плечи пользовательского кода.
Вообще, это иллюзия, что двухфазный коммит тормозной. Я вот здесь как раз написал про это: "Достижимость нижней границы времени исполнения коммита распределенных отказоустойчивых транзакций" https://habr.com/post/353248/
Просто существует ряд иллюзий по поводу консистентности. Все возникает из-за недостаточной базы в распределенных системах.
Есть, но почему-то никто не пользуется. Слышал, что, дескать, все с ними сложно и они сильно тупят. Но мне кажется, рано или поздно к этому придем. Это лишь вопрос времени.
Должно быть так: вжух, и доказательство провалидировано. И все счастливы, а по вопросам веры следует обращаться в другую организацию.
Пора уже валидацию доказательств поручать машине. Слишком сложные доказательства становятся, надо иметь надежный фундамент для верификации доказательств. А то получается, что рассматриваются вопросы веры, а не реального положения дел.
Детерминированные алгоритмы дают транзакционное поведение с высокими гарантиями по консистентности. В то время как здесь нет транзакций. Нельзя же сказать, что саги бывают пессимистичными или оптимистичными. Да, они выглядят как оптимистичные транзакции, но градаций у них нет.
Передачи управления не происходит, каждый участник коммитит и работает со своими полутранзакциями. При этом если после выполнения полутранзакции участник сразу падает, то затем после восстановления он проверяет, не была ли выполнена полутранзакция. Таким образом достигается идемпотентность операции: см.
push_at_idempotentфункцию.В моем понимании, если нет коммита, то говорить об оптимистичности не имеет смысла. Оптимистичность можно использовать в контексте транзакций.
Каждое действие является атомарным, а значит, синхронизация присутствует, но локально для этого действия. Т.е. разные саги над одним и тем же элементом будут синхронизированы.
Ну тогда это не саги, а набор костылей, чтобы как-то работало. Саги имеют вполне понятную четкую и довольно жесткую семантику.
Двухфазный коммит совместим с оптимистичным подходом. Более того, оптимистичность в контексте VLDB 2017 статьи имеет очень далекое отношение к тому, что здесь описано. Дело в том, что оптимистичность — это про блокировки во время выполнения пользовательских операций. Они берутся только в последней фазе — во время коммита.
В то же время в приведенной статье ни о каких транзакциях речь не идет. Речь идет про атомарное исполнение на каждом этапе с возможностью отката изменений в случае, если последующая операция не имеет возможности выполнится.
К недостаткам такого подхода, как и другие масштабируемые подходы, можно отнести:
В целом, подход очень похож на то, что я описал с статье "Гетерогенная конкурентная обработка данных в реальном времени строго один раз": https://habr.com/post/413817/
Можете уточнить:
Молодец!
Очередная статья на тему блокчейна, не объясняющая и не определяющая понятие "блокчейн", как будто это так просто и все должны знать, что это такое.
Например, мы записываем во внешнюю базу данных, при этом у нас at-most-once. Если при этом не получилось записать, то эту запись мы сохраняем для того, чтобы позже повторить. Можно, конечно, тут же потерять эту запись, но нам бы не хотелось этого делать. После этого можно крешнуться прямо во время записи, а затем, т.к. эта запись осталась в нашем состоянии, то после восстановления снова попытаться ее записать.
Я потерял нить диалога.
Хочется прояснить следующие вещи:
Хочется понять проблематику и более подробное описание, что означет приведенный код.
Статью не читаю, комментарий пишу?
Пункт "Фундаментальность подхода" подробно описывает возможность разбиения транзакций на полутранзакции. Каждая полутранзакция — атомарная операция, суммарное действие полутранзакций составляет исходную транзакцию.
Дубликаты может давать сам обработчик, повторяя действия с последнего восстановленного состояния.
Бывают нюансы, связанные со взаимодействием с внешними хранилищами. Но в нулевом приближении все просто.
Дедупликация делается на входе последующего обработчика, который есть выход предыдущего.
Данная статья в топе по запросу "Exactly once". Статья в целом воспринимается как вполне толковая, и кто-то может подумать даже подумать, что в ней есть глубокий смысл. А рассмотрение деталей позволяет прояснить многие ключевые моменты.
Чтобы понимать намерения, для этого не нужно читать мысли. Достаточно глядеть на машины вокруг и понимать ситуацию и возможные варианты. В подавляющем большинстве случаев все действия достаточно предсказуемы, если водители опытны и знают, что будут делать в следующую секунду.
A Paxos — это серия алгоритмов. Можно почитать, например, такую статью: "Byzantizing Paxos by Refinement", Leslie Lamport, 2010. Ключевое слово — Byzantizing.