Почему проблема консенсуса так важна в распределенных вычислениях?

19

В распределенных вычислениях проблема консенсуса, по-видимому, является одной из центральных тем, которая привлекла интенсивные исследования. В частности, статья «Невозможность распределенного консенсуса с одним ошибочным процессом» была удостоена награды PODC за выдающуюся работу в 2001 году .

Так почему проблема консенсуса так важна? Чего мы можем достичь с консенсусом как в теории, так и на практике?

Любые ссылки или экспозиции будут действительно полезны.

reference-request big-picture dc.distributed-comp

— Hengxin
источник

18

Упомянутый вами документ важен по двум причинам:

Это показывает, что не существует асинхронного детерминированного консенсусного алгоритма, который допускает даже одну ошибку сбоя. Обратите внимание, что в синхронной настройке существует детерминированный алгоритм, который завершается в раундах когда сбой процессов. $f+1$ $\le f$
Он вводит бивалентность и однолистность конфигураций (*), которые позже используются во многих нижних оценках и доказательствах невозможности.

Приложения

Одним из важных применений проблемы консенсуса является избрание координатора или лидера в отказоустойчивой среде для инициирования каких-либо глобальных действий. Консенсусный алгоритм позволяет вам делать это на лету, не исправляя заранее «суперузел» (который привел бы к единственной точке отказа).

Другое приложение поддерживает согласованность в распределенной сети: предположим, что у вас есть разные сенсорные узлы, контролирующие одну и ту же среду. В случае, если некоторые из этих сенсорных узлов выходят из строя (или даже начинают отправлять поврежденные данные из-за аппаратного сбоя), согласованный протокол обеспечивает устойчивость к таким сбоям.

(*) Выполнение распределенного алгоритма - это последовательность конфигураций. Конфигурация - это вектор локальных состояний процессов. Каждый процесс выполняет детерминированный конечный автомат. Любой правильный алгоритм консенсуса должен в конечном итоге достичь конфигурации, в которой каждый процесс определил (безвозвратно) одно и то же входное значение. Конфигурация составляет - валентный если, независимо от того , что делает противник, все возможные расширения приводят к значению решения от . Аналогично мы можем определить - валентность . Конфигурация является двухвалентной, если оба решения достижимы из $C$ $1$ $C$ $1$ $0$ $C$ $C$ (какой из двух достигнут, зависит от противника). Ясно, что ни один процесс не может быть решен в двухвалентной конфигурации , так как в противном случае мы получим противоречие с соглашением! Таким образом, если мы можем построить бесконечную последовательность таких двухвалентных конфигураций, мы показали, что в этой настройке нет консенсусного алгоритма. $C$

— Питер
источник

2

@AJed В качестве дополнения: я просмотрел синхронизацию работы Мориса Херлихи и теперь могу представить еще одно большое теоретическое значение проблемы консенсуса. Используя идею согласованного числа , можно показать, что существует бесконечная иерархия примитивов синхронизации, так что ни один примитив на одном уровне не может быть использован для реализации любых примитивов на более высоких уровнях без ожидания. Проще говоря, проблема консенсуса рассматривается как единая теория определения относительной силы примитивных операций синхронизации. Это элегантно.

— hengxin 12.12.12

1

У меня есть некоторые трудности в понимании доказательства невозможности результата ФЛП. Не могли бы вы дать мне несколько советов? Пожалуйста, обратитесь к [доказательство FLP] ( stackoverflow.com/q/15131730/1833118 ). Благодарю.

— hengxin

«где каждый процесс решил», может быть, должен быть «где каждый правильный процесс решил»?

— nbro

Вы должны объяснить, кто является противником, «независимо от того, что противник делает».

— nbro

«все возможные расширения C», что вы подразумеваете под «расширением C»? Что такое расширение конфигурации в целом?

— Nbro

7

Это показывает, что нет отказоустойчивого детерминированного алгоритма. Довольно сильный теоретический результат, который заставляет дизайнеров по-разному справляться с отказоустойчивостью, некоторые из которых - синхронизация и рандомизация.

Комментарий: По моему мнению, синхронизация - это дополнительное допущение системы, которое вряд ли можно найти в практических приложениях.

Для ссылок, проверьте ссылку в Википедии . Проверьте также этот блог для практических приложений

— AJed
источник

1

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

— hengxin

1

Говоря о синхронизации, мне просто не нравится предположение в теории . Однако в промышленности часто применяется частичная или частичная синхронизация. Например, Google Spanner - это глобально распределенная синхронно реплицируемая база данных. Это делает меня менее решительным. Каково твое мнение?

— hengxin

Думаю, лучше посмотреть, как там реализована синхронизация. Но это очень интересная ссылка. - что я имею в виду, это не естественная особенность системы. Это должно быть добавлено к этому.

— AJed

В общем, вы не должны давать в качестве ссылки википедию. Я только что прочитал эту статью в Википедии: она довольно неполная и неорганизованная; это также может сбить с толку.

— августа

5

Одна из причин, по которой проблемы консенсуса важны, заключается в том, что они очень просты и являются своего рода универсальными проблемами для распределенных вычислительных систем.

Если мы можем решить консенсус в асинхронной распределенной системе, мы можем использовать его для линеаризации действий над общими объектами и получения линеаризуемости для общих объектов.

Для простоты, сколько проблем вы можете придумать, какие из них проще, чем согласиться с ценностью?

Результат невозможности достижения консенсуса в (чистых) асинхронных распределенных системах говорит нам о том, что мы не можем решить проблемы, которые хотим решить в (чистых) асинхронных распределенных системах, без каких-либо дополнительных «вещей». Это приводит к асинхронным моделям, в которых мы можем решать консенсус, например, рандомизированные алгоритмы, детекторы ошибок, модели частичной синхронизации и т. Д.

Это также является причиной того, что на практике алгоритмы, которые решают консенсус, такие как Paxos Лампорта, Chubby от Google, Apache ZooKeeper и совсем недавно Raft, являются ядром распределенных систем, где мы часто хотим реплицировать состояние среди серверов.

— Кава
источник

0

Я хотел бы только добавить, что характер вычислений все более распределяется по стеку: многие ЦП, многие процессы на машине, многие машины, подключенные к локальным сетям, многие локальные сети, подключенные к сетям.

Это делает проблему общего (распределенного / глобального) состояния первостепенной - каждый алгоритм принимает определенное состояние, и если вычисления должны выполняться более чем в одном месте, то это состояние также должно быть распределено.

Влиятельные статьи ( Paxos , и совсем недавно Raft ) в этой области были опубликованы после цитируемой вами статьи. Оба решают вопросы консенсуса при наличии некоторых неудач.

Византийских ошибок можно избежать в распределенных системах, используя несколько подходов.

Взгляните на статью в Википедии о византийской терпимости к ошибкам .

— diginoise
источник

Результат невозможности FLP применяется даже при настройке самого основного сбоя (краха), поэтому я не уверен, в чем смысл параграфа об избежании византийских неудач. Обратите внимание, что если у нас нет сбоев, то достичь консенсуса довольно просто: один фиксированный процесс передает свое значение, и каждый процесс принимает это значение сразу после его получения.

— Каве