Необходимо, чтобы выбранное значение соответствовало предложенному последним лидером, значение, которое было выбрано, может быть потеряно. Полезный способ думать об этом заключается в том, что новый собеседник выбирает совместить со старым предложением. Если он не взаимодействует, тогда может возникнуть противоречие, и мы можем получить несогласованность в распределенной системе.
Пример:
Рассмотрим узлы А, В и С, действуя все роли многоосных Paxos. Узел A является лидером и предлагает V1. Представьте, что сеть терпит неудачу, и только узлы A и B могут общаться, и только минимальное количество сообщений проходит через Node A, чтобы знать, что выбран V1.
Когда узел A слышит из узла B, он знает, что V1 выбран так, как он имеет большинство (узлы A и B). Он отправляет сообщение узлам B и C, чтобы сказать, что значение выбрано, однако, как указано в этом примере, никакие дальнейшие сообщения не проходят через Node A. Узел A выполняет такие бизнес-операции, как деньги, выплачиваемые с банковского счета суммы V1. Затем вызывается узел A.
Узел C теперь становится лидером и не знает правильного баланса банковского счета или ничего о том, что платеж даже был предложен. Узел B знает, что платеж был предложен в V1, но не был ли он выбран, так как он никогда не слышал результат от узла A. Таким образом, Node B также не знает правильный баланс банковского счета.
Механизм, который вы описываете, точно так же, как Node C взаимодействует с мертвым узлом A при выборе значения V1. Если никакие дополнительные сообщения не будут потеряны, оба B и C войдут в согласованное состояние, где они согласятся с суммой, которая была выплачена с банковского счета.
Очевидно, что если Узел C не должен был обнаружить значение V1 через узел B и должен был предложить какое-то новое значение, у нас возникло бы противоречие. Банковский счет будет поврежден, как компенсация V1 не будет отражаться в балансе счета на каждом из узлов B и C.
Обсуждение
Существует подробное обсуждение механизма вы просите о в своем сообщении в блоге, которое описывает его the leader takeover phase.
Есть некоторые стандартные детали реализации, принятые в событиях, поскольку я описываю их выше. Например, можно сказать, что «не переводите деньги с банковского счета без дополнительных сообщений, чтобы подтвердить, что все узлы знают, что значение выбрано». Тем не менее, Paxos доказал, что минимальное количество сообщений должно быть безопасным, а аварии должны быть редкими. Это означает, что при реализации Paxos обычно оптимально использовать минимальное количество сообщений при нормальном запуске и полагаться на алгоритм для восстановления согласованного состояния в системе во время сценариев сбоев.
Интересно, что значение может быть выбрано, но ни один живой узел не знает об этом. В приведенном выше примере Node A работает достаточно долго, чтобы видеть сообщения из узла B и перемещать деньги между банковскими счетами. Тем не менее, возможно, он потерпел аварию перед тем, как услышать от Node A.Он будет принимать V1, в дополнение к узлу B, но ни один Node не знает, что значение было выбрано до тех пор, пока Node C не обнаружит V1, а также не выберет его.
Интересно, что клиенты системы, те вещи, которые наблюдают банковский счет, или другие системы, получающие платеж с банковского счета, также являются частью распределенной системы. Если бы в этом случае никаких платежей не производилось с банковских счетов, тогда потеря V1 не была бы проблемой. Тем не менее, вполне нормально, что есть побочные эффекты выбранных значений. Сторонние системы или пользовательские веб-браузеры, которые наблюдают за системой, фактически являются частью распределенной системы.