Розподілені системи

Фундаментальний трек | 3 Модулі | ~1.5 години загалом

Основи побудови систем, що працюють на декількох машинах одночасно. Розуміння того, чому розподілені системи — це складно, та патернів, які роблять їхню роботу можливою.

---

Чому розподілені системи?

Кожна сучасна система є розподіленою. Щойно у вас з’являється вебсервер та база даних — ви стаєте розподіленою системою. Щойно ви розгортаєте застосунок у декількох зонах доступності (availability zones) — ви стикаєтеся з викликами розподілених систем.

Розподілені системи не поводяться як поодинокі машини. Речі, які були простими, стають складними:

• Затримка (Latency): Мережеві виклики в мільйони разів повільніші за локальні.
• Часткова відмова (Partial failure): Компоненти виходять з ладу незалежно один від одного, часто непомітно.
• Відсутність глобального годинника: Ви не можете надійно впорядкувати події на різних машинах.
• Невизначеність: Ви не завжди можете визначити, чи був віддалений виклик успішним.

Розуміння цих викликів допоможе вам проєктувати системи, які працюють попри них.

---

Модулі

#	Модуль	Час	Опис
5.1	Модуль 5.1: Що робить системи розподіленими	25-30 хв	Фундаментальні виклики, CAP-теорема, Kubernetes як розподілена система
5.2	Модуль 5.2: Консенсус та координація	35-40 хв	Paxos, Raft, вибір лідера, розподілені блокування, etcd
5.3	Модуль 5.3: Узгодженість у кінцевому підсумку	30-35 хв	Моделі узгодженості, реплікація, вирішення конфліктів, CRDTs

---

Навчальний шлях

ПОЧИНАЙТЕ ТУТ
    │
    ▼
┌─────────────────────────────────────┐
│  Модуль 5.1                         │
│  Що робить системи розподіленими    │
│  └── Фундаментальні виклики         │
│  └── CAP-теорема                    │
│  └── Kubernetes як приклад          │
│  └── Чому це складно                │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│  Модуль 5.2                         │
│  Консенсус та координація           │
│  └── Paxos та Raft                  │
│  └── Вибір лідера (Leader election) │
│  └── Розподілені блокування         │
│  └── etcd та ZooKeeper              │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│  Модуль 5.3                         │
│  Eventual Consistency               │
│  └── Спектр узгодженості            │
│  └── Стратегії реплікації           │
│  └── Вирішення конфліктів           │
│  └── CRDTs                          │
└──────────────────┬──────────────────┘
                   │
                   ▼
           ФУНДАМЕНТ ЗАКЛАДЕНО
                   │
    ┌──────────────┼──────────────┐
    │              │              │
    ▼              ▼              ▼
   Напрям        Напрям         Напрям
    SRE         Platform        GitOps
               Engineering

---

Ключові поняття, які ви вивчите

Поняття	Модуль	Що це означає
Затримка (Latency)	5.1	Мережеві виклики повільні (фізика)
Часткова відмова	5.1	Одні частини виходять з ладу, поки інші працюють
CAP-теорема	5.1	Вибір між узгодженістю та доступністю під час розділення
Консенсус	5.2	Досягнення згоди між вузлами щодо певного значення
Raft	5.2	Зрозумілий алгоритм консенсусу
Вибір лідера	5.2	Обрання одного координатора серед багатьох
Розподілене блокування	5.2	Взаємне виключення (mutual exclusion) між машинами
Eventual Consistency	5.3	Збіжність даних без миттєвої згоди
Вектори версій	5.3	Відстеження причинно-наслідкових зв’язків без годинників
CRDTs	5.3	Структури даних без конфліктів

---

Попередні вимоги

• Рекомендовано: Трек «Системне мислення» — Розуміння взаємодії систем
• Рекомендовано: Трек «Reliability Engineering» — Режими відмов та стійкість
• Корисно: Базові знання Kubernetes
• Корисно: Певний досвід програмування

---

Куди це веде

Після завершення треку «Розподілені системи» ви будете готові до:

Напрям	Чому
Напрям SRE	Застосування мислення розподілених систем для надійності
Напрям Platform Engineering	Побудова платформ на розподіленому фундаменті
Напрям GitOps	Eventual consistency на практиці
Набір інструментів Observability	Моніторинг розподілених систем

---

Основні ресурси

Книги, на які ми посилаємося в цьому треку:

• “Designing Data-Intensive Applications” — Martin Kleppmann (найкращий посібник у цій галузі)
• “Distributed Systems for Fun and Profit” — Mikito Takada (доступна безкоштовно онлайн)
• “Database Internals” — Alex Petrov

Наукові праці (Papers):

• “Time, Clocks, and the Ordering of Events” — Leslie Lamport
• “In Search of an Understandable Consensus Algorithm” — Diego Ongaro (Raft)
• “Dynamo: Amazon’s Highly Available Key-value Store” — DeCandia et al.

---

Розподілений спосіб мислення

Питання, які варто ставити	Чому це важливо
”Що, якщо цей виклик завершиться помилкою?”	Проєктуйте з урахуванням часткових відмов
”Що, якщо він просто повільний?”	Неможливо відрізнити повільний вузол від мертвого
”Чи потрібен нам тут консенсус?”	Консенсус коштує дорого, використовуйте його ощадливо
”Яка узгодженість нам потрібна?”	Узгоджуйте рівень консистенції з вимогами
”Як ми обробляємо конфлікти?”	Паралельні записи обов’язково траплятимуться
”Який тут домен відмови (failure domain)?”	Розумійте радіус ураження (blast radius)

---

Фундамент закладено

Це останній трек у серії Foundations. Тепер ви охопили:

1. Системне мислення: Бачення систем як взаємопов’язаних цілих
2. Reliability Engineering: Проєктування з урахуванням відмов, вимірювання через SLO
3. Теорія Observability: Розуміння через метрики, логи та трасування
4. Принципи безпеки: Ешелонована оборона, мінімальні привілеї
5. Розподілені системи: Консенсус, узгодженість, координація

Ці основи підготували вас до практичних треків Disciplines та Toolkits.

---

“Розподілена система — це така система, в якій поломка комп’ютера, про існування якого ви навіть не здогадувалися, може зробити ваш власний комп’ютер непридатним до використання.” — Леслі Лампорт