Словник для розподілених баз даних: консенсус, реплікація і розділення
Освоєння англійської мови щодо розподілених баз даних: консенсус, кворум, затримка реплікації, шардування, терпимість до розділів і теорема CAP. Точні терміни для інженерів сервера і платформи.
Розподілені бази даних мають словник, який легко зловживати. Слова, такі як consistency, availability і partition, мають тут певне значення — і не завжди те, що вони означають у повсякденній англійській мові. Цей посібник розповість про основні терміни, дієслова, які використовують інженери, і пастки мови, які ловлять носіїв мови, для яких мова не є рідною.
Теорема CAP: три слова, які ви повинні використовувати точно
Теорема ** CAP ** стверджує, що розподілена система може гарантувати лише дві з трьох властивостей, коли відбувається розділ мережі:
- ** Послідовність ** — кожне читання буде мати найновіший запис.
- ** Доступність ** — кожен запит отримує відповідь (не помилку).
- ** Допуск розділів ** — система продовжує працювати, незважаючи на відключення мережевих повідомлень між вузлами.
Класичної помилкою є висловлювання « CAP означає вибрати два ». Точніше кажучи: ** коли виникають розділи **, ви повинні обрати між послідовністю і доступністю — у справжній розподіленій системі допуск розділів не є обов’ язковим. Звучить вільно означає сказати:
“Під мережевим розділом, ця система надає перевагу доступності над послідовністю — це AP система. Він буде продовжувати обслуговувати читання, навіть якщо вони трохи ** застаріли **. ”
Словниковий запас: * stale read * (застарілі дані), * strong consistency *, * eventual consistency * (репліки збігаються з часом), * PACELC * (розширена теорема: else, торгова затримка проти послідовності).
Replication
** Реплікація ** означає зберігання копій даних на декількох вузлах. Умови:
- ** Лідер / наслідувач ** (також ** головний / реплікатор **) — вузол, який приймає записи проти копій.
- ** Синхронна проти асинхронної реплікації ** — чекати на підтвердження реплікації проти не чекати.
- ** Затримка реплікації ** — наскільки відстає відслідковуваний об’ єкт.
- ** Відновлення після аварії ** — підвищення підлеглого до лідерського статусу після смерті лідерського статусу.
- ** Розділений мозок ** — два вузли вважають, що вони є лідерами (серйозна помилка).
Колокацій дієслова:
- лідер ** копіює ** пише до послідовників
- Послідовник відстає / наздоганяє
- система ** підвищує ** копію і ** понижує ** старого лідера
- реплікація піки затримки під навантаженням
“Наша затримка реплікації під час імпорту досягла 30 секунд, тому репліки читання обслуговували старі дані. Ми зламали чисто, без розділеного мозку»
Вимова: replica є /ˈreplɪkə/ — акцент на першому складі, короткий e. Не “ре-пли-ка”
Консенсус и кворум
Коли декілька вузлів повинні погодитися на значення, вони запускають консенсусний алгоритм — Raft або Paxos. Ключеві терміни:
- ** Кворум ** — мінімальна кількість вузлів, які мають погодитися (зазвичай, більшість).
- ** Вибори лідерів ** — вибір координатора вузла.
- ** Затвердити ** — запис буде затверджено після того, як кворум підтвердить його.
- ** Лінійність ** — найсильніша послідовність: операції відбуваються миттєво, в порядку.
Колокацій:
- вузли досягають згоди / згодяться на значення
- запис ** підтверджується ** ** кворумом **
- кластер ** вибирає лідер**
- розділ втрачає кворум і стає лише для читання
“При п’яти вузлах, кворум становить три. Якщо розділ ізольовує два вузли, сторона меншості втрачає кворум і припиняє приймати записи, щоб уникнути розділення мозку»
Вимова: quorum звучить як /ˈkwɔːrəm/. Paxos звучить як /ˈpæksɒs/. Raft римується з «craft»
Розділення і шардування
Увага: « ** partition ** » має два значення у цьому полі — мережевий розділ (вище) і ** розділення даних **. Контекст роз’ яснює, але будьте обережні.
** Шардинг ** = розділення даних між вузлами, щоб кожен з них містив підмножину.
- ** ключ розділу / розділу ** — поле, яке визначає, у якому вузлі знаходиться рядок.
- ** Розділення за гешом проти діапазону ** — розподіл за гешом ключа проти діапазонів.
- ** Hot shard / hotspot ** — один шард отримує непропорційно багато трафіку.
- ** Перебалансування ** — пересування даних між осколками для вирівнювання навантаження.
- ** Перешарування ** — зміна схеми шарування (дорого).
“Ми shard by
customer_idвикористовуючи hash partitioning щоб уникнути hotspots. Один великий клієнт створив hot shard, тому нам довелося ребалансувати»
Незвичайне слово: дані * розділені * або * розділені * (розділені); у звичайній англійській мові їх не « розділено ». Скажіть “ми ** розділяємо дані за ** регіоном,” а не “ми розділяємо дані за регіоном.”
Трансакции в распределённом мире
- ** ACID ** — Атомність, Послідовність, Ізоляція, Тривалість (класичні гарантії для одного вузла).
- ** BASE ** — базово доступний, м’ який стан, можлива послідовність (розслаблена розподілена альтернатива).
- ** Двофазний затвердження (2PC) ** — протокол для затвердження транзакції між вузлами атомарно.
- ** Рівні ізоляції ** — * читання зафіксоване, повторне читання, серіалізація.*
- ** Похилий запис, фантомне читання, неправильне читання ** — аномалії, які дозволяють слабкі рівні ізоляції.
“Ми потребуємо серіалізованої ізоляції для реєстру, тому ми приймаємо затримку вартості. Все інше виконується на read committed
Розв’язання конфліктів
Коли репліки приймають записи незалежно, виникають конфлікти:
- ** Last- Write- Wins (LWW) ** — перемагає найновіший час (простий, може призвести до втрати даних).
- ** Векторні годинники ** — спостерігати за причинністю для виявлення одночасних записів.
- ** CRDTs ** (Conflict- free Replicated Data Types) — структури даних, які об’ єднуються автоматично.
- ** Tombstone ** — маркер, який записує вилучення, щоб воно поширювалося.
«Ми використовуємо CRDTs для спільного редактора, тому одночасні редагування зливаються без конфліктів, а не покладаючись на last-write-wins»
До / після: вільно говорить
** До: ** « Копія бази даних запізнюється, іноді дані є застарілими, і коли головна база даних зникає, ми змінюємо її на іншу. »
** Після: ** « **Затримка реплікації ** спричинила **застарілі читання ** на підписниках. Коли лідер зазнав невдачі, ми підвищили репліку за допомогою автоматичного переходу на інший сервер»
Швидкий словник
| Term | One-line meaning |
|---|---|
| Consensus / quorum | Nodes agreeing / the majority needed |
| Replication lag | How far a follower is behind |
| Failover | Promoting a replica to leader |
| Split-brain | Two leaders at once (bad) |
| Sharding | Splitting data across nodes |
| Hot shard | One shard overloaded |
| Eventual consistency | Replicas converge over time |
| Linearizable | Strongest consistency |
| CRDT | Auto-merging data structure |
Ключевые вещи
- CAP змушує зробити вибір між послідовністю і доступністю під розділом — сформулюйте це таким чином.
- Вивчати ** лідер/наслідник, відключення, затримка реплікації ** колокації холодно.
- « ** Розділ ** » означає дві речі — розділення мережі і розділення даних. Читати контекст.
- Використовуйте shard / partition як дієслова у ідіоматичному вигляді: « we shard by key. »
- Вимовляйте реплику, кворум, Паксос - это те слова, которые вы будете говорить чаще всего.
На практиці: Навігація нюансів в обговореннях розподілених систем
Будьмо чесними - технічні дискусії навколо розподілених систем можуть відчуватися… щільними. Навіть якщо ви розумієте основні поняття консенсусу, реплікації і розділення, переклад цього розуміння на чітку, точну англійську мову у команді може бути складним. Для не-рідних носіїв це особливо вірно. Це не просто про те, щоб знати визначення; це про те, щоб використовувати правильну фразу, щоб ефективно передати свої ідеї і уникнути непорозумінь.
Розглянемо такий сценарій: ви переглядаєте запит на збирання від колеги щодо нової можливості, яка вводить асинхронне повідомлення між службами. Під час перегляду з’ явиться коментар: « Затримка реплікації тут неприйнятна ». Хоча « затримка реплікації » є технічно правильним — це затримка між оновленнями, які застосовуються до реплік — це може звучати як обвинувачення і, можливо, здатися приголомшливим. Більш конструктивний підхід може бути, “Чи можемо ми дослідити, чому затримка реплікації в цьому конкретному шляху вище, ніж очікувалося? Можливо, ми могли б додати деякі показники щодо часу поширення даних, щоб краще зрозуміти вузьке місце. ” Зауважте, як оформлення проблеми як * розслідування *, а не як проблеми з роботою колеги робить її менш конфронтаційною і більш співпрацею. Аналогічно, сказати «допуск розділів» може бути неправильно інтерпретовано; замість цього, ви можете сказати «здатність системи продовжувати функціонувати, навіть якщо частини її не спрацьовують»
Інша поширена ситуація виникає в розмовах Slack при обговоренні викликів масштабування. Розробник може написати: « Нам потрібно розділити базу даних! » Ця фраза технічно правильна, але у ній бракує контексту. Краще сформулювати * чому * sharding необхідний - наприклад, “Враховуючи наш прогнозований ріст користувачів, ми повинні дослідити sharding клієнтських даних, щоб поліпшити продуктивність запиту і зменшити суперечки.” Крім того, при обговоренні досягнення консенсусу, пам’ятайте, що просто сказати “ми потребуємо кворуму” недостатньо. Замість цього, поясніть * що * ви намагаєтеся досягти з кворумом: “Ми повинні забезпечити кворум вузлів погоджуються на транзакцію до того, як вона буде зафіксована, гарантуючи послідовність даних.”
Нарешті, давайте поглянемо, як це перекладається на описи PR. Хороший опис буде чітко вказувати на мету і прийнятий підхід, використовуючи точну термінологію. Наприклад: «Ця PR реалізує асинхронну реплікацію подій з трьома вузлами кворуму для критичних оновлень, мінімізуючи час простою під час обслуговування системи»
Ось приклад використання etcd для керування перевірками стану кластера:
# Example etcd command to check node status
curl -s https://192.168.1.100:2379/healthz | jq .Ця проста команда демонструє практичне застосування розуміння таких термінів, як «кворум» - в цьому випадку, переконання більшості вузлів, що вони здорові, перед тим, як продовжувати з операціями.