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

Минулого тижня я знову читав розписку Леслі Лампорт 1982 року конференції, яку він дав про вирішені проблеми, нерозв’язані проблеми та непроблеми в паралельній валюті . Папір легко читається, але однією з речей, на які я задумався, є наступне твердження:

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

Мені хотілося б знати, чи відповіли на це питання у випадку розподілених систем.

Чи існує набір канонічних проблем із розподіленими системами, з яких можна звести всі можливі проблеми розподіленої системи? Що це за канонічний список?

Якщо немає канонічного списку, який є поточний перелік проблем та які скорочення існують?

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

Якщо можливо, я б хотів, щоб відповіді містили посилання на опублікований документ / книгу, що підтверджує його твердження :)

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

Я не знаю про такий опублікований перелік проблем.

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

Фактична модель, що знаходиться під рукою, часто передбачає зовсім інший характер питання. (Див. [1] для більш детальної розробки цих підспільнот у розподілених обчисленнях.) У моделях, близьких до безвідмовної синхронної моделі, дослідники часто розглядають складність локальних обчислень, наприклад, "Який час і складність повідомлення для обчислення забарвлення вершин? "$2$

З іншого боку, дивлячись на невдачі, питання більше стосуються питань вирішуваності на кшталт "Чи вирішується консенсус у цій моделі?" або "Чи можемо ми реалізувати цей фантазійний детектор несправностей під цими припущеннями?"

Якщо немає канонічного списку, який є поточний перелік проблем та які скорочення існують?

Існує багато прикладів таких скорочень у певних моделях розподілених обчислень, я обмежу свою відповідь наступними 2:

Локальні обчислення в (безвідмовної) синхронній моделі

[2] показують зменшення між багатьма проблемами оптимізації, наприклад, Мінімальний домінуючий набір, Максимальний незалежний набір (MIS), Максимальне співпадіння (ММ) та Мінімальний крик вершин (MVC): Зокрема, [2] показують нижню межу , де - розмір мережі, а - максимальний ступінь, для обчислення постійного наближення MVC. З цього випливає та сама межа для обчислення ММ, оскільки будь-яке максимальне співпадіння є також -приближенням MVC. Виходячи з цього, ви також отримуєте обмеження для обчислення МІС, оскільки для обчислення ММ можна використовувати MIS-алгоритм , імітуючи виконання на лінійному графіку.$\Omega(\sqrt{\log n} + \log\Delta)$$n$$\Delta$$2$$A$$A$

Асинхронна модель з аварійними аваріями

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

Наприклад, припускаючи доступ до детекторів відмов [3], виникає класифікація проблем, переглядаючи потужність відповідного детектора несправностей. Ми говоримо , що відмова детектора є слабким детектором несправності для завдання , якщо для будь-якого детектора відмови для , ви також можете реалізувати .$S$ $P$$T$$P$$S$

Використовуючи це співвідношення, можна визначити завдання як складніше , ніж проблеми , якщо слабкий детектор несправності для вирішення може реалізувати найслабший детектор відмови для вирішення . Нещодавно було показано, що кожна проблема має найслабший детектор несправностей [4]; зауважте, що [4] є екзистенційним результатом. Для деяких проблем, наприклад, консенсусу, відомий найслабший детектор несправностей [5], тоді як для інших проблем, наприклад, узгодження, найслабший детектор несправностей все ще відкритий [6].$P$$Q$$P$$Q$$k$

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

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

[1] П'єр Фройньо: Розподілені обчислювальні складності: ви залежні від волів чи одержимі наскаром? PODC 2010. http://doi.acm.org/10.1145/1835698.1835700

[2] Фабіан Кун, Томас Москіброда, Роджер Ваттенхофер: Місцеві обчислення: нижня і верхня межі. CoRR abs / 1011.5470 (2010) http://arxiv.org/abs/1011.5470

[3] Тушар Діпак Чандра, Сем Туег: Ненадійні детектори відмов для надійних розподілених систем. J. ACM 43 (2): 225-267 (1996). http://doi.acm.org/10.1145/226643.226647

[4] Прасад Джаянті, Сем Туег: Кожна проблема має найслабший детектор несправностей. PODC 2008: 75-84. http://doi.acm.org/10.1145/1400751.1400763

[5] Тушар Діпак Чандра, Вассос Хадділакос, Сем Туег: найслабший детектор відмов для вирішення консенсусу. J. ACM 43 (4): 685-722 (1996) http://doi.acm.org/10.1145/234533.234549

[6] Мішель Рейнал: Детектори несправностей вирішити асинхронну угоду k-Set: короткий проміжок останніх результатів. Вісник EATCS 103: 74-95 (2011) http://albcom.lsi.upc.edu/ojs/index.php/beatcs/article/view/61