Клеппман «Высоконагруженные приложения»: ключевые идеи книги

Что такое высоконагруженные приложения по Клеппману

Мартин Клеппман в своей фундаментальной работе «Высоконагруженные приложения. Программирование, аудит, эксплуатация» сместил фокус с модных технологий на базовые принципы. Его подход рассматривает систему не как набор серверов, а как совокупность свойств: надежность, масштабируемость и удобство сопровождения. Именно эти три столпа, по мнению автора, определяют жизнеспособность любого распределенного продукта.

Ключевая мысль заключается в том, что сложность возникает не из-за количества кода, а из-за взаимодействия между компонентами. Клеппман разбирает типовые проблемы: отказоустойчивость, задержки, консистентность данных. Он предлагает не готовые рецепты, а инструменты для анализа компромиссов. Например, выбор между ACID-транзакциями и конечной согласованностью зависит от конкретной бизнес-задачи, а не от моды на NoSQL.

Для практиков ценно то, что автор систематизирует паттерны репликации, партиционирования и обработки сбоев. Это своего рода карта местности, которая помогает инженерам не изобретать велосипед, а осознанно подходить к архитектуре. В итоге, труд Клеппмана стал настольной книгой для тех, кто проектирует системы с миллионной аудиторией.

Определение и критерии высокой нагрузки в книге Мартина Клеппмана

В своей работе Мартин Клеппман предлагает отказаться от абстрактного понятия «highload» в пользу измеримых параметров. Нагрузка описывается не количеством пользователей, а конкретными показателями: запросами в секунду, объёмом данных, соотношением чтения и записи. Критически важна не сама цифра, а её динамика и способность системы адаптироваться под изменения.

Автор выделяет два ключевых аспекта: нагрузку и производительность. Если первое — объективная характеристика запросов, то второе — реакция системы на них. Для оценки используются перцентили задержек, а не средние значения, так как они лучше отражают реальный опыт пользователя. Такой подход позволяет проектировать архитектуру, которая деградирует предсказуемо, а не рушится внезапно.

Почему «Designing Data-Intensive Applications» стала настольной книгой архитекторов

Труд Мартина Клеппмана ценят за системный разбор того, как реально работают распределённые системы. Вместо набора разрозненных рецептов автор предлагает фундаментальные принципы: от моделей репликации до тонкостей консистентности. Книга даёт язык для описания проблем, с которыми сталкивается каждый, кто проектирует хранилища или очереди. Это своего рода карта местности: после её прочтения доклады инженеров и документация баз данных воспринимаются совершенно иначе — как части единой картины, а не случайный набор терминов.

Надёжность, масштабируемость и сопровождаемость как фундамент системы

Проектирование сложных цифровых продуктов редко сводится к выбору стека технологий. Гораздо важнее заложить в архитектуру способность выдерживать пиковые нагрузки, быстро восстанавливаться после сбоев и оставаться понятной для команды разработки. Без этих трёх качеств даже самая изящная кодовая база превращается в источник постоянных проблем.

Отказоустойчивость достигается не только резервированием серверов, но и продуманной логикой обработки ошибок. Масштабируемость, в свою очередь, требует горизонтального расширения без переписывания ядра. Сопровождаемость же напрямую влияет на скорость внедрения новых функций — чем проще разобраться в чужом коде, тем быстрее команда закрывает задачи бизнеса.

Обеспечение надёжности: отказоустойчивость и обработка сбоев

Сбои неизбежны, поэтому проектирование системы начинается с допущения, что любой компонент может выйти из строя. Отказоустойчивость достигается резервированием и изоляцией, а не попытками создать идеальное железо.

• Репликация данных на несколько узлов.
• Таймауты и повторные попытки с экспоненциальной задержкой.
• Автоматическое переключение ролей при потере лидера.

Важно не просто перезапускать упавший сервис, а делать это быстро и без потери пользовательских запросов. Для этого применяют circuit breaker, который предотвращает каскадные отказы, и bulkhead — изоляцию ресурсов между потребителями.

Масштабируемость: как Клеппман предлагает измерять и достигать роста

В своей работе Мартин Клеппман предлагает отойти от абстрактных рассуждений о нагрузке и перейти к конкретным метрикам. Вместо того чтобы гадать, выдержит ли система, он советует описывать её через параметры, которые можно измерить и спрогнозировать.

Ключевая идея — разделить понятия «нагрузка» и «производительность». Нагрузка описывается через так называемые параметры нагрузки: количество запросов в секунду, соотношение чтения и записи, число одновременных активных пользователей или, например, доля «горячих» данных в кэше. Производительность же — это отклик системы под этой нагрузкой.

Для оценки отклика Клеппман предлагает использовать не среднее время ответа, а процентили (p50, p95, p99). Среднее арифметическое легко «портят» редкие, но очень медленные запросы, тогда как процентили показывают реальный опыт большинства пользователей. Например, если p99 равен 500 мс, это значит, что 99% запросов укладываются в полсекунды, и лишь 1% пользователей сталкивается с задержками.

Что касается достижения роста, то здесь автор выделяет два принципиально разных подхода — вертикальное и горизонтальное масштабирование. Первый путь (наращивание мощности одной машины) прост, но упирается в физические пределы оборудования. Второй (распределение нагрузки на множество узлов) сложнее, но даёт практически неограниченный потенциал. Выбор между ними зависит от характера нагрузки:

• Если данные легко шардируются (например, по идентификатору пользователя), горизонтальное масштабирование даёт почти линейный прирост.
• Если требуется строгая согласованность на всех узлах, распределённая система становится крайне сложной в реализации.

Клеппман подчёркивает: масштабируемость — это не свойство «по умолчанию», а результат осознанного проектирования. Часто проще пересмотреть архитектуру (например, добавить кэширующий слой или изменить модель данных), чем бесконечно добавлять серверы. Важно понимать, что универсального рецепта нет — каждая система требует собственного анализа узких мест и выбора подходящей стратегии роста.

Сопровождаемость: простота и эволюция кода в высоконагруженных проектах

Поддерживать систему, которая обрабатывает миллионы запросов, сложнее, чем создать её с нуля. Ключевой фактор — модульность. Когда логика разбита на изолированные сервисы, замена одного компонента не роняет остальные. Важно документировать архитектурные решения: через год разработчик должен понять, почему выбрана именно такая схема. Практикуйте код-ревью и автотесты — они страхуют от регрессий при рефакторинге. Эволюция неизбежна: закладывайте возможность менять протоколы и схемы данных без остановки системы.

Модели данных и языки запросов для высоких нагрузок

Выбор способа хранения и обработки информации напрямую определяет поведение системы под давлением. Реляционная модель с её строгими схемами часто уступает место более гибким решениям, когда речь заходит о масштабировании. Документо-ориентированные базы, графовые структуры или key-value хранилища позволяют распределять данные иначе, упрощая горизонтальное расширение.

Языки запросов тоже эволюционируют. SQL остаётся стандартом, но для распределённых сред всё чаще применяют декларативные подходы, которые скрывают сложность шардирования. Важно понимать: универсального ответа нет, компромисс между согласованностью, доступностью и скоростью приходится искать под конкретную задачу.

Реляционные модели против документоориентированных: выбор по Клеппману

Мартин Клеппман в своей работе предлагает оценивать хранилища не по модности, а по характеру связей между данными. Если структура напоминает дерево или вложенный документ — присмотритесь к документоориентированным СУБД. Когда же записи густо переплетены ссылками (как в соцсетях или бухгалтерии), реляционная модель с её JOIN-ами окажется надёжнее.

Ключевой критерий — локальность данных. В документной модели всё, что относится к одной сущности, лежит рядом, что ускоряет чтение. Но обновление одного факта, повторённого в тысяче документов, превращается в боль. В реляционной — наоборот: нормализация устраняет дубли, но разбивает объект на части, требуя соединений при выборке.

Практический совет: для каталога товаров с вариациями удобнее документы, а для платёжной системы или системы бронирования — таблицы с внешними ключами.

Графовые модели данных и их роль в сложных взаимосвязях

Когда связи между сущностями важнее самих сущностей, на помощь приходят графы. Вместо плоских таблиц здесь узлы и рёбра — так удобно описывать социальные сети, рекомендательные системы или маршруты доставки. Подобный подход особенно полезен, когда запросы требуют обхода нескольких уровней связей, например, поиск друзей друзей. Однако стоит помнить: горизонтальное масштабирование таких структур — задача нетривиальная, ведь данные приходится разрезать по кластерам, сохраняя целостность обхода.

Хранение и поиск данных: движки, которые выдерживают нагрузку

Когда речь заходит о системах, обслуживающих миллионы запросов, выбор способа хранения превращается в фундаментальное решение. Реляционные базы данных, привычные для большинства проектов, часто становятся узким местом. На смену им приходят распределённые хранилища, где данные шардируются по кластерам, а согласованность достигается за счёт компромиссов.

Для поиска по большим объёмам информации используют инвертированные индексы, как в Elasticsearch. Для кэширования — in-memory решения вроде Redis. Ключевой принцип: не пытаться хранить всё в одном месте, а проектировать систему так, чтобы каждый узел отвечал за свою часть данных и мог масштабироваться горизонтально.

Структуры индексов: LSM-деревья и B-деревья в сравнении

Выбор между LSM и B-деревьями определяет поведение хранилища под нагрузкой. Классические B-деревья оптимизированы для чтения и обеспечивают предсказуемую латентность, но страдают при интенсивной вставке из-за случайных операций записи. LSM-структуры, напротив, преобразуют случайные записи в последовательные, группируя данные в отсортированные сегменты (SSTable). Это даёт выигрыш на запись, однако ценой становится амортизация чтения: приходится просматривать несколько уровней и выполнять merge-операции в фоне.

На практике выбор зависит от сценария:

• Для систем с преобладанием чтения (аналитика, каталоги) чаще берут B-деревья.
• Для логов, метрик и очередей, где важна скорость приёма данных, предпочтительнее LSM.

Компромиссным решением выступают гибридные варианты, например, использование LSM с периодическим уплотнением (compaction) для снижения амплификации записи.

Колоночные хранилища для аналитических нагрузок

Когда речь заходит об обработке огромных массивов данных, привычные строчные СУБД часто пасуют. Им на смену приходят колоночные системы, где данные организованы не по записям, а по столбцам. Такой подход радикально ускоряет агрегатные запросы, ведь считываются только нужные поля, а не вся строка целиком. Например, при анализе продаж за год системе не приходится перелопачивать всю информацию о клиентах — достаточно выбрать лишь столбец с суммами. Подобная архитектура особенно эффективна для OLAP-сценариев, где преобладают операции чтения и сканирования больших диапазонов. Сжатие данных в таких системах тоже работает лучше: однотипные значения в колонке жмутся в разы плотнее, экономя дисковое пространство и ускоряя ввод-вывод.

Форматы кодирования и эволюция схем в распределённых системах

В распределённых средах данные передаются между сервисами, и здесь критически важен выбор формата сериализации. Текстовые варианты вроде JSON или XML удобны для чтения, но проигрывают бинарным аналогам (Protocol Buffers, Thrift, Avro) в скорости обработки и компактности. Последние, однако, требуют управления схемами данных.

Проблема совместимости возникает при изменении структуры записей. Стратегии эволюции схем предполагают два направления: прямую и обратную совместимость. Например, добавление нового поля с значением по умолчанию не ломает старых клиентов, а удаление — требует осторожности. В Avro для этого используется отдельный файл схемы, тогда как в Protobuf номера полей играют роль идентификаторов.

На практике часто применяют гибридный подход: основное хранилище — бинарный формат, а для внешних API — JSON. Это позволяет балансировать между производительностью и доступностью. Важно помнить, что миграция на новую версию схемы должна происходить поэтапно, чтобы избежать простоев.

Бинарные форматы: Thrift, Protobuf и Avro в примерах Клеппмана

В книге Мартина Клеппмана разбор бинарных протоколов начинается с проблемы: JSON и XML слишком «болтливы». Для внутреннего обмена между сервисами это критично. Thrift от Facebook и Protobuf от Google генерируют компактный код, но требуют компиляции схемы. Avro, напротив, хранит схему прямо в файле, что упрощает эволюцию данных.

Ключевое различие — подход к совместимости:

• Thrift использует явные идентификаторы полей, что делает его устойчивым к переименованию атрибутов.
• Protobuf полагается на номера тегов, экономя место, но усложняя отладку.
• Avro ориентирован на запись в журналы: схема прилагается к каждой порции данных, поэтому читатель всегда знает формат.

Клеппман подчёркивает: выбор между ними — это компромисс между скоростью разработки и гибкостью миграции. Для долгоживущих систем Avro часто удобнее, так как позволяет менять структуру без остановки кластера.

Совместимость схем при миграции данных без остановки сервиса

При эволюции структуры хранения в работающей системе критически важна обратимая совместимость. Обычно применяется стратегия расширения: новое поле добавляется как необязательное, а старое продолжает поддерживаться несколько релизов. Такой подход позволяет старым узлам читать новые записи, а новым — корректно обрабатывать прежние версии.

На практике это выглядит так:

• двухфазное изменение: сначала код, затем схема;
• использование версионирования записей (например, поле schema_version);
• миграция данных фоновыми задачами с контролем нагрузки.

Подобная методика описана в литературе по распределённым системам и применяется в крупных сервисах для бесшовного обновления без даунтайма.

Распределённые данные: репликация и партиционирование

Когда данные не помещаются на одном узле, их приходится дробить и дублировать. Репликация обеспечивает отказоустойчивость и снижает задержки чтения, а шардирование распределяет нагрузку при записи. Эти механизмы работают в связке: каждая копия шарда живёт на отдельной машине. Выбор стратегии зависит от модели согласованности и характера запросов.

Репликация: синхронная и асинхронная, проблемы согласованности

При дублировании данных на несколько узлов критичен выбор момента подтверждения записи. Синхронный подход гарантирует актуальность копий, но жертвует скоростью ответа. Асинхронный вариант быстрее, однако допускает временные расхождения. Компромисс — полусинхронная схема, где ждём ответа лишь от части реплик. Возникающие конфликты версий решают через векторные часы или версионирование. Для ослабления требований к целостности применяют модель итоговой согласованности.

Партиционирование ключей и вторичных индексов для равномерной нагрузки

Распределение данных по шардам напрямую определяет, насколько сбалансированно будут работать узлы кластера. Если хэш-функция подобрана неудачно, отдельные серверы перегружаются, а другие простаивают. Для первичных ключей обычно применяют последовательное или хэш-разбиение, но со вторичными индексами всё сложнее — их обновление требует координации между нодами.

Практические подходы к решению проблемы:

• использование составных ключей, где первая часть — идентификатор шарда;
• репликация индексных таблиц на все узлы для локальных выборок;
• применение глобальных индексов с отдельным партиционированием.

В распределённых базах вроде Cassandra или ScyllaDB вторичные индексы часто реализуют через отдельные таблицы поиска, что увеличивает задержки, но сохраняет равномерность. Для систем реального времени лучше заранее проектировать схему так, чтобы горячие ключи не концентрировались в одном диапазоне.

Транзакции в условиях высокой конкурентности

Когда десятки тысяч запросов одновременно пытаются изменить одну запись, наивный подход к блокировкам превращает базу данных в узкое место. Оптимистичное управление версиями строк (MVCC) позволяет читателям не ждать писателей, а конфликты фиксировать лишь на этапе коммита. Для горячих точек вроде счётчиков лучше применять атомарные операции, а не транзакции с длинными блокировками. Полезно также ограничивать время удержания блокировок и использовать сегментирование данных.

Изоляция транзакций: от Read Committed до Serializable

Уровни изоляции определяют, насколько сильно параллельные операции влияют друг на друга. Read Committed защищает от чернового чтения, но допускает фантомы и несогласованность при повторном чтении. Переход к Repeatable Read снимает часть проблем, однако полностью проблему решает только Serializable — самый строгий режим, который фактически сериализует выполнение.

На практике выбор зависит от компромисса между консистентностью и производительностью. Для аналитических нагрузок часто достаточно более слабых гарантий, а вот для финансовых операций лучше переплатить за строгость.

Распределённые транзакции и компенсирующие действия

В распределённых системах атомарность операций достигается через сагу — последовательность локальных транзакций с компенсациями. Если шаг падает, запускаются обратные действия: возврат средств, отмена брони, удаление записи. Такой подход заменяет двухфазный коммит, который блокирует ресурсы и плохо масштабируется. Для контроля используют оркестрацию (центральный координатор) или хореографию (обмен событиями). Компенсации проектируют идемпотентными, чтобы повторный вызов не ломал состояние системы.

Горизонтальное масштабирование: партиции, ребалансировка и маршрутизация

Когда данные перестают помещаться на одном узле, на помощь приходит шардирование. Суть проста: разбить набор записей на части и разложить их по разным машинам. Но тут возникает вопрос — как понять, на каком сервере лежит нужная запись? Обычно применяют хеширование ключа или диапазонное разбиение. Первый способ даёт равномерное распределение, но усложняет запросы по диапазонам. Второй — удобен для сканирования, однако рискует перекосом, когда одна «горячая» зона получает львиную долю трафика.

Ребалансировка — это перенос партиций между нодами при добавлении или удалении оборудования. Классический подход — перемешивать только часть данных, а не пересчитывать всё заново. Например, в Cassandra используется консистентное хеширование с виртуальными токенами, что минимизирует объём миграции. Маршрутизация запросов может быть реализована через координатор, который знает карту размещения, либо через gossip-протокол, когда каждый узел сам узнаёт о соседях. Важно помнить: чем меньше данных перемещается, тем быстрее проходит перестройка кластера и ниже нагрузка на сеть.

Стратегии ребалансировки партиций без простоя системы

Перераспределение данных между узлами кластера — операция деликатная. Остановка сервиса ради этого недопустима, поэтому применяются методы, работающие «на горячую». Классический подход — постепенный перенос сегментов с одного хоста на другой с сохранением обслуживания запросов на старом месте до полной синхронизации копии.

Альтернативный сценарий — использование виртуальных «колец» или логических слотов, которые перепривязываются к физическим машинам без перемещения самих данных. Это снижает нагрузку на сеть, но требует продуманной схемы маршрутизации.

Популярны и гибридные схемы:

• фоновая миграция с приоритетом наименее загруженных реплик;
• двухфазное переключение: сначала дублирование, затем отключение исходника;
• балансировка по расписанию в часы минимального трафика.

Ключевой принцип — идемпотентность операций и возможность отката без потери целостности.

Маршрутизация запросов: от клиентского до прокси-серверного подхода

Путь обращения к сервису начинается на стороне пользователя. Клиентское приложение определяет адрес, но реальное распределение нагрузки происходит выше — на уровне балансировщика. Прокси-сервер выступает посредником: он принимает трафик, анализирует состояние бэкендов и перенаправляет запросы по алгоритмам (round-robin, least-connections, consistent hashing).

Для критичных систем важна не только скорость, но и отказоустойчивость. Поэтому схемы маршрутизации часто включают:

• проверку здоровья узлов (health checks);
• таймауты и ретраи;
• ограничение скорости (rate limiting).

Выбор между L4- и L7-балансировкой зависит от протокола: TCP-прокси быстрее, HTTP-прокси позволяет гибко управлять кэшированием и аутентификацией.

Пакетная обработка данных в высоконагруженных системах

Пакетная обработка остаётся фундаментом для задач, не требующих мгновенного ответа. Вместо потоковой передачи здесь данные накапливаются и обрабатываются крупными порциями — это упрощает оптимизацию и снижает нагрузку на инфраструктуру.

Классический пример — ночной пересчёт агрегатов или построение отчётов. Такой подход хорошо масштабируется горизонтально: задачу можно разбить на части и выполнять параллельно на множестве узлов.

Ключевые принципы организации:

• Идемпотентность операций — повторный запуск не должен ломать результат.
• Чекпоинты для восстановления после сбоев.
• Разделение данных на независимые партиции.

Инструменты вроде Hadoop MapReduce или Spark позволяют распределять вычисления, но требуют тщательной настройки. Важно помнить: пакетный режим не подходит для низколатентных сценариев, где задержка критична.

MapReduce и его ограничения по Клеппману

Мартин Клеппман в своей работе о распределённых системах отмечает, что классическая модель MapReduce, при всей её исторической значимости, плохо подходит для задач, требующих интерактивного отклика. Она ориентирована на пакетную обработку, где результат не нужен мгновенно. Основная претензия — материализация промежуточных данных на диск между фазами map и reduce, что создаёт избыточную задержку. Для итеративных алгоритмов машинного обучения такой конвейер оказывается слишком медленным, поскольку каждый шаг требует повторного чтения данных с диска.

Вместо этого Клеппман предлагает рассматривать более гибкие модели исполнения, например, на основе направленных ациклических графов (DAG), которые позволяют эффективнее управлять потоком данных и избегать лишних сериализаций. Ключевой вывод: архитектура, хорошая для пакетного анализа, не является универсальным решением для всех видов нагрузок.

Конвейеры пакетной обработки: сортировка и соединение больших объёмов

Пакетные конвейеры незаменимы, когда данные не требуют мгновенного отклика. Классический пример — ночной пересчёт агрегатов или построение поискового индекса. Соединение двух терабайтных наборов часто реализуют через сортировку слиянием: сначала упорядочивают обе стороны, затем проходят по ним двумя указателями. Это избавляет от случайных чтений с диска. Альтернатива — хэш-соединение, где меньшая таблица помещается в память как словарь. Для сортировки объёмов, не влезающих в RAM, применяют внешнюю многофазную схему: разбивку на прогоны, их сортировку и каскадное слияние. Подобные задачи хорошо ложатся на MapReduce-парадигму, где перемешивание данных происходит между мапперами и редьюсерами.

Потоковая обработка событий для реального времени

Когда данные прибывают непрерывно, пакетная обработка не успевает за темпом. На помощь приходит потоковая модель: она анализирует информацию по мере поступления, а не порциями. Такой подход критичен для мониторинга, трейдинга и аналитики пользовательских действий. Задержка снижается до миллисекунд, а система успевает реагировать на изменения мгновенно. Архитектура строится на брокерах сообщений и процессорах, которые обеспечивают сквозную передачу данных без потерь.

Потоковые системы: от Kafka до сложных событийных платформ

Эволюция обработки данных в реальном времени прошла путь от простых очередей сообщений до распределённых платформ, способных анализировать миллионы событий в секунду. Если Apache Kafka стала де-факто стандартом для транспортировки логов и метрик, то современные системы вроде Flink или Pulsar добавляют к этому вычислительные возможности и гарантии доставки. Ключевое различие — в модели потребления: Kafka хранит поток на диске, позволяя перечитывать его, тогда как стриминговые движки обрабатывают данные «на лету», минимизируя задержки. Для архитектора важно понимать, что выбор между ними определяется не популярностью, а требованиями к консистентности и допустимой задержкой. Например, для финансовых транзакций критична идемпотентность, а для IoT-телеметрии — пропускная способность.

Гарантии доставки и обработка событий ровно один раз

В распределённых системах классическая модель «at-most-once» (не более одного раза) часто приводит к потерянным сообщениям, а «at-least-once» (как минимум один раз) — к дубликатам. Промежуточный вариант — идемпотентные потребители и дедупликация на стороне получателя. На практике это означает: провайдер фиксирует offset после успешной обработки, а не после чтения. Если процесс упал между этими операциями, повторная доставка неизбежна, но она не нарушит консистентность, если обработчик умеет отличать повтор от нового события.

Для этого применяют:

• уникальные идентификаторы сообщений (UUID) и проверку по хранилищу;
• транзакционные таблицы с атомарным обновлением статуса;
• брокеры с поддержкой транзакций (Kafka, Pulsar).

Гарантия «ровно один раз» — это компромисс между производительностью и надёжностью. Полная строгость требует координации между брокером и БД, что увеличивает задержку. Поэтому часто выбирают «эффективно один раз»: дубликаты возможны, но их последствия устраняются бизнес-логикой.

Целостность данных и согласованность в конечном счёте

В распределённых системах невозможно одновременно гарантировать строгую целостность и высокую доступность. Инженеры вынуждены выбирать: либо блокировать операции ради мгновенной консистентности, либо разрешать временные расхождения. Модель конечной согласованности предполагает, что система в итоге придёт к единому состоянию, но в промежуточный момент разные узлы могут видеть разные версии данных. Такой подход характерен для NoSQL-хранилищ и событийных архитектур.

На практике это означает:

• запись подтверждается до того, как реплики получат обновление;
• чтение из вторичной копии может вернуть устаревший ответ;
• конфликты разрешаются фоновыми процессами или стратегией последней записи.

Для критичных операций (платежи, бронирование) применяют компенсирующие транзакции или саги, чтобы откатить частично выполненные шаги. Ключевой инструмент — векторные часы и версионирование записей, позволяющие отслеживать причинно-следственные связи между событиями.

Компромиссы CAP-теоремы и выбор конфигурации для вашего сервиса

Согласно теореме CAP, распределённая система не может одновременно гарантировать согласованность, доступность и устойчивость к разделению. На практике всегда приходится жертвовать одним из свойств. Если сетевой сбой неизбежен, выбор стоит между CP (консистентность) и AP (доступность).

Для финансовых транзакций предпочтительнее CP-режим, где данные не разойдутся, но возможны кратковременные отказы. Для социальных сетей и каталогов товаров логичнее AP-подход — система отвечает всегда, даже если ответ содержит устаревшие сведения.

При проектировании учитывайте допустимую задержку и бизнес-требования. Например, для корзины покупок лучше AP, а для банковского перевода — строгая CP. Гибридные схемы, когда разные подсистемы используют разные модели, часто оказываются оптимальным решением.

Достижение консенсуса: Raft, Zab и лидерство в кластере

Когда распределённая система выходит из строя, узлам нужно договориться о едином состоянии. Для этого применяются протоколы, где один узел временно становится главным, а остальные следуют его указаниям. Raft и Zab — два популярных подхода к такой координации.

• Raft делает упор на понятность: выборы лидера, репликация логов и безопасность разделены на чёткие этапы.
• Zab, используемый в Apache ZooKeeper, ориентирован на строгий порядок транзакций и быстрое восстановление после сбоев.

Оба механизма гарантируют, что даже при потере части серверов система продолжит работу без расхождений в данных.