2015-12-15 2 views
4

На следующем рисунке показан поток сообщений основных Paxos, в фазе 2a Лидер выбирает значение Vn для своего предложения1 и отправляет Accept (1, Vn) на каждый акцептор. Мой вопрос: что, если два из этих тезисов потеряются? Я имею в виду, что только Acceptor 1 (не большинство) получает Accept! (1, Vn). Будет ли приемник 1 принимать этот запрос? А потом транслировать каждому ученику? Это значение выбрано? enter image description hereПотеря сообщения Paxos 2a

+0

Следует избегать принятия первого неправильного ответа только потому, что это был ответ, которого вы ожидали. – simbo1905

+2

Ответ JensG верен. В базовом алгоритме Паксо нет понятия отрицательных ответов, поэтому отсутствие ответа интерпретируется как отрицательное подтверждение. Ответ Simbo1905 также верен, но ссылки на практические расширения превышают то, что требует основной алгоритм. Преимущество чистого алгоритма заключается в том, что он избегает большей части сложности, связанной с реалиями реального мира. Эффективное обнаружение и обработка этих случаев сбоев в практических реализациях может быть довольно сложным и сложным. Поэтому, вероятно, лучше всего игнорировать эти детали при первом изучении Paxos. – Rakis

+0

@Rakis плюс один для вашего хорошо рассмотренного комментария. я отредактировал свой ответ, чтобы дать понять, что он должен помочь в создании реальных решений с помощью paxos, а не в сдаче экзамена по экзамену cs. в моем опыте внедрения paxos я нахожу, что академический подход к доказательству правильности с использованием синтетического одноканального протокола, который не является практичным, вероятно, является основной причиной того, что люди находят его запутанным и сложным. поэтому я оставлю свою практическую помощь, даже если это не поможет никому пройти университетский письменный экзамен. – simbo1905

ответ

2

Предложение не получит достаточное количество (читай: Кворум) ответов на прием, поэтому весь раунд терпит неудачу.

3

Паксос терпим к повторным сообщениям, поэтому он может быть безопасным и оптимальным для того, чтобы предлагающий повторно отправить либо подготовить, либо принять сообщения, если он не получит ответа большинства. Скажем, была преходящая и короткая сетевая проблема, так что были потеряны только те сообщения. Если это время ответа на ответы, а затем повторно отправляет сообщения, сообщения будут проходить, и раунд может преуспеть. Это более эффективно, чем неудача раунда и начало нового раунда из-за потерянных сообщений.

Редактировать Я хотел бы отметить, что, как @Rakis указывает в комментарии я на самом деле говорить о практическом применении Паксоса, а не академического описания алгоритма, который предназначен, чтобы доказать правильность этого подхода. Если вы сидите экзамен по этому предмету, придерживайтесь академического описания. Если вы на самом деле пишете an implementation, то тайм-аут и повторная отправка - это способ эффективно обрабатывать потерянные сообщения из-за кратковременной потери сообщения.

Редактировать Ответ «круглый провален» означает, что есть тайм-аут, чтобы действовать на тот факт, начав новый раунд. Таймауты на самом деле не упоминаются в документе Paxos Made Simple. Поэтому, если вы хотите придерживаться академического описания алгоритма, то точный ответ на потерю сообщения «ничего не происходит, когда мир останавливается». Обратите внимание, что в документе говорится, что он не претендует на то, что происходит своевременно, только если не произойдет неправильного результата. Разумеется, никакая разумная реализация ничего не сделает; он должен тайм-аут и что-то делать. Это подчеркивает тот факт, что академическое описание алгоритма является лишь доказательством правильности; он сознательно не учитывает практические соображения о том, как реально построить фактическое решение с использованием алгоритма. В документе намекает, что вы можете добавить такие вещи, как негативные ответы, чтобы помочь построить прагматичную реализацию без правильности. Поэтому такие прагматические решения, как trex, возвращают отрицательные подтверждения для ускорения восстановления после сбоя с использованием алгоритма. Тогда не получение ответа не совпадает с получением ответов негативов; поэтому с потерей сообщений раунд не проваливается, он имеет неопределенный результат. Дальнейшие сообщения (resends) могут быть отправлены безопасно, чтобы определить фактический результат.

+0

Поскольку акцепторы не получают сообщения вообще, вряд ли они когда-либо отправят ответ. – JensG

+0

В этом ответе говорится, что отправитель должен пропустить ответ и отправить его повторно. – simbo1905

+0

Я согласен с вами в практических реализациях, но разница действительно в деталях. Как вы правильно писали: «* отправитель ** должен ** [...] повторно отправить *». Хотя это может быть хорошим советом, он все еще говорит о том, что * можно было бы сделать * после * ситуации. Отправитель ни в коем случае не обязан повторно отправлять сообщение. Другими словами, это (только) вариант, как обрабатывать ситуацию, а не обязательно. И могут быть случаи, когда начало нового раунда может быть лучшим выбором, например. когда старый раунд, скорее всего, потерпит неудачу в любом случае после некоторого длительного таймаута. – JensG