Гарантії API etcd

etcd — це консистентне та надійне сховище ключ-значення. Сховище ключ-значення доступне через gRPC Services. etcd забезпечує найсильніші гарантії консистентності та надійності для розподіленої системи. Ця специфікація перераховує гарантії API, які надає etcd.

API для розгляду

• KV API
  • Range
  • Put
  • Delete
  • Transaction
• Watch API
  • Watch
• Lease API
  • Grant
  • [Revoke]
  • Keep alive

KV API дозволяє безпосередньо читати та маніпулювати сховищем ключ-значення. Watch API дозволяє підписуватися на зміни в сховищі ключ-значення. Lease API дозволяє призначати час життя ключа.

Як KV, так і Watch API дозволяють доступ не тільки до останніх версій ключів, але й до попередніх версій у межах безперервного історичного вікна, обмеженого операцією ущільнення.

Виклик KV API матиме негайний ефект, в той час, як Watch API повернеться з деякою необмеженою затримкою. У кластері etcd, що працює коректно, ви можете очікувати, що watch-події зʼявлятимуться з затримкою в 10 мс після того, як вони відбудуться. Однак, немає ніяких обмежень, і події у несправних кластерах можуть ніколи не зʼявлятися.

KV API

etcd забезпечує надійність і сувору серіалізованість для всіх викликів KV API. Це найсильніші гарантії ізоляції розподілених транзакційних баз даних.

Надійність

Будь-які завершені операції є надійними. Всі доступні дані також є надійними даними. Читання ніколи не поверне дані, які не були зроблені надійними.

Сувора серіалізованість

Операції KV Service є атомарними та відбуваються в загальному порядку, що відповідає реальному часу цих операцій. Загальний порядок імпліцитно через revision. Детальніше про сувору серіалізованість.

Сувора серіалізованість передбачає інші слабші гарантії, які можуть бути легшими для розуміння:

Атомарність

Всі запити API є атомарними; операція або завершується повністю, або не завершується взагалі. Для запитів спостереження всі події, згенеровані однією операцією, будуть в одній відповіді спостереження. Спостереження ніколи не спостерігає часткових подій для однієї операції.

Лінеаризованість

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

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

Наприклад, розглянемо клієнта, який завершує запис у момент часу 1 (t1). Клієнт, який виконує читання в момент часу t2 (для t2 > t1), повинен отримати значення принаймні найсвіжіше з часу попереднього запису, завершеного в t1. Однак читання може фактично завершитися лише до t3. Лінеаризованість гарантує, що читання поверне найсвіжіше значення. Без гарантії лінеаризованості повернуте значення, актуальне на t2, коли почалося читання, може бути “застарілим” до t3, оскільки паралельний запис може відбутися між t2 і t3.

etcd стандартно забезпечує лінеаризованість для всіх інших операцій. Однак лінеаризованість має свою ціну, оскільки лінеаризовані запити повинні проходити через процес консенсусу Raft. Щоб отримати нижчу затримку та вищу пропускну здатність для запитів на читання, клієнти можуть налаштувати режим консистентності запиту на serializable, який може отримувати застарілі дані щодо кворуму, але усуває штраф за продуктивність лінеаризованих доступів, що залежать від живого консенсусу.

Watch API

Спостереження надають гарантії щодо подій:

• Упорядковані — події впорядковані за ревізією. Подія ніколи не зʼявиться у спостереженні, якщо вона передує події в часі, яка вже була опублікована.
• Унікальні — подія ніколи не зʼявиться у спостереженні двічі.
• Надійні — послідовність подій ніколи не пропустить жодної підпослідовності подій у доступному історичному вікні. Якщо події впорядковані в часі як a < b < c, то якщо спостереження отримує події a і c, воно гарантовано отримає b, якщо b знаходиться в доступному історичному вікні.
• Атомарні — список подій гарантовано охоплює повні ревізії. Оновлення в одній ревізії для кількох ключів не будуть розділені на кілька списків подій.
• Відновлювані — Перерване спостереження можна відновити, встановивши нове спостереження, починаючи після останньої ревізії, отриманої у події спостереження до перерви, за умови, що ревізія знаходиться в історичному вікні.
• Закладка — Події повідомлення про прогрес гарантують, що всі події до ревізії вже були доставлені.

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

Lease API

etcd надає механізм оренди. Основний випадок використання оренди — реалізація механізмів розподіленої координації, таких як розподілені блокування. Сам механізм оренди простий: оренда може бути створена за допомогою API grant, прикріплена до ключа за допомогою API put, відкликана за допомогою API revoke і закінчиться за часом, який залишився до кінця життя (TTL), фактичного часу. Однак користувачі повинні бути обізнані про важливі властивості API та використання для реалізації правильних механізмів розподіленої координації.

Специфічні визначення etcd

Завершена операція

Операція etcd вважається завершеною, коли вона підтверджена через консенсус, і, отже, “виконана”, постійно збережена, за допомогою сховища etcd. Клієнт знає, що операція завершена, коли отримує відповідь від сервера etcd. Зверніть увагу, що клієнт може бути невпевнений у статусі операції, якщо вона перевищує час очікування або є мережеве порушення між клієнтом та членом etcd. etcd також може скасувати операції під час виборів лідера. etcd не надсилає відповіді abort на невиконані запити клієнтів у цьому випадку.

Ревізія

Операція etcd, яка змінює сховище ключ-значення, отримує одну зростаючу ревізію. Операція транзакції може змінити сховище ключ-значення кілька разів, але призначається лише одна ревізія. Атрибут ревізії пари ключ-значення, який був змінений операцією, має таке ж значення, як і ревізія операції. Ревізія може використовуватися як логічний годинник для сховища ключ-значення. Пара ключ-значення, яка має більшу ревізію, змінена після пари ключ-значення з меншою ревізією. Дві пари ключ-значення, які мають однакову ревізію, змінені операцією “одночасно”.