Предположим, что система кворума имеет 5 узлов, а число кворума записи и чтения равно 3. Теперь предположим, что клиент отправляет запрос записи w, и w реплицируется на 2/5 узлов. Поскольку мы не выполняли репликацию по крайней мере на 3/5 узлов, мы говорим клиенту, что запись не удалась. Теперь сразу после этого 2 узла, на которые не была реплицирована запись, выходят из строя. Итак, из оставшихся 3 узлов 2 имеют частичную запись, а 1 - нет. В этом случае, как система определяет, что частичную запись w необходимо отменить, если она на самом деле не завершилась успешно?
Отмена частичной записи в кворумных системах
comment
Добро пожаловать в SO. Stack Overflow - это сообщество для обсуждения проблем разработки программного обеспечения. Ваш вопрос кажется не по теме. Возможно, вам стоит спросить здесь: serverfault.com или здесь superuser.com
- person marsh-wiggle schedule 01.01.2021
comment
Привет, Марш, спасибо за предложение, но я вижу другие похожие вопросы в Stackoverflow и хотел бы оставить свой вопрос здесь. Если я не получу здесь ответа, я удалю этот вопрос и попробую два указанных выше веб-сайта.
- person user13635713 schedule 01.01.2021
Ответы (2)
В большинстве систем 3/5 означает, что значение выбрано и не может быть отменено.
Различные протоколы и системы справляются с этим по-разному.
В ABD следующее чтение узнает значение и от одного узла и распространит его на два других оставшихся узла.
Точно так же в Paxos следующий предлагающий узнает значение из этого одного узла и распространит его на два других. В практических системах, основанных на Paxos, будет система (возможно, Лидер), которая будет выдавать предложение no-op, чтобы гарантировать своевременное распространение значения.
В системах выбора лидера / первичной реплики, таких как Raft, лидер обеспечивает распространение на реплики. Если, конечно, это не один из тех, кто умер. В этом случае процесс выборов обычно требует, чтобы новый лидер был самым последним, что в этом случае будет включать оспариваемую стоимость.
person
Michael Deardeuff
schedule
04.01.2021
Это распространенный сценарий, который необходимо учитывать при построении распределенной системы, чтобы проверить, как управлять сбоями или событиями, которые не отправляются на все необходимые узлы.
Лидер несет ответственность за то, чтобы события были успешно отправлены в минимальный кворум, определенный до того, как событие будет считаться совершенным [должен быть флаг с хэш-кодом этого идентификатора события], и событие не имеет права на повторную попытку.
Когда появляется запрос на выборку данных из распределенных систем; он всегда идет к Лидеру, который будет делегировать запрос ближайшему Узлу по его Hashcode. Но перед делегированием лидер должен убедиться, что флаг фиксации имеет значение ИСТИНА (означает, что событие доставляется на минимально определенные узлы). В противном случае лидер может выдать исключение.
Кроме того, Лидер должен Штамповать номер Версии к событию и сохранить текущие зафиксированные флаги Номер Версии. При получении события Leader может сравнить версии событий, чтобы убедиться, что все узлы предоставляют самые свежие и самые лучшие данные.
Вы можете увидеть встроенную функциональность в системах Zookeeper и т. Д.
person
Rajasrikar
schedule
16.01.2021
