Как реплики, возвращающиеся онлайн в PAXOS или RAFT, догоняют? - PullRequest
2 голосов
/ 19 марта 2019

В согласованных алгоритмах, таких как, например, PAXOS и RAFT, предлагается значение, и, если кворум согласен, оно долговременно записывается в хранилище данных. Что происходит с участниками, которые были недоступны во время кворума? Как они в итоге догонят? Это, кажется, оставлено как упражнение для читателя, куда бы я ни посмотрел.

Ответы [ 3 ]

1 голос
/ 19 марта 2019

Посмотрите на протокол плота. Он просто встроен в алгоритм. Если лидер отслеживает самый высокий индекс (matchIndex) и nextIndex, которые должны быть отправлены каждому подписчику, и лидер всегда отправляет записи каждому подписчику, начиная с nextIndex этого подписчика, особого случая для обработки перехвата не требуется. до последователя, который отсутствовал, когда запись была совершена. По своей природе при перезапуске лидер всегда начинает отправлять записи этому последователю, начиная с последней записи в его журнале. Таким образом, узел захвачен.

0 голосов
/ 27 апреля 2019

Это упомянуто в Paxos made Simple:

Из-за потери сообщения может быть выбрано значение, так что учащийся никогда не узнает. Учащийся может спросить акцепторов, какие предложения они приняли, но отказ акцептора может сделать невозможным узнать, приняло ли большинство конкретное предложение. В этом случае учащиеся узнают, какая ценность выбрана, только когда выбрано новое предложение. Если учащийся должен знать, было ли выбрано значение, он может предложить заявителю выдать предложение, используя алгоритм, описанный выше.

А также в плоту бумаги:

Лидер поддерживает следующий индекс для каждого подписчика, который является индексом следующей записи журнала, которую лидер отправит этому подписчику.


Если журнал подписчика не согласуется с журналом лидера, проверка согласованности AppendEntries не будет выполнена на следующем RPC AppendEntries. После отклонения лидер уменьшает значение nextIndex и повторяет RPC AppendEntries. В конечном счете nextIndex достигнет точки, где совпадают журналы лидера и последователя. Когда это происходит, AppendEntries будет успешным, что удаляет любые конфликтующие записи в журнале подписчика и добавляет записи из журнала лидера (если есть).


В случае сбоя подписчика или кандидата последующие RPC RequestVote и AppendEntries, отправленные ему, завершатся неудачно. Плот обрабатывает эти неудачи, повторяя попытки бесконечно; если сбойный сервер перезапустится, RPC будет успешно завершен.

0 голосов
/ 20 марта 2019

С оригинальными бумагами Paxos это действительно оставлено как упражнение для читателя.На практике с Paxos вы можете отправлять дополнительные сообщения, такие как отрицательные подтверждения, чтобы распространять больше информации по кластеру в качестве оптимизации производительности.Это можно использовать, чтобы сообщить узлу, что он находится позади из-за потерянных сообщений.Когда узел знает, что он позади, ему нужно наверстать упущенное, что можно сделать с помощью дополнительных типов сообщений.Это описывается как ретрансляция в движке Trex multi-paxos, который я написал для демистификации Paxos .

Бумага Google Chubby paxos Paxos Made Live критикует Paxos за то, что он многое оставил на усмотрение людей, занимающихся реализацией.Лампорт учился на математика и пытался математически доказать, что вы не можете прийти к единому мнению по поводу сетей с потерями, когда он найдет решение.Оригинальные статьи в значительной степени предоставляют доказательство, которое возможно, а не объясняют, как создавать практические системы с его помощью.В современных работах обычно описывается применение некоторых новых методов, подкрепленных некоторыми экспериментальными результатами, и в то же время они предоставляют формальное доказательство, ИМХО большинство людей пропускают его и доверяют ему.«Недоступный способ введения Paxos» означает, что многие люди, которые цитируют оригинальную статью, но не понимают, что они описывают выборы лидера и мультипаксос .К сожалению, Паксос все еще преподают теоретически, а не в современном стиле, что заставляет людей думать, что это трудно, и упускать суть.

Я утверждаю, что Paxos - это просто , но рассуждать о сбоях в распределенной системе и проверять наличие ошибок сложно.Все, что остается читателю в оригинальных статьях, не влияет на правильность, но влияет на задержку, пропускную способность и сложность кода.Как только вы поймете, что делает Paxos правильным, поскольку он механически прост, вам будет просто написать остальное, что необходимо, таким образом, чтобы не нарушать согласованность, когда вы оптимизируете код для своего варианта использования и рабочей нагрузки.

Например, Корфу и CURP обеспечивают невероятно высокую производительность: один использует Paxos только для метаданных, другой должен выполнять Paxos только при одновременной записи втакие же ключи.Эти решения напрямую не дополняются Raft или Multi-Paxos, поскольку они подходят для конкретных высокопроизводительных сценариев (например, для магазинов kv).Тем не менее, они демонстрируют, что стоит понимать, что для практических приложений существует огромное количество оптимизаций, которые вы можете выполнить, если ваша конкретная рабочая нагрузка позволит вам при использовании Paxos для какой-то части общего решения.

...