CAP-теорема (Brewer): в распределённой системе нельзя одновременно гарантировать более двух из трёх свойств при сбоях сети (partition): согласованность (Consistency, C), доступность (Availability, A) и устойчивость к разделению сети (Partition tolerance, P). При реальной сети P обязателен (разделения случаются), значит приходится выбирать между C и A.
Краткие определения:
- Consistency (C) — все клиенты видят одну и ту же версию данных (по завершении операции).
- Availability (A) — каждый корректный запрос получает ответ (не обязательно с последними данными).
- Partition tolerance (P) — система продолжает работать при потере/задержках сообщений между узлами.
Применение к распределённому кэшу для онлайн-игры — возможный сценарий и компромиссы
Исходные требования игры (пример):
- Низкая задержка для позиционирования/обновления игрока (мс).
- Корректные транзакции с виртуальной валютой/инвентарём (нельзя потерять монету).
- Глобальная аудитория, кластеры в нескольких регионах (разделения возможны).
Архитектурная стратегия (рекомендация — гибридный подход):
1. Разделение по критичности данных
- Критичные данные (платежи, инвентарь, транзакции): требовать C over A (CP). Обосновать: неверные или конфликтные операции с балансом недопустимы.
- Эпhemeral/скоростные данные (позиции игроков, эффект частиц, видимые состояния): требовать A over C (AP) или eventual consistency — доступность и низкая задержка важнее, небольшая рассинхронизация допустима.
- Метрики/лидерборды: eventual consistency / CRDTs.
2. Технические механизмы для CP для критичных данных
- Хранить авторитетные операции в централизованном согласованном хранилище (Paxos/Raft) или с мастером на регион; при разделе предпочесть отказ по доступности, чтобы избежать рассинхронивания.
- Использовать кворумы: если репликаций $N$, выбирать $W,R$ такие, что $$R+W>N$$ чтобы читать последние данные; пример: $N=3,W=2,R=2$.
- Минусы: увеличенная задержка (ожидание кворума), возможная недоступность при расколе сети.
3. Технические механизмы для AP для не критичных данных
- Репликация с асинхронным распространением, TTL, write-behind или cache-aside; использовать event sourcing/публикацию изменений.
- Применять слияние конфликтов через CRDT или last-write-wins (LWW) когда допустимо.
- Плюсы: высокая доступность и низкая задержка при разрывах; минусы — возможная устарелость данных и необходимость компенсационных операций.
4. Практическая топология и поведение при разделе
- Локальные региональные кэши для быстрого отклика (read-local). На запись — либо маршрутизировать в региональный мастер (локальный CP) либо писать в глобальный мастер (удлинённый путь).
- При partition: для данных, где выбрана CP — отклонять/задерживать операции до восстановления кворума (поведение «fail closed»). Для данных, где выбрана AP — продолжать обслуживать и потом реплицировать/сливать («eventual apply»).
- Для уменьшения ошибок применить комбинацию: обслуживать временно из кеша с пометкой «stale», запрещать критичные операции офлайн.
5. Примеры компромиссов и почему
- Компромисс 1: жертвую доступностью для транзакций валюты (CP). Почему: корректность финансов важнее кратковременной недоступности.
- Компромисс 2: жертвую строгой согласованностью для позиционирования/видимости (AP). Почему: игроки ценят плавность и малую задержку; небольшая расхожесть в позициях быстро корректируется.
- Компромисс 3: усложняю логику приложения (разделяю данные по модели консистентности), но получаю оптимальные UX для разных сценариев.
Дополнительные практические меры
- Версионирование объектов, vector clocks или CRDT для упрощения слияния.
- Read-repair и background reconciliation.
- Наблюдаемость и деградация UX: показывать игроку, если данные потенциально устарели.
- Тестирование сценариев partition и стресс-тесты кворумных настроек.
Итог: P обязателен. Для кэша онлайн-игры логично применять гибрид — CP для экономически критичных операций (обеспечивая согласованность жертвуя доступностью при разделе) и AP/eventual для скоростных, нечётких данных (обеспечивая доступность и низкую латентность). Выбор конкретных механизмов (кворумы, Raft, CRDT, TTL) определяется требованиями задержки и допустимой степенью рассинхронизации.