Comments 7
Понятно, что когда клиент отослал запрос всем участникам, то дальше коммит произойдет уже без участия клиента. А что делать, если клиент отослал только некоторым из них и благополучно упал?

В этом случае мы обязываем клиента делать следующее: клиент обязан каждому участнику послать информацию обо всех остальных о такой транзакции. Таким образом, каждый участник знает всех других участников и рассылает им свой результат


Небольшая просьба доработать эту часть т.к. смысл сказанного не вполне понятен. Я даже сначала подумал что это перевод.

Немного улучшил этот фрагмент. Надеюсь, так будет понятнее.

По факту координатор может быть сам по себе распределенной системой, тем самым повышая отказаустойчивость.

В нормальных системах (Spanner, YT) координатор является отказоустойчивым. В противном случае все становится плохо.

Спасибо большое за статью.


Вопросы и соображения:


1)


При этом другой участник, если он не получил запроса от клиента, может выбрать одно из следующих поведений:

Как участник это понимает? Откуда он знает, когда транзакция закончена и "надо бы начать ждать команду от клиента"?


2) Если в каждой консенсус-группе по три участника, а сообщения шлются вообще от всех вообще всем, не возникает ли тут серьезного network communication amplification?


3) Похоже что предложенный алгоритм существенно сложнее сделать корректно в случае различных "плохих" сценариев, чем более модульные алгоритмы, где консенсус, коммит, participation, conflict resolution, random backoffs for liveness, etc. не запихнуты в один единственный RTT. (Абсолютно та же проблема, как мне кажется, есть у статьи, на которую вы сослались во введении, думаю стоит дать на нее ссылку для контекста: To Vote Before Decide: A Logless One-Phase Commit Protocol for Highly-Available Datastores). Не получится ли как в этом твите:


> I'm coining the phrase «effectively-once» for message processing with at-least-once + idempotent operations.
I'm coining the phrase “hopefully-once” for any production implementations of the above. https://t.co/Xq5snRKXfs
— Dan North (@tastapod) October 21, 2016


Как участник это понимает?

Это фиксирует разработчик на этапе реализации. Т.е. это возможные реализации, и надо выбрать одну из двух стратегий и ее придерживаться.


Откуда он знает, когда транзакция закончена и "надо бы начать ждать команду от клиента"

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


Если в каждой консенсус-группе по три участника, а сообщения шлются вообще от всех вообще всем, не возникает ли тут серьезного network communication amplification?

Зависит от тяжести транзакции. Но в целом это сильнее нагружает сеть, нежели другие способы. Это ожидаемо и такова плата за уменьшение времени.


Похоже что предложенный алгоритм существенно сложнее сделать корректно в случае различных "плохих" сценариев, чем более модульные алгоритмы, где консенсус, коммит, participation, conflict resolution, random backoffs for liveness, etc. не запихнуты в один единственный RTT.

Хитрожопые алгоритмы, как правило, сложнее. Тем не менее, модульность тут вполне возможна. Во-первых, консенсус алгоритм никак не завязан на двухфазность. Просто надо добавить режим для клиента посылки запросов всем участникам. Единственное добавление: это спекулятивное исполнение, т.е. алгоритм должен поддерживать такое.


Ну а в целом нет ничего нового: оптимизации, как правило, пронизывают многие слои абстракции. В данном случае, тем не менее, можно реализовать все компоненты независимо с дополнительными фишками типа спекулятивного исполнения.


Тут также стоит отметить следующую вещь. Когда проектируется система, то у тебя всегда есть выбор между различными компромиссами. Важно их иметь. Статья как раз задает рамки, в которых его можно искать. До этого рамок не было, был просто классический двухфазный коммит, который был, скажем так, недостаточно быстр.

Only those users with full accounts are able to leave comments. Log in, please.