Senior Distributed Systems Engineer English: Consensus, CRDTs, and CAP Theorem Vocabulary (англійською)
Consensus, Raft vs Paxos, split-brain, CRDT, CAP theorem — англійський словник для старших інженерів розподілених систем в оглядах дизайну і обговореннях архітектури.
Розподілені системи мають словник, який відокремлює інженерів, які працювали в області від тих, хто читав про це. У проектних оглядах, архітектурних обговореннях і пост-мртових записах, старші інженери використовують цю мову точно - і неточне використання відразу ж помітно для колег.
У цій статті описано словниковий запас, який вам потрібен для впевненого обговорення розподілених систем англійською мовою, з використанням колокації і шаблонів речень, які використовують носії рідної мови.
Консенсусні алгоритми
** Консенсус ** у розподілених системах означає згоду — зокрема, здатність кластера вузлів погоджуватися щодо єдиного значення або рішення, навіть якщо деякі вузли не працюють або повідомлення затримуються.
«Головна проблема розподіленого консенсусу полягає в тому, щоб отримати вузли, щоб погодитися на порядок операцій без єдиного джерела правди.»
** Алгоритм консенсусу ** є протоколом, який досягає цієї згоди. Два з них, які ви почуєте майже в кожній дискусії про розподілені системи, це Raft і Paxos.
** Raft ** був розроблений для того, щоб його було легше зрозуміти, ніж Paxos. Він використовує ** лідер ** вузол, який координує реплікацію журналу. Якщо лідер програє, то на виборах обирається новий. Інженери часто кажуть, що Raft є * більш доступним * або * більш зрозумілим *, ніж Paxos.
«Ми обрали etcd над ZooKeeper частково тому, що etcd використовує Raft, який легше обґрунтувати, коли ви зневаджуєте проблему виборів лідера»
** Paxos ** — це оригінальний алгоритм консенсусу, запропонований Leslie Lamport. Це номінально важко реалізувати правильно. Інженери, які працюють з ним, часто використовують фразу * “зрозуміти Paxos правильно” *, щоб описати цю складність.
«Multi-Paxos є тим, що більшість виробничих систем насправді реалізують, а не версією з одним указом з оригінальної статті»
** Кворум ** це мінімальна кількість вузлів, які повинні погодитися, щоб рішення було чинним. У кластері з п’яти вузлів, кворум зазвичай становить три.
“Ми можемо терпіти до двох невдач вузлів і все ще підтримувати кворум. Втратити третій, і кластер стає недоступним, а не непослідовним.”
Недоліки модифікації
** Розділений мозок ** — це сценарій аварії, у якому мережевий розділ спричиняє дві частини кластера, які працюють незалежно, кожна з яких вважає, що вона є єдиною авторитетною. Обидві сторони можуть прийняти запис, що призведе до конфліктного стану.
“Цей інцидент був класичним сценарієм розділення мозку. Мережевий розділ тривав 90 секунд, і обидва первинні приймали записи. Ми витратили шість годин на примирення розбіжних даних»
Використовуйте cause, trigger, result in, або lead to з split-brain: “Несправність асиметричної мережі викликала стан split-brain.”
Модель послідовності
Теорема CAP (Consistency, Availability, Partition tolerance) стверджує, що розподілена система може гарантувати тільки дві з трьох властивостей одночасно, коли відбувається мережевий розділ. Інженери кажуть, що система є CP (послідовною і толерантною до розділів) або AP (доступною і толерантною до розділів).
«Cassandra є системою AP — вона приоритизує доступність над сильною послідовністю. Якщо вам потрібні лінійні читання, Cassandra — неправильний вибір»
«Люди часто неправильно застосовують CAP. Реальний компроміс на практиці є послідовність проти затримки, а не послідовність проти доступності»
** Послідовність можливих змін ** означає, що за достатньо тривалого часу без нових оновлень всі репліки будуть збігатися до одного значення. Процеси читання можуть повертати застарілі дані.
«Корзинка з часом стає послідовною — якщо два клієнти додають товари одночасно, обидва додавання з часом будуть відображені, але є вікно, де один клієнт не побачить зміни іншого»
** Сильна послідовність ** (або * лінійність *) означає, що кожне читання відображає останній запис, так, ніби система є єдиним вузлом. Це більш дорого.
“Ми потребуємо сильної послідовності для балансів рахунків. Ми не можемо показати користувачеві застарілий баланс до того, як вони розпочнуть платіж»
Часописи і брошури
** CRDT ** (Conflict- free Replicated Data Type) — це структура даних, розроблена таким чином, що одночасні оновлення з декількох вузлів завжди можна об’ єднати без конфліктів. Математичні властивості структури гарантують, що всі репліки зрештою збігатимуться в один і той же стан.
«Ми використовуємо CRDT для редактора документів для співпраці. Незалежно від того, скільки клієнтів редагують одночасно, стан завжди збігається детерміністично»
«CRDT не є вільними — вони накладають обмеження на модель даних. Контр-CRDT може тільки збільшувати, ніколи не зменшувати, без втрати гарантії безконфліктності»
Вимовляйте CRDT як окремі літери: “C-R-D-T.”
** Векторний годинник ** це механізм для відстеження причинного порядку подій у розподілених вузлах. Кожен вузол підтримує лічильник, а вектор лічильників у всіх вузлах показує, які події відбулися раніше за інші.
“Ми використовуємо векторні годинники, щоб виявити порушення причинно-наслідкового порядку в журналі аудиту. Якщо векторний годинник події B не домінує над подією A, ми знаємо, що вони одночасні»
** Lamport timestamp ** є простішим логічним годинником (один лічильник), який встановлює часткове впорядкування подій між вузлами — достатньо для багатьох випадків використання, де повне причинне відстеження не потрібно.
«Временові штампи Лампорта дають нам послідовний порядок відтворення подій, але вони не говорять нам про причинність — дві події з різними штампами часу все ще можуть бути одночасними»
Фрази для дизайн-оглядів і архітектурних дискусій
Використовуйте ці ключові слова під час інтерв’ ю з розробниками систем, на радах з перегляду архітектури і технічних оглядах:
- “За розділенням, ця конструкція належить до категорії AP — ми допускаємо застарілий зчитування для підтримки доступності.”
-
- “Риск розщеплення мозку є головною проблемою тут. Нам потрібно забезпечити, щоб кворум запису був строго виконаний.»*
- “Ми використовуємо CRDT для індикаторів присутності — він обробляє одночасні оновлення з декількох пристроїв без координації.”
- “Рафт дає нам простішу ментальну модель для вибору лідерів, але нам все ще потрібно уважно роздумувати про числа термінів і репродукцію журналу.”
- “Посмертное обследование выявило корневую причину как неправильную конфигурацию кворума - кластер принимал записи с подтверждением только одной реплики.”
Ключові слова
| Collocation | Example |
|---|---|
| achieve consensus | ”The algorithm achieves consensus in two rounds under normal conditions.” |
| maintain quorum | ”We cannot maintain quorum with fewer than three nodes.” |
| trigger a split-brain | ”The network partition triggered a split-brain condition.” |
| guarantee eventual consistency | ”The CRDT guarantees eventual consistency without coordination.” |
| reason about consistency | ”It’s easier to reason about consistency with Raft than with Paxos.” |
| tolerate node failures | ”The system tolerates up to two node failures without data loss.” |
Practice
Розглянемо будь- яку проблему проектування системи — розподілене сховище ключів і значень, таблицю лідерів або текстовий редактор для спільної роботи. Напишіть короткий абзац (від чотирьох до шести речень), у якому ви поясните вибір моделі несуперечності за допомогою словника, наведеного у цьому повідомленні. Включіть принаймні: одне посилання на теорему CAP, одну модель послідовності (eventual або strong) і один механізм (quorum, CRDT або vector clock). Прочитайте його вголос колегі або записайте його самостійно — чи звучить лексика природно, чи ви все ще перекладаєте у голові?
Навигація по нюансах: практичний підхід до термінології розподілених систем
Будьмо чесними - “консенсус”, “CRDT”, і навіть “теорема CAP” можуть звучати загрозливо, коли ви намагаєтеся побудувати міцну, масштабовану систему. Це не просто про те, щоб знати * визначення *; Це про розуміння того, як ці концепції перекладаються на реальні рішення під час перегляду коду, обговорення архітектури або розмов Slack. Часто молодші інженери використовують технічний жаргон неправильно, що призводить до плутанини і переробки. Як старший інженер, ваша роль не просто виправити їх - хоча це важливо - але ніжно керувати розмову до ясності і точності. Ключовим є впровадження цих концепцій у релевантні сценарії. Наприклад, при обговоренні «розділення мозку» під час перегляду дизайну, більш вплинувчим буде сказати: «Якщо ми не маємо сильного механізму консенсусу, існує ризик, що наша система може ефективно розділитися на дві незалежні частини, що призведе до невідповідностей даних - уявіть один сервер, який все ще вважає себе основним, а інший повністю ігнорує його».
Крім того, розпізнавання контексту дискусії драматично впливає на спілкування. Під час перегляду коду, замість того, щоб просто сказати « Нам потрібен консенсус », ви можете сказати: « Давайте переконаємося, що ця зміна відповідає нашій загальній стратегії для послідовності даних — конкретно, як ми обробляємо потенційні мережеві розділи і підтримуємо єдине джерело правди. » Повідомлення Slack, що пояснює складне архітектурне рішення, може починатися з: « Роздумуючи про потенціал тимчасових відключень мережі … CRDT здається, що тут добре підходить, тому що … » Цей підхід показує, що ви не просто кидаєте навколо модних слів, а застосовуєте їх до реальної проблеми. Ключовим є завжди прагнути до * дійсного * спілкування, перекладаючи теоретичні концепції на практичні роздуми. Також важливо визнати обмеження кожної концепції - теорема CAP не є чарівною кулею, і розуміння того, коли пріоритет доступності над послідовністю (і навпаки) є ключовим.
Щоб проілюструвати цю точку зору, розглянемо простий приклад з використанням etcd, розподіленого сховища ключів- значень, яке часто використовується для досягнення консенсусу:
# Example etcd command - simulating a raft protocol update
etcdctl set /my/key value="New Value" --fast-health --consistentЦе не тільки про саму команду; це про те, як ми * обговорюємо * її. Ми могли б говорити про необхідність реплікації, виборів лідерів і перевірок послідовності даних - всі елементи безпосередньо пов’язані з такими поняттями, як консенсус і CRDT. Команда etcdctl є матеріальним представленням абстрактних ідей, які ми обговорюємо. Це конкретний інструмент, який втілює принципи проектування розподілених систем.
В кінцевому підсумку, оволодіння цим словником не стосується запам’ятовування; це стосується розробки спільної мови для вирішення складних завдань в інженерії розподілених систем - побудованої на розумінні, контексті і ясному спілкуванні.