Распределённые системы
CAP на практике: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту CAP — формальные определения C/A, выбор CP/AP при разделении, компромисс PACELC в штатном режиме, логические разделения и разрешение конфликтов в AP.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте на дежурстве — не аббревиатуру для заучивания, а компромисс, который надо отстоять, пока сеть молчит.
Цель
Убедись, что связываешь формальные определения CAP, бинарный выбор CP/AP при разделении, компромисс задержки и согласованности по PACELC в штатном режиме и production-сбои — тот синтез, к которому вёл урок.
Викторина
Completed
Вендор рекламирует свою БД как «всегда доступна, полностью согласована, устойчива к разделениям — CAP-полная». Почему это утверждение бессвязно с точки зрения доказательства Gilbert-Lynch?
Heads-up Raft — это CP: когда разделение изолирует лидера от большинства, меньшинство отклоняет чтения и записи ради линеаризуемости. Оно покупает согласованность, отказываясь от доступности на изолированной стороне, а не обходя теорему.
Heads-up Разделения физически неизбежны — обрыв кабелей, флапы BGP, паузы гипервизора. P обязательно, и именно поэтому выбор C-против-A становится вынужденным, а не бесплатным обедом.
Heads-up Аптайм — это операционный SLA, а не свойство живучести на каждый запрос, которое определяет CAP. Кластер «пять девяток» всё равно может быть формально CP и отклонять запросы во время разделения.
Викторина
Completed
Кластер etcd из 5 узлов разделён на 2-3. Сторона из 2 узлов отклоняет все чтения и записи ошибками; сторона из 3 узлов продолжает обслуживать. Как классифицировать это поведение?
Heads-up Доступность в CAP требует, чтобы каждый работающий узел отвечал успешно. Меньшинство из 2 узлов возвращает ошибки, поэтому система в целом жертвует A — это CP, а не AP.
Heads-up Меньшинство, продолжающее принимать записи, ушло бы в split-brain и нарушило линеаризуемость. Отказ — корректное, намеренное CP-поведение для кворумной системы вроде etcd.
Heads-up Отсутствие потерь данных — свойство долговечности, не связанное с осью A/C в CAP. Именно неспособность меньшинства ответить успешно делает это CP.
Викторина
Completed
Двое инженеров выбрали «CP». Один говорит, что чтения в другом регионе теперь добавляют 80 мс; другой настаивает, что CP ничего не меняет при здоровой сети. Кто прав и почему?
Heads-up Весь смысл PACELC в том, что строгая согласованность стоит задержки даже при здоровой сети: линеаризуемое чтение/запись обязано синхронно координироваться между репликами, добавляя RTT. Системы PC/EC платят это постоянно.
Heads-up Задержка межрегиональной координации — это сетевой RTT между репликами, а не диск. Синхронное кворумное подтверждение между датацентрами — главная цена для EC-систем.
Heads-up 80 мс — это неотъемлемая цена синхронной координации (EC), а не ошибка конфигурации. PACELC предсказывает ровно этот обмен задержки на согласованность в здоровом состоянии «Else».
Викторина
Completed
Классифицируй Google Spanner и Amazon DynamoDB (по умолчанию) по оси PACELC и скажи, что это предсказывает о каждом.
Heads-up Облачный хостинг ничего не говорит о позиции в CAP/PACELC. Spanner намеренно выбирает согласованность (PC/EC) и принимает задержку координации; только DynamoDB по умолчанию PA/EL.
Heads-up Это перевёрнуто. Spanner блокирует, а не отдаёт устаревшие данные (PC/EC); DynamoDB по умолчанию остаётся доступным и eventually consistent (PA/EL).
Heads-up Они предсказывают конкретное поведение: PC/EC отклоняет записи при разделении и добавляет RTT при здоровой сети; PA/EL продолжает обслуживать и может вернуть устаревшее чтение. Ярлыки соответствуют наблюдаемым решениям.
Викторина
Completed
Здоровый CP-лидер прекрасно переживает сеть, но получает stop-the-world паузу GC на 10 секунд; пиры немедленно запускают перевыборы лидера. К какому классу относится первопричина?
Heads-up Raft использует логические термы и порядковые номера, а не синхронизацию настенных часов. Триггер — пропущенные heartbeat от приостановленного узла, а не дрейф часов.
Heads-up Пауза GC останавливает потоки приложения; она никогда не трогает NIC или сетевой стек ОС. Узел достижим, но не отвечает — это логическое разделение.
Heads-up Это разрушительно: кластер теряет лидера, блокирует записи на время выборов, а незавершённая работа старого лидера пропадает. Поэтому важны pre-vote и настроенные таймауты.
Викторина
Completed
Ты держишь AP-хранилище (в стиле Cassandra/DynamoDB) и разрешаешь конкурентные записи через Last-Write-Wins по настенным меткам времени. В чём скрытый режим сбоя?
Heads-up «Самая свежая» определяется метками часов, а часы дрейфуют. Действительно более поздняя запись на отстающем узле проигрывает более ранней с большей меткой — LWW молча выбрасывает реальные данные.
Heads-up Он ломается на обычных конкурентных записях через разделение с расходящимися часами — потеря датацентра не нужна. Это повседневный налог на разрешение конфликтов в AP.
Heads-up Можно остаться AP и починить разрешение конфликтов через CRDT или векторные часы, которые объединяют или упорядочивают записи без единого победителя по настенным часам. Переход на CP — один из вариантов, а не единственный.
Итог
Сквозная линия: P — не выбор, поэтому разделение вынуждает бинарное решение CP-против-AP — блокировать/ошибаться ради линеаризуемости или оставаться отзывчивым и отдавать расхождение. PACELC расширяет это на штатный режим, где строгая согласованность всё равно стоит задержки. Production-ловушки — заявления вендоров о «CAP-полноте», логические разделения от пауз GC и молчаливая потеря записей в LWW при дрейфе часов — все сводятся к одной дисциплине: пользуйся формальными определениями, честно классифицируй систему по PC/EC vs PA/EL и тюнингуй под реальные требования корректности нагрузки.