Комментарии 7
Понятно, что когда клиент отослал запрос всем участникам, то дальше коммит произойдет уже без участия клиента. А что делать, если клиент отослал только некоторым из них и благополучно упал?
В этом случае мы обязываем клиента делать следующее: клиент обязан каждому участнику послать информацию обо всех остальных о такой транзакции. Таким образом, каждый участник знает всех других участников и рассылает им свой результат
Небольшая просьба доработать эту часть т.к. смысл сказанного не вполне понятен. Я даже сначала подумал что это перевод.
Спасибо большое за статью.
Вопросы и соображения:
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.
Хитрожопые алгоритмы, как правило, сложнее. Тем не менее, модульность тут вполне возможна. Во-первых, консенсус алгоритм никак не завязан на двухфазность. Просто надо добавить режим для клиента посылки запросов всем участникам. Единственное добавление: это спекулятивное исполнение, т.е. алгоритм должен поддерживать такое.
Ну а в целом нет ничего нового: оптимизации, как правило, пронизывают многие слои абстракции. В данном случае, тем не менее, можно реализовать все компоненты независимо с дополнительными фишками типа спекулятивного исполнения.
Тут также стоит отметить следующую вещь. Когда проектируется система, то у тебя всегда есть выбор между различными компромиссами. Важно их иметь. Статья как раз задает рамки, в которых его можно искать. До этого рамок не было, был просто классический двухфазный коммит, который был, скажем так, недостаточно быстр.
Достижимость нижней границы времени исполнения коммита распределенных отказоустойчивых транзакций