Георгий Димитриади – Руководство по созданию высоконагруженных систем (страница 4)

Система может быть высокодоступной, но ненадежной. Пример: скрипт, который перезапускает упавший сервис каждую секунду. MTTR составляет 1 секунду, поэтому доступность стремится к 100%, однако надежность крайне низка, так как сервис постоянно падает (MTBF мал).

Компромисс: Повышение доступности требует введения избыточности (резервирования), что подробно рассматривается в Главе 4. Каждая дополнительная копия сервера или базы данных увеличивает капитальные и операционные затраты, а также сложность синхронизации, но снижает MTTR и минимизирует единую точку отказа (SPOF - Single Point of Failure).

2.3. Консистентность данных

Консистентность определяет, насколько данные в разных частях системы соответствуют друг другу и реальности.

Сильная консистентность (Strong Consistency): После завершения операции записи все последующие операции чтения во всей системе гарантированно вернут новое значение. Это свойство требует синхронной репликации и блокировок, что напрямую увеличивает латентность.

Конечная консистентность (Eventual Consistency): Если в систему не поступают новые обновления, через некоторое (не гарантированное) время все реплики данных придут к единому значению. В момент сразу после записи чтение может вернуть как старое, так и новое значение. Это позволяет достичь минимальной латентности записи.

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

2.4. Практические кейсы столкновения параметров

Кейс 1: Фронтальная система обработки платежей

Требования: Нулевая потеря транзакций, защита от двойного списания.

Выбор: Приоритет - Консистентность (C) и Надежность (Reliability).

Реализация: Использование распределенных транзакций (например, паттерн Saga или протокол двухфазного коммита 2PC). Каждая запись подтверждается минимум двумя узлами хранилища.

Цена компромисса: Высокая латентность (пользователь ждет подтверждения 1–2 секунды) и низкая доступность при сбое одного из узлов подтверждения (транзакция отклоняется). Стоимость владения (TCO) высока из-за необходимости поддержки синхронно работающих кластеров.

Кейс 2: Глобальный сервис микроблогинга (лента новостей)

Требования: Мгновенная публикация контента, поддержка миллионов одновременных сессий.

Выбор: Приоритет - Латентность (L) и Доступность (A).

Реализация: Асинхронная запись в очередь (Message Queue), последующая фоновая сборка ленты из кэша (например, в Redis). Используется конечная консистентность.

Цена компромисса: Пользователь видит свой пост мгновенно, но его подписчики могут увидеть его с задержкой до 5–10 секунд. В случае сбоя одного из серверов кэша лента части пользователей может не обновиться, но общая работоспособность системы сохранится.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.