Гіпотетичний протокол: Як розподілені системи поширюють інформацію як епідемія

Основний механізм: Стиснення, Витягування та Стиснення-Витягування через Gossip

Кола Ігре — це, здавалося б, дуже проста річ. Кожен вузол підтримує локальну таблицю, яка описує те, що він вважає за належне щодо кластера: які вузли існують, їх адреси, лічильник серцебиття або номер версії, а також іноді застоповерхневий стан. У фіксовані проміжки часу вузол вибирає невеликий випадковий набір сусідів, часто лише один чи три, і ініціює обмін. Існує три поширені стратегії обміну. При Стисненому Gossip ініційовальний вузол просто надсилає свій поточний стан вибраним сусідам, які зливаються з ним у своїх записах. При Витягуванні ініційований вузол замість цього запитує у сусіда, що він знає, та зливає відповідь локально. Стиснення-Витягування — це обмін станом між двома вузлами в один цикл подорожі, який найшвидше збігається, оскільки кожен контакт поширює інформацію обома способами одночасно, а не одним. Більшість виробничих систем, включно з Cassandra, використовують варіант Стиснення-Витягування, оскільки він мінімізує кількість раундів, необхідних для повного збігу. Випадковий вибір сусідів є ключовим, не випадковим. Якщо кожен вузол завжди спілкувався б із одним і тим же фіксованим сусідом, інформація поширювалася б повільним, передбачуваним ланцюгом, і одна зла зв’язка могла б розділити кластер на групи, які ніколи не чули б одне про одного. Випадковий вибір означає, що з високою ймовірністю кожен вузол можна досягти через багато різних шляхів, тому відмова будь-якого окремого зв’язку або вузла майже не сповільнює поширення. Кожен вузол також зазвичай порівнює номери версій або часові мітки під час обміну, щоб коли два вузли спілкуються, їм потрібно лише передавати відмінності, а не весь їхній табличний стан, що утримує витрати на пропускну здатність кожного раунду невеликими навіть при великому розмірі кластера.

Вибухоподібне розповсюдження: Чому логарифмічне збіжнення має значення

Причина, чому протоколи гоп-розмови масштабуються так добре, однакова математика, яка робить епідемії та губні чутки швидким поширенням: вибухоподібне зростання. Припустимо, що один вузол дізнається нову інформацію, наприклад, про відмову іншого вузла. У першому раунді він повідомляє одному випадковому сусіду, тому два вузли тепер знають. У другому раунді обидва ці вузли кожного контактують з новим випадковим сусідом, тому до чотирьох вузлів може дійти інформації. У третьому раунді до восьми вузлів може дійти інформації і так далі. Це означає, що кількість сповільнених вузлів зростає як 2 в степені від числа раундів, тому кількість раундів, необхідних для сповіщення всіх n вузлів кластера, становить лише пропорційну величину логарифму n. Додавання розміру кластеру з десяти тисяч вузлів до двадцяти тисяч додає лише один додатковий раунд до повного збігу, а не подвоює час. Це логарифмічне масштабування – властивість, яка робить гоп-розмови привабливими для дуже великих кластерів, де централізований трансилятор повинен був би встановити прямий зв’язок з кожним вузлом окремо, споживаючи пропускну здатність та координаційні витрати, які лінійно зростають із розміром кластера. З гоп-розгою кожен вузол виконує однакову невелику роботу за раунд незалежно від того, скільки загалом вузлів у кластері, оскільки він говорить лише з кількома випадковими сусідами замість усіх. Реальні розгортання налаштовують кількість одночасних контактів (fan-out) та інтервал між раундами, щоб збалансувати швидкість збіжності та мережевого шуму. Більша кількість одночасних контактів поширює інформацію швидше, але збільшує фоновий трафік, а менша – дешевша, але займає більше часу для досягнення всіх, тому оператори обирають значення, що відповідають розміру кластера та толерантності до застарілості інформації.

Групова Членність та Виявлення Відмов

Одна з найпоширеніших застосувань гучного обговорення – це забезпечення того, щоб кожна вузол був у курсі того, які інші вузли є в групі, і чи вони ще живі, проблема відома як управління членством. Місцева таблиця кожного вузла містить лічильник серцебиття для кожного сусіда, про який він знає. Коли вузол обговорює, він ділиться найвищим значенням серцебиття, яке він бачив для кожного сусіда. Якщо серцебиття вузла B для вузла C не збільшилося після кількох раундів і перевищує час підозри, інші вузли починають підозрювати, що вузол C вийшов з ладу, навіть якщо жоден центральний сервіс здоров’я не опитував його безпосередньо. Системи, такі як Consul та Cassandra, використовують удосконалення цієї ідеї, такі як родина протоколів SWIM або виявник відмов Phi Accrual, які призначають безперервний бал підозри на основі того, як давно не було видно серцебиття, замість жорсткого бінарного значення «вийшов з ладу» чи «живий», зменшуючи хибні позитивні результати через тимчасові мережеві затримки. Оскільки підозра поширюється через гучне обговорення так само, як і інформація про членство, весь кластер збігається до узгодженого перегляду того, хто вільний, а хто ні, протягом невеликої кількості раундів без необхідності для будь-якого вузла окремо контактувати з кожним іншим вузлом. Коли новий вузол приєднується до кластера, він зазвичай звертається до одного або кількох початкових вузлів для розгортання, дізнається поточний таблицю членства та стає активним обговорювачем, поширюючи новини про свій власний прихід назовні через той самий експоненційний процес. Цей децентралізований підхід гарантує, що членство в групі залишається точним і актуальним навіть тоді, коли вузли додаються, видаляються або виходять з ладу, без необхідності будь-якому координатору підтримувати основний список.

Анти-ентропія: Відновлення узгодженості реплік

Гістові протоколи також виконують другу, пов’язану задачу – антиентропію, яка полягає у виявленні та усуненні розбіжностей між репліками, що зберігають однакові дані. У реплікованих базах даних, таких як Cassandra та DynamoDB, декілька вузлів містять копії одних і тих самих рядків або пар ключів-значень, щоб система продовжувала працювати навіть тоді, коли деякі репліки тимчасово недоступні. З часом репліки можуть відхилятися від узгодженості через мережеві розділи, втрачені запису чи вузли, які ненадовго були вимкнені. Якщо цю розбіжність не усувати, це дозволить застарілим або відсутнім даним існувати безперервно. Антиентропійний гісто періодично порівнює стан, що зберігається в двох вузлах, та відновлює будь-які розбіжності, зводячи репліки до узгодженості без необхідності центральної служби згортання. Поширеною та ефективною технікою для цього порівняння є Merkle tree – ієрархічна структура хешів, де кожен лист хешу підсумовує невеликий діапазон даних, а кожний батьківський хеш підсумовує своїх дітей. Два вузли можуть порівняти корені Merkle tree; якщо вони збігаються, репліки вже ідентичні, і передавати дані не потрібно взагалі. Якщо корені відрізняються, вузли рекурсивно порівнюють хеші дітей, щоб точно визначити, який невеликий діапазон даних насправді відрізняється, і лише цей невеликий діапазон потрібно передати та виправити. Це дозволяє антиентропії масштабуватися до величезних наборів даних, оскільки дві репліки, що містять мільярди записів, часто можуть підтвердити свою узгодженість або визначити невеликий діапазон, де вони розійшлися, обмінюючись лише кількома хеш-значеннями замість сканування та передачі всього набору даних.

Відмовостійкість, Масштабованість та Компроміс Міжзвертання та Послідовності на Випередження

Гірсовані протоколи цінуються в розподілених системах завдяки тому, що вони не мають єдиної точки відмови. Централізований трансир – це вузол і недолік: якщо він вийде з ладу, кожна залежна вузла одночасно буде відрізана від оновлень, а його мережеві з’єднання та обчислювальна потужність повинні масштабуватися лінійно з кількістю обслуговуваних вузлів. Гірсовані протоколи не мають слабкості. Оскільки будь-який вузол може спілкуватися з будь-яким іншим, втрата окремих вузлів або навіть значної частини кластера все ще залишає достатньо живих шляхів для поширення інформації через решту вузлів. Протокол поступово деградує замість того, щоб відмовлятися повністю, і ця стійкість, у поєднанні з попереднім постійним навантаженням на вузол, пояснюють, чому гірсовані протоколи комфортно масштабуються до кластерів тисяч машин, де централізоване координування було б непрактичним. Ця стійкість має реальну вартість, відому як поступова послідовність. Оскільки інформація потребує кількох раундів гірсованого спілкування, пропорційного розміру кластера, щоб досягти кожного вузла, завжди буде короткий період після оновлення, коли різні вузли не погоджуються щодо поточного стану. Вузол, який нещодавно приєднався або клієнт, що звертається до вузла, який ще не почув останній гірсований протокол, може бачити трохи застарілі дані на секунди або кілька секунд, залежно від обраного інтервалу та розповсюдження. Системи, яким потрібен кожен прочитаний запит, щоб відображати останні записи, які називають сильною послідовністю, зазвичай не можуть покладатися лише на гірсовані протоколи для цього гарантування. На практиці інженери свідомо приймають цю невелику, обмежену затримку, оскільки альтернатива – централізований трансир з сильною послідовністю, жертвувала б саме стійкість до відмов і горизонтальну масштабованість, які зробили гірсовані протоколи вартими вибору для кластерної приналежності, виявлення відмов та ремонту анти-ентопії в першу чергу.

Frequently asked questions

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте Gossip Protocol: How Distributed Systems Spread Information Like an Epidemic і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.