Цинні реплікації: Простіший спосіб підтримки узгодженості розподілених даних

Фіксовані Лінії, а не Мережі

Основна ідея реплікації ланцюгом є структурною: реплікарські сервери розташовані у фіксованій лінійній ланцюзі, а не в повністю з’єднаній мережі peer-to-peer. Кожен сервер знає точно двох сусідів – попереднього та наступного, за винятком кінцевих точок. Перший сервер називається «головним», а останній – «хвостовим». Усі інші сервери розташовані десь посередині, тихо передаючи дані далі. Це свідомий відхід від систем, таких як Dynamo-стиль кворумної реплікації, де будь-який реплікар міг спілкуватися з будь-яким іншим реплікаром, а клієнти могли звертатися до кількох реплікарів на одну операцію. У реплікації ланцюгом топологія сама по собі кодує протокол. Оскільки порядок серверів фіксований і відомий усім, немає потреби динамічно визначати, кому потрібно спілкуватися з ким для певної операції – це вирішується один раз, коли ланцюг налаштовано, і залишається вирішеним до тих пір, поки щось не вийде з ладу. Ця структурна простота робить решту протоколу такою легкою для розуміння: докази правильності щодо порядку та узгодженості спрощуються до простих тверджень про положення в ланцюзі, а не про те, який набір реплікарів випадково відповів на запит кворуму.

Операції поширюються від голови до хвоста ланцюга

Усі запити на запис надходять у систему в одній точці – в голову ланцюга. Клієнт ніколи не записує дані безпосередньо на середні сервери або на хвіст; запис відбувається лише через голову. Коли голова отримує оновлення, вона застосовує його до власного локального копію даних і потім відправляє повідомлення про оновлення наступному серверу в ланцюзі. Цей сервер робить те ж саме: застосовує оновлення локально та відправляє його далі. Це повторюється сервером за сервером, поки оновлення не досягне хвоста – останнього зв’язку в ланцюгу. Лише після того, як хвіст застосував оновлення, клієнт отримує підтвердження про завершення запису. Це означає, що запис вважається стійким та видимим лише тоді, коли він поширився через усі репліки ланцюга в строговому порядку. Немає можливості, щоб два сервери застосовували оновлення в різному порядку відносно один одного, оскільки сам ланцюг забезпечує єдиний, повний порядок поширення. Порівняйте це з записами на основі кворуму, де координатор надсилає оновлення кільком реплікам паралельно та чекає підтвердження більшістю; репліки можуть застосовувати оновлення в дещо різних послідовностях, якщо не буде додаткового механізму, наприклад, номерів версій або векторних годинників, який їх сортує. Chain replication обходить цю проблему з самого початку.

Читання з Хвостового Резервування Гарантує Консистентність

Так само, як записи мають один фіксований пункт призначення, читання мають один фіксований вихідний пункт: хвіст. Усі запити на читання обслуговуються виключно з хвостового сервера, ніколи з головного або будь-якого середнього сервера. Це одне рішення забезпечує сильний консистентність гарантію ланцюжкового реплікування, формально відому як лінійну реалізація. Оскільки кожен запис повинен повністю поширюватися по всьому ланцюгу та застосовуватися на хвості перед тим, як буде підтверджено, найновіший, повністю відремонтований стан системи завжди є копією даних у хвостового сервера. Клієнт, читаючи з хвоста, ніколи не бачить застарілої або частково застосованої оновлення та ніколи не бачить двох різних значень для одного ключа залежно від того, який реплікат він випадковим чином запитав. Це різко контрастує із системами на основі кворуму, де читання може потребувати зв’язку з кількома реплікатами, порівняння часових міток або векторів версій і вирішення конфліктуючих значень перед поверненням відповіді клієнту. Ланцюгове реплікування не потребує жодної цієї логіки узгодження. Шлях читання майже безглуздо простий: запитати хвіст, отримати відповідь, зроблено. Торгівля полягає в тому, що весь навантаження з читання концентрується на одному сервері, тому масштабування пропускної здатності виглядає інакше, ніж у системах на основі кворуму, але історія про консистентність стає набагато легшою для пояснення та перевірки.

Чому це Перевершує Розуміння щодо Кворумів

Системи, такі як Paxos та Raft, досягають стійкості до збоїв і узгодженості шляхом голосування: значення вважається зафіксованим лише тоді, коли більшість вузлів погоджуються, а визначення того, хто дозволений пропонувати значення, потребує протоколу вибору лідера з умовами, бюлетенями або епохами. Розуміння того, чому ці протоколи є правильними, зазвичай передбачає ретельні аргументи щодо перекриваючихся більшин і крайніх випадків щодо розбитих голосів чи конкуруючих лідерів. Chain replication йде кардинально іншим шляхом. Немає етапу голосування в жодному моменті, оновлення – це не щось, що повинно виграти більшість, а просто потік через визначену послідовність серверів. Також немає традиційного вибору лідера: ролі головного та хвостового вузла є лише позиціями у фіксованому порядку, а не чим-то, за що сервери змагаються за допомогою бюлетенів. Узгодженість – це властивість, яка виникає не спонтанно і не повинна доводитися через аргументи про перетин кворумів; вона безпосередньо випливає з того, що ланцюг забезпечує єдиний порядок записів та єдичне фіксоване місце для читання. Це робить chain replication значно легшим для інженерів розуміти, правильно реалізувати та відлагоджувати, коли щось піде не так, оскільки ментальна модель – це черга серверів, а не розподілений протокол голосування.

Обробка відмов головного, хвостового та середніх вузлів

Простота реплікації ланцюга природно поширюється на те, як вона обробляє відмови. Кожна ситуація відображає інтуїтивно зрозуміле відновлення. Якщо виходить з ладу головний вузол, наступний у ланцюгу стає новим головним, а клієнти перенаправляють свої записи туди. Якщо виходить з ладу хвостовий вузол, попередній у ланцюзі стає новим хвостом, і читання перенаправляються до нього. Це безпечно, оскільки цей вузол вже застосував усі оновлення, які застосував колишній хвіст, а також можливо, й більш нові. Якщо виходить з ладу вузол посередині ланцюга, ланцюг відновлюється шляхом безпосереднього підключення його двох сусідів один до одного, закриваючи проміжок, щоб оновлення продовжували передаватися від головного до хвоста без відключеного вузла. Жодне з цих відновлень не вимагає від виживших реплік голосувати щодо того, що сталося, або вести переговори про нову конфігурацію між собою. Замість цього все це координується зовнішнім менеджером конфігурації – компонентом, яким усі репліки довіряють для виявлення відмов і оголошення нової топології ланцюга. Це передає найскладнішу частину розподіленого консенсусу – узгодження членства групи – окремому, часто простішому підсистемі, який сам зазвичай будується з використанням меншого, присвяченого консенсусного сервісу. Самі сервери ланцюга залишаються простими, вони просто слідують будь-якій топології, яку вказує менеджер конфігурації.

Frequently asked questions

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

Усе, що вище, працює прямо у вашому браузері — відкрийте Chain Replication: A Simpler Way to Keep Distributed Data Consistent і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.