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

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

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

---

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

Кожна сучасна система є розподіленою. Як тільки у вас з’являється веб-сервер і база даних — ви вже в розподіленому середовищі. Як тільки ви розгортаєтесь у кількох зонах доступності — ви стикаєтеся з викликами розподілених систем.

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

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

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

---

Модулі

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

---

Шлях навчання

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

---

Ключові концепції

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

---

Передумови

• Рекомендовано: Трек системного мислення — розуміння взаємодії систем
• Рекомендовано: Трек надійності інженерних систем — режими відмов та стійкість
• Корисно: базові знання Kubernetes
• Корисно: деякий досвід програмування

---

Куди це веде

Після завершення розподілених систем ви готові до:

Трек	Чому
SRE Дисципліна	Застосування мислення розподілених систем до надійності
Platform Engineering	Побудова платформ на розподіленому фундаменті
GitOps Дисципліна	Кінцева узгодженість на практиці
Інструменти спостережуваності	Моніторинг розподілених систем

---

Ключові ресурси

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

• “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.

---

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

Питання для роздумів	Чому це важливо
”Що, якщо цей виклик не вдасться?”	Проєктуйте для часткових відмов
”Що, якщо система просто повільна?”	Неможливо відрізнити повільне від мертвого
”Чи потрібен нам тут консенсус?”	Консенсус — це дорого, використовуйте економно
”Яка узгодженість нам потрібна?”	Зіставляйте узгодженість з вимогами
”Як ми обробляємо конфлікти?”	Паралельні записи обов’язково стануться
”Який домен відмови?”	Розумійте радіус ураження

---

Основи завершено

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

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

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

---

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