CAP на практике: тест с выбором ответа
Тест с выбором на синтез по всему юниту CAP — формальные определения C/A, выбор CP/AP при разделении, компромисс PACELC в штатном режиме, логические разделения и разрешение конфликтов в AP.
Шесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте на дежурстве — не аббревиатуру для заучивания, а компромисс, который надо отстоять, пока сеть молчит.
Убедись, что связываешь формальные определения CAP, бинарный выбор CP/AP при разделении, компромисс задержки и согласованности по PACELC в штатном режиме и production-сбои — тот синтез, к которому вёл урок.
Вендор рекламирует свою БД как «всегда доступна, полностью согласована, устойчива к разделениям — CAP-полная». Почему это утверждение бессвязно с точки зрения доказательства Gilbert-Lynch?
Кластер etcd из 5 узлов разделён на 2-3. Сторона из 2 узлов отклоняет все чтения и записи ошибками; сторона из 3 узлов продолжает обслуживать. Как классифицировать это поведение?
Двое инженеров выбрали «CP». Один говорит, что чтения в другом регионе теперь добавляют 80 мс; другой настаивает, что CP ничего не меняет при здоровой сети. Кто прав и почему?
Классифицируй Google Spanner и Amazon DynamoDB (по умолчанию) по оси PACELC и скажи, что это предсказывает о каждом.
Здоровый CP-лидер прекрасно переживает сеть, но получает stop-the-world паузу GC на 10 секунд; пиры немедленно запускают перевыборы лидера. К какому классу относится первопричина?
Ты держишь AP-хранилище (в стиле Cassandra/DynamoDB) и разрешаешь конкурентные записи через Last-Write-Wins по настенным меткам времени. В чём скрытый режим сбоя?
Сквозная линия: P — не выбор, поэтому разделение вынуждает бинарное решение CP-против-AP — блокировать/ошибаться ради линеаризуемости или оставаться отзывчивым и отдавать расхождение. PACELC расширяет это на штатный режим, где строгая согласованность всё равно стоит задержки. Production-ловушки — заявления вендоров о «CAP-полноте», логические разделения от пауз GC и молчаливая потеря записей в LWW при дрейфе часов — все сводятся к одной дисциплине: пользуйся формальными определениями, честно классифицируй систему по PC/EC vs PA/EL и тюнингуй под реальные требования корректности нагрузки. Теперь, когда видишь конфиг распределённой системы на code review, у тебя есть два вопроса: что делает эта настройка при разделении и сколько она стоит в штатном режиме — ответы сразу ложатся в фреймворк CAP/PACELC, который ты только что отработал.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.