---
title: Конспект материала 28 — awesome-distributed-systems (theanalyst)
source: https://github.com/theanalyst/awesome-distributed-systems
author: курируемая подборка классики распределённых систем «on architecture itself rather than code» (bootcamp-теория, книги, первоисточники-статьи, курсы, блоги)
конспект: подготовлено 2026-09-18, TASK-45.32; README прочитан целиком (83 ссылки, 8 разделов); топ-5 отобраны и прочитаны полностью — 2 статьи конференций (Dynamo SOSP'07, 16 стр.; Dapper, 14 стр.) + 2 инженерных поста/доклада (Hodges 2013, Hamilton USENIX LISA'07) + сайт и визуализации Raft
статус: P3-источник «после секций», но это единственная подборка, где в одном месте лежат первоисточники (Dynamo, Dapper, Hamilton, Raft) — то, на что ссылаются все остальные конспекты. Папку Books/Courses пропускаем сознательно (DDIA-глубина уже законспектирована, тяжёлые курсы не успеть до слотов), топ-5 смещён в «первоисточник + операционный практический слой»
---

# Материал 28: awesome-distributed-systems — индекс и топ-5

Из всех просмотренных подборок эта — самая «теоретическая» по духу: никаких кейсов компаний и шпаргалок, а канон распределённых систем — от Fallacies и CAP до первоисточников Dynamo/GFS/Paxos и инфраструктуры наблюдаемости (Dapper, Jepsen). Для нашей секции (крупноблочная схема + отказоустойчивость) ценность не в «прочитать всё» — почти вся теория списка уже лежит в KB §5–§7 и DDIA-конспектах, — а в **первоисточниках с числами и формулировками**, которые придают ответам вес: «так это описано в Dynamo» звучит иначе, чем «вроде есть такой приём». Плюс два текста закрывают слой, которого не хватало другим конспектам: **операционная мудрость** (Hodges, Hamilton) и **наблюдаемость** (Dapper).

## 1. Как устроен источник

| Раздел | Что внутри | Ссылок | Ценность для нас |
|---|---|---|---|
| **Papers** | Ядро списка: Lamport (Time Clocks, Paxos, Byzantine), хранилища (Dynamo, Bigtable, GFS, Cassandra, CRUSH), месседжинг (The Log, Kafka), консенсус (PBFT, Raft, CRDT, Chubby), трассировка (Dapper) | 25 | **Топ-5 отсюда**; остальное уже покрыто DDIA-конспектами |
| **Bootcamp** | CAP, Fallacies of Distributed Computing, FLP impossibility, «distsys theory» по карте, aphyr-введение | 5 | Разогрев за вечер; CAP у нас уже в KB §7 |
| **Books** | mixu «Fun and Profit», Tanenbaum, DDIA, Armstrong (Erlang), Lynch, Burns и др. | 15 | DDIA извлечена (45.39), mixu дублирует её; отдельного чтения не требует |
| **Courses** | MIT 6.824, Kleppmann (Cambridge), CMU 15-440, ETH, KTH, Coursera CCC | 10 | Клеппман — материал 32, 6.824 — «после секций» |
| **Blogs** | Amazon Builders Library, High Scalability, aphyr/Jepsen, «Young Bloods», Hamilton LISA'07, There is No Now | 15 | Второй источник для топ-5 (Hodges, Hamilton) |
| **Testing/Verification** (внутри Papers) | Jepsen, список testing-distributed-systems, Verdi | ~4 | Jepsen — материал 33 |
| Videos (2) / Research (3) / Meta Lists (8) | Ably Deep Dive, Tim Berglund; PODC/DISC, мета-списки чтений | 13 | Вне брифа |

## 2. Критерии отбора топ-5

1. **Не дублировать уже покрытое.** Механики Dynamo (quorum, векторные часы, sloppy quorum, Merkle) уже в KB §5/§7 (Alex Xu гл. 6, DDIA); The Log — топ-5 материала 27; деградация (Netflix/Brewer) — материал 26; Jepsen — материал 33; лекции Клеппмана — материал 32. Поэтому Papers-канон берём только там, где статья даёт **новое** поверх конспектов (рамка решения, числа, формулировки), а остальные слоты отдаём непокрытым слоям: эксплуатация, наблюдаемость, практический словарь.
2. **Прямая релевантность брифу**: крупноблочная схема сервиса + отказоустойчивость + «говорим эксплуатацию всегда» (KB §10). Каждый пункт закрывает конкретный вопрос интервьюера: «почему AP, а не CP», «что будет, если упадёт мастер», «как вы это эксплуатируете», «как вы это наблюдаете».
3. **Скорость поглощения под слоты 18–22.09**: все топ-5 читаются суммарно за 3–4 часа, без курсов и книг; две статьи — классика, которую цитируют сами конспекты KB.

## 3. Топ-5

| # | Материал | Год / автор | Слой ответа | Бриф / KB |
|---|---|---|---|---|
| 1 | [Dynamo: Amazon's Highly Available Key-value Store](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) | Amazon, SOSP'07 | «почему AP»: бизнес-рамка + SLA на перцентиле | бриф 04–05, 09 / KB §5, §6, §7 |
| 2 | [Raft: raft.github.io + The Secret Lives of Data](https://raft.github.io/) | Ongaro & Ousterhout, 2014 | механика «упал мастер → выборы» | бриф 08 / KB §7 |
| 3 | [Notes on Distributed Systems for Young Bloods](http://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/) | Jeff Hodges, 2013 | практический словарь зрелых ответов | бриф 08, 12 / KB §7, §9, §10 |
| 4 | [On Designing and Deploying Internet-Scale Services](https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton_html/) | James Hamilton, USENIX LISA'07 | чек-лист operations-friendly | бриф 12 / KB §10 |
| 5 | [Dapper, a Large-Scale Distributed Systems Tracing Infrastructure](https://research.google/pubs/pub36356/) | Google, 2010 | распределённая трассировка | бриф 12 / KB §10 |

### 3.1 Dynamo (Amazon, SOSP'07) — первоисточник AP-дизайна: рамка решения, а не механики

**Выжимка.** Сами механики (consistent hashing с виртуальными нодами, N/R/W, векторные часы, sloppy quorum, hinted handoff, Merkle-антиэнтропия, gossip-членство) у нас уже законспектированы (KB §5–§7) — читать статью стоит ради **рамки, в которой они выбраны**. (1) Бизнес-кейс как требование: «покупатель должен иметь возможность положить товар в корзину, даже если диски отказывают, маршруты флапают, а ДЦ сносит торнадо» — корзина **always-writable**, и из этого единственного требования выводится весь дизайн (AP вместо CP). Урок для секции: сначала фиксируешь, что дороже терять — запись или чтение, остальное выводится. (2) SLA измеряется **на 99.9-перцентиле, а не на среднем**: клиенты с длинной историей (персонализация) — самые нагруженные, медиана их не видит; 99.9, а не 99.99 — сознательный cost-benefit выбор. (3) Типовая конфигурация **(N, R, W) = (3, 2, 2)**, SLA «99.9% чтений/записей быстрее 300 мс»; p99.9 ≈ 200 мс — **на порядок выше среднего** (диуральный паттерн нагрузки), поэтому оптимизации вроде балансировки write-координаторов делались именно под p99.9. (4) Availability и durability **не синонимы**: растёшь W — прочнее durability, но чаще отказываешь записи (больше реплик должны быть живы); трейдофф проговаривается явно. (5) Операционные мелочи: нода «отвалилась» ≠ выбыла из кольца (членство меняет администратор, gossip распространяет — иначе флапающий узел ребалансирует кластер); hinted-реплика лежит в отдельной локальной БД и доставляется по восстановлению; buffered writes сглаживают пики дисковых операций.

**Что брать на секцию.**
- Готовая формулировка выбора AP: «как в Dynamo — корзина должна писаться всегда, поэтому читаем возможно устаревшее и мирим версии; консистентность жертвуем осознанно». Это ответ на «почему не просто Postgres master-slave».
- «SLA на p99.9, потому что самые ценные клиенты — самые тяжёлые» — зрелая реплика про перцентили (стыкуется с KB §10 и Young Bloods §3.3).
- Числа: (3,2,2), 300 мс SLA, p99.9 ≈ 200 мс «на порядок выше среднего» — три цифры, которые делают ответ про кворум конкретным.
- «Availability ≠ durability» при настройке W — тонкость, которую редко называют; хорошо звучит в блоке про шардирование/репликацию.

### 3.2 Raft: raft.github.io + The Secret Lives of Data — механика «упал мастер» за 30 минут

**Выжимка.** Сайт-дом консенсуса (переехал с raftconsensus.github.io): описание алгоритма в одном абзаце («эквивалентен Paxos по отказоустойчивости и производительности, но разложен на независимые подзадачи — выборы, лог, безопасность»), модель replicated state machine (клиенты думают, что общаются с одной надёжной машиной, хотя кластер из 5 переживает отказ 2 узлов) и интерактивная визуализация **RaftScope** прямо на странице. Рядом — управляемая пошаговая визуализация **The Secret Lives of Data**: на живом примере «зарегистрировать в логе set x=3» показывает, как узел с полным логом становится кандидатом, набирает большинство голосов (термины-эпохи растут при каждом таймауте heartbeat), реплицирует записи и коммитит их, что происходит при партиции и почему узел с устаревшим логом не может выиграть выборы. Консенсус гарантирует: если одна реплика применила «set x=3» как n-ю команду, ни одна другая не применит другую n-ю — отсюда идентичные последовательности состояний на всех узлах. Для нас это **закрепление механики KB §7** (эпоха/терм, два голосования, кворумы DDIA гл. 10) в виде наблюдаемой картинки, а не нового знания.

**Что брать на секцию.**
- Ответ на «что будет, если упадёт мастер БД/координатора»: «мастер — не SPOF, если за ним консенсус: термины растут при каждом таймауте heartbeat, кандидат с более свежим логом побеждает, кворум коммитит; при потере кворума кластер молчит, но не врёт» (последняя фраза — свойство safety консенсуса: не прогресс, но никогда неверный результат).
- «Почему 5 узлов, а не 4»: прогресс при любом большинстве, 2 из 5 можно потерять; чётный размер не добавляет отказоустойчивости, только латентность.
- Raft как ответ на «зачем ZooKeeper/etcd»: Raft — тот протокол, что крутится внутри etcd/консула; стыкуется с KB §7 (координационные сервисы, fencing tokens).
- Время на подготовку: RaftScope + Secret Lives ≈ 30 минут на глазах — лучший ROI из всего списка.

### 3.3 Notes on Distributed Systems for Young Bloods (Hodges, 2013) — словарь зрелых ответов

**Выжимка.** 16 уроков инженера-практика (Google/Swiss Systems, рецензенты — Coda Hale и др.); ни одна из «шпаргалок» списка не даёт столько готовых формулировок на квадратный метр. Ключевое: (1) **распределённые системы отличаются вероятностью частичного отказа**, а не латентностью — «отправить на обе машины и ретраить» — маркер неопытности; отказ unlock распределённого мьютекса встраивается в протокол, а не роняет процесс. (2) **Backpressure** — базовый строительный блок: сигнал отказа от сервера клиенту, ограничение ресурсов при перегрузке; без него — каскадные отказы или тихая потеря сообщений. (3) **Partial availability** — «найти способ быть частично доступным»: поиск отдаёт то, что успел собрать за бюджет; для личных сообщений лучше уронить сервис для малого процента пользователей, чем молча терять письма у всех; размечать failure domains. (4) **Метрики vs логи**: «логи врут» — редкие классы ошибок раздувают файл и уводят расследование; «ты не Шерлок, пока метрики не подтверждают историю». (5) **Перцентили, не средние**: «я не видел распределённой системы, где латентность — колокол; среднее ведёт к неверным решениям». (6) **Feature flags для миграций инфраструктуры**: замена хранилища шагами «двойная запись → чтение-сравнение → перевод чтения» с ручками отката; «много версий инфраструктуры — норма, а не исключение». (7) **Выбирай пространство ID осознанно**: чем больше идентификаторов нужно до данных, тем больше вариантов партиционирования (кейс Twitter API v1: твит адресуем только tweet id → для партиционирования по пользователю нужен lookup-сервис; а включи user id в tweet id — потеряешь k-сортируемость). (8) CAP — **инструмент критики дизайна, а не принцип построения**; «из C, A, P нельзя выбрать CA». Плюс: координацию машин — минимизировать; «it's slow» — самая тяжёлая отладка; кэш нельзя писать обратно в персистентное хранилище; компьютеры мощнее, чем ты думаешь; выделяй сервисы вместо библиотек.

**Что брать на секцию.**
- Формулировка про частичные отказы для первого этапа секции: «проектирую под частичные отказы: одна из двух записей может не пройти — вопросы консистентности решаю протоколом, а не ретраем».
- **Backpressure** — одно слово, которое поднимает блок деградации (KB §9): «очередь не бесконечная, при перегрузке — отказ на входе, drop или ошибка клиенту, счётчик растёт».
- Partial availability на примере ленты: «лучше недоступна лента у 1% пользователей, чем у всех нет счётчиков» — стыкуется с yield/harvest Брюера (материал 26).
- «Ты не Шерлок, пока метрики не подтверждают» — на вопрос про эксплуатацию/инциденты; вместе с «перцентили, не средние» закрывает словарь наблюдаемости.
- Кейс Twitter про пространство ID — готовый ответ на «как бы вы выбирали ключи партиционирования» (стыкуется с §13.4 KB и Instagram IDs).

### 3.4 On Designing and Deploying Internet-Scale Services (Hamilton, LISA'07) — чек-лист operations-friendly

**Выжимка.** Классика эксплуатации от архитектора Windows Live/Exchange (позже AWS): соотношение «систем на администратора» — от 2:1 до **2500:1**, и главный фактор — не автопилот, а то, **спроектирован ли сервис для автоматизации**. Три заповеди: **expect failures / keep things simple / automate everything**. «80% операционных проблем рождаются в дизайне и разработке». Ключевые правила: **design for failure** — за 10 000 серверов и 50 000 дисков отказы случаются **несколько раз в день**, любое требование «человеческого вмешательства» при отказе делает сервис неремонтопригодным; тест на синхронную репликацию и автотейковер — «готова ли ops-команда выключить **любой** сервер в **любой** момент без дрейна нагрузки»; **crash-only** (Fox/Stanford): путь отказа надо дёргать постоянно, поэтому сервис не выключают «по-хорошему» — просто жёстко убивают; моделировать отказы как security threat modeling — «редкие комбинации событий становятся обычными на тысячах машин». **Admission control на всех уровнях** (не только на входе): лучше не пустить работу в перегруженную подсистему, чем дать всем одинаково плохо; **graceful degradation вместо тотального падения** (кейс 9/11: новостные сайты легли целиком, хотя могли отдавать подмножество статей). Партиционирование: разбиение **fine-grained, не по реальным сущностям** (компании «Гугл» не влезет в шард, префикс «P» переполнится) + lookup-таблица в middle-tier. Эксплуатация: **soft delete only** — ничего не удалять, вести rolling-историю изменений 2+ недели (DELETE без WHERE не спасут ни RAID, ни зеркала); **трекать все механизмы отказоустойчивости** — ретраи и failover скрывают мелкие отказы, «сервис из 2000 машин незаметно деградировал до 400 за несколько дней»; отладка — дампом памяти из прода, «чем реже трогают прод, тем счастливее клиенты»; «you build it, you manage it» (Amazon); аварийные скрипты проверять в проде «fire drill'ом» — не готов рисковать в дрилле, значит скрипт не готов к аварии. Коммуникации: сообщать клиентам статус и ETA восстановления — удовлетворённость выше, даже у бесплатного сервиса.

**Что брать на секцию.**
- Шесть фактов для блока «эксплуатация» (KB §10): 2500:1; отказы несколько раз в день на 10K серверов; «выключи любой сервер без дрейна» как тест HA; admission control на каждом ярусе; soft delete + история изменений; трекинг FT-механизмов (2000→400).
- Связка «80% проблем рождаются в дизайне» — аргумент в ответе «как вы проектируете надёжность»: не пост-фактум мониторингом, а ограничениями в дизайне (single-version software, pod-изоляция, отсутствие SPOF).
- «Редкие комбинации отказов становятся обычными» — зрелая реплика в разговоре про multi-ДЦ и отказоустойчивость брифа 08.
- Кейс 9/11 и «большая красная кнопка» деградации — конкретика к graceful degradation, стыкуется с Netflix/Brewer (материал 26).

### 3.5 Dapper (Google, 2010) — распределённая трассировка: как «see the whole request»

**Выжимка.** Технический отчёт Google про 2+ года продакшена системы трассировки: один universal search запрос обрабатывают **тысячи машин**, и без сквозного наблюдения «поведение системы неотличимо от шаманизма». Модель: **trace tree** из **span'ов** (имя, timestamp, RPC-данные) с tree-структурой вызовов; распространение **трассировочных контекстов через общие библиотеки** (thread pool, RPC, control flow) — приложение трогать не надо, инструментирование точечное; данные пишутся в локальные файлы, собираются асинхронно — трассировка не на пути запроса. Цена решается **сэмплированием**: дефолт 1/1024 (до 0.01% для самых горячих сервисов), влияние на латентность неотличимо от нуля при частоте ≤1/16; адаптивное сэмплирование «N трейсов в секунду» для низконагруженных; агрессивное сэмплирование не мешает анализу — «если паттерн важен, он проявится тысячи раз»; >1 TB трейсов в день, хранение 2+ недели, демон <0.3% ядра, сбор <0.01%. Главный побочный эффект: Dapper начал как инструмент, а стал **платформой** — на его данных построили непредвиденные авторами инструменты (анализ сервисных конфигураций, сетевая отладка, профиль латентностей); наследники — Zipkin, SkyWalking, OpenTelemetry.

**Что брать на секцию.**
- Ответ на «как вы наблюдаете распределённый запрос» (KB §10 говорит «traces: OpenTelemetry, сквозной trace id» — теперь с первоисточником): «сквозной trace id прокидывается через общие библиотеки, спаны собираются в дерево вызова; сэмплируем 1/1024 — на горячих сервисах важный паттерн всё равно проявится тысячи раз; поэтому трассировка стоит ноль на пути запроса».
- «Трассировка — платформа, а не инструмент»: по трейсам строят профиль латентностей и ловят конфигурационные деградации — готовый ответ на «что даёт наблюдаемость бизнесу».
- Связка с Hodges («it's slow» — самая тяжёлая отладка, Dapper и Zipkin построены ради неё): два источника одним голосом.

## 4. Второй эшелон (после секций / по остаточному времени)

| Материал | Что даёт | Когда |
|---|---|---|
| [Amazon Builders Library](https://aws.amazon.com/builders-library/) | сборник практик AWS: таймауты/ретраи/jitter, кэширование, static stability, «shuffle sharding» | бриф 08/12, после секций |
| [MIT 6.824](https://pdos.csail.mit.edu/6.824/) (плейлист) | курс по статьям: GFS, ZooKeeper, Raft, Spanner — лекции + лабы на Go | глубина, если секций будет несколько |
| [Distributed Systems for Fun and Profit (mixu)](http://book.mixu.net/distsys/single-page.html) | короткая бесплатная книга: репликация, консистентность, время — «DDIA для бедных» | только если нет DDIA под рукой |
| [Scalable Web Architecture and Distributed Systems (aosabook)](http://www.aosabook.org/en/distsys.html) | классический intro: клонирование, кэш, шардирование, async | новичкам; у нас перекрыто KB |
| [An Introduction to Distributed Systems (aphyr)](https://github.com/aphyr/distsys-class) | скетч-конспект-словарь на 40 минут: время, репликация, консенсус | быстрый повтор перед секцией |
| [Fallacies of Distributed Computing](http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) + CAP plain english | 8 заблуждений и CAP «по-человечески» | разогрев, 15 минут |
| [The Chubby Lock Service](http://static.googleusercontent.com/media/research.google.com/en//archive/chubby-osdi06.pdf) | «Paxos as a Service»: прародитель ZooKeeper/etcd | вопрос про координацию |
| [Lamport, Time, Clocks and Ordering of Events](http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf) | первоисточник логических часов | заодно с DDIA гл. 8 (2-е изд. добавила логические часы) |
| [Testing distributed systems (asatarin)](https://asatarin.github.io/testing-distributed-systems/) | курируемый список по тестированию DS (Google, Netflix, Dropbox) | рядом с Jepsen (материал 33) |
| [There is No Now (Sheehy)](http://queue.acm.org/detail.cfm?id=2745385) | «одновременности не существует»: время как переговоры | разговор про консистентность |

## 5. Как использовать

1. **Первоисточник для цитирования (§3.1, §3.5)** — по одной фразе-маркеру: «как в Dynamo: always-writable корзина, SLA на p99.9, (3,2,2)»; «как в Dapper: трейс — дерево спанов через общие библиотеки, сэмплируем 1/1024».
2. **Механика отказов (§3.2)** — 30 минут визуализаций перед тренировкой: выборы/термины/кворум должны проговариваться без запинки в блоке «отказоустойчивость» брифа 08.
3. **Операционный слой (§3.3–3.4)** — словарь и чек-лист для финального этапа секции («эксплуатацию говорим всегда», KB §10): backpressure, partial availability, перцентили, soft delete, трекинг FT-механизмов, «выключи любой сервер без дрейна».
4. Чего в списке **нет**: разборов под формат интервью и кейсов компаний — за ними в `lsd-awesome-scalability.md`, `lsd-interviewready-resources.md`, `../classic-designs.md`.

## Связанные документы

- `../knowledge-base.md` — §5 (репликация), §6 (шардирование), §7 (консистентность/консенсус), §9 (отказоустойчивость), §10 (эксплуатация), §13.4 (ID)
- `../articles/08-fault-tolerance.md`, `../articles/09-consistency.md`, `../articles/12-operations-observability.md` — статьи брифа, куда ложатся темы топ-5
- `lsd-interviewready-resources.md` — материал 27: The Log и академические первоисточники (компаньон по Papers)
- `lsd-awesome-scalability.md` — материал 26: прод-кейсы тех же паттернов (Dynamo-механики в бою — Cassandra/DynamoDB-наследники)
- `learn-system-design-index.md` — индекс подборки (этот материал — №28, Advanced, P3)