Чому проблема консенсусу настільки важлива при розподілених обчисленнях?

19

У розподілених обчисленнях проблема консенсусу, як видається, є однією з центральних тем, що привернула інтенсивні дослідження. Зокрема, документ "Неможливість розподілу консенсусу за один несправний процес" отримав 2001 р. Впливову паперову премію PODC .

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

Будь-які довідки чи експозиції були б дуже корисними.

reference-request big-picture dc.distributed-comp

— хенксин
джерело

18

Папір, яку ви згадуєте, важлива з двох причин:

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

Програми

Одним із важливих застосувань проблеми консенсусу є обрання координатора чи керівника у невідповідному середовищі для ініціювання деяких глобальних дій. Алгоритм консенсусу дозволяє зробити це на ходу, не фіксуючи заздалегідь "суперноду" (що вводило б одну точку відмови).

Іншим додатком є підтримка послідовності в розподіленій мережі: Припустимо, у вас є різні сенсорні вузли, що контролюють одне і те ж середовище. У випадку, коли деякі з цих сенсорних вузлів виходять з ладу (або навіть починають надсилати пошкоджені дані через апаратну помилку), протокол консенсусу забезпечує надійність проти таких помилок.

(*) Запуск розподіленого алгоритму - це послідовність конфігурацій. Конфігурація - вектор локальних станів процесів. Кожен процес виконує детерміновану машину стану. Будь-який правильний алгоритм консенсусу повинен врешті-решт дійти до конфігурації, де кожен процес вирішив (безповоротно) одне й те саме вхідне значення. Конфігурація становить - валентний якщо, незалежно від того , що робить противник, всі можливі розширення призводять до значення рішення від . Аналогічно ми можемо визначити - валентність . Конфігурація є двовалентною, якщо обидва рішення доступні з $C$ $1$ $C$ $1$ $0$ $C$ $C$ (яка з двох буде досягнута, залежить від супротивника). Зрозуміло, що жоден процес не може вирішитись у двовалентній конфігурації , оскільки в іншому випадку ми отримуємо протиріччя згоди! Отже, якщо ми можемо побудувати нескінченну послідовність таких двовалентних конфігурацій, ми показали, що алгоритм консенсусу в цьому налаштуваннях не існує. $C$

— Петро
джерело

2

@AJed Як доповнення: я ознайомився із синхронізацією паперу Морісом Херліхі і тепер можу представити ще один великий теоретичний вплив проблеми консенсусу. Використовуючи ідею консенсусного числа , можна показати, що існує нескінченна ієрархія примітивів синхронізації, така що жоден примітив на одному рівні не може бути використаний для безперебійної реалізації будь-яких примітивів на більш високих рівнях. Простіше кажучи, проблема консенсусу є єдиною теорією щодо визначення відносної потужності операцій примітивної синхронізації. Це елегантно.

— hengxin

1

У мене є певні труднощі в розумінні доказу результату неможливості FLP. Не могли б ви дати мені підказки? Будь ласка, зверніться до [FLP proof] ( stackoverflow.com/q/15131730/1833118 ). Спасибі.

— hengxin

"де кожен процес вирішив" може бути, "де кожен правильний процес вирішив"?

— nbro

Ви повинні пояснити, хто є противником "незалежно від того, що робить противник".

— nbro

"усі можливі розширення C", що ви маєте на увазі під "розширенням C"? Що таке розширення конфігурації взагалі?

— nbro

7

Це показує, що не існує відмовного детермінованого алгоритму. Досить сильний теоретичний результат, який змушує дизайнерів по-різному ставитися до відмовостійкості, деякі з яких - синхронізація та рандомізація.

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

Для ознайомлення перегляньте посилання Вікіпедія . Перевірте також цей блог щодо практичних застосувань

— AJed
джерело

1

Так, я віддаю перевагу рандомізації синхронізації. Навколишнє середовище, в якому розподілені обчислювальні машини грає дуже погано в сенсі асинхронізації, необмеженої затримки, несподіваного виходу з ладу і занадто багато недетермінованих. Поки це не ідеально, чому б нам не використати рандомізацію, досягнувши певних гарантій, уникаючи занадто великої складності.

— хенксин

1

Говорячи про синхронізацію, я просто не люблю припущення в теорії . Однак у промисловості синхронізація або часткова синхронізація застосовуються часто. Наприклад, Spanner від Google - це глобально розподілена синхронно-реплікувана база даних. Це робить мене менш рішучим. Яка ваша думка?

— hengxin

Я думаю, краще подивитися, як там реалізована синхронізація. Але це дуже цікава довідка. - що я маю на увазі, це не є природною рисою системи. До нього треба додати.

— AJed

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

— nbro

5

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

Якщо ми можемо вирішити консенсус у розподіленій асинхронній системі, ми можемо використовувати його для лінеаризації дій на спільних об'єктах та отримання лінійної можливості для спільних об'єктів.

Для простоти, скільки проблем, на вашу думку, є простішими, ніж домовитись про значення?

Результат неможливості консенсусу в (чистому) розподілених системах асинхронізації говорить про те, що ми не можемо вирішити проблеми, які ми хочемо вирішити в (чистих) розподілених системах асинхронізації, без додаткових "матеріалів". Це призводить до асинхронних моделей, де ми можемо вирішити консенсус, наприклад, рандомізовані алгоритми, детектори несправностей, моделі часткової синхронії тощо.

Це також причина того, що на практиці алгоритми, що вирішують консенсус, такі як Paxos Lamport, Chubby Google, Apache ZooKeeper та нещодавно Raft, лежать в основі розподілених систем, де ми часто хочемо копіювати стан серед серверів.

— Каве
джерело

0

Я хотів би лише додати, що характер обчислень стає все більш розповсюдженим через стек: багато процесорів, багато процесів на машині, багато машин, підключених локальними мережами, багато локальних мереж, підключених міжмережами.

Це робить проблему загального (розподіленого / глобального) стану першочерговим - кожен алгоритм передбачає певний стан, і якщо обчислення слід проводити в більш ніж одному місці, то стан також має бути розподіленим.

Впливові статті ( Paxos та нещодавно Raft ) у цій галузі були опубліковані після роботи, яку ви цитуєте. Обидва вирішують питання консенсусу за наявності певних невдач.

Візантійських помилок можна уникнути в розподілених системах, використовуючи кілька підходів.

Подивіться на запис у Вікіпедії про толерантність візантійських вин .

— дигіноз
джерело

Результат неможливості FLP застосовується навіть у встановленні найпростішого провалу (аварії), тому я не впевнений, який сенс параграфа щодо уникнення візантійських невдач. Зауважте, що якщо у нас немає збоїв, то консенсус досить простий: один фіксований процес передає його значення, і кожен процес визначає це значення, як тільки воно буде отримане.

— Каве