Распределённые системы
CAP на практике: построй и раздели реплицированное хранилище
Прочитать, что «разделение вынуждает выбор CP-или-AP» — не то же самое, что увидеть, как твои собственные записи расходятся, и примирить их руками. Построй крошечное реплицированное key-value хранилище, разорви канал между репликами и заставь одну и ту же систему вести себя как CP, а затем как AP — с логом запросов в качестве доказательства.
Преврати ментальную модель юнита в то, что можно запустить: докажи, что P не опционально, что позиции CP и AP — наблюдаемое поведение, что строгая согласованность стоит задержки даже при здоровой сети (PACELC) и что налог AP на разрешение конфликтов реален.
Построй реплицированное key-value хранилище из 3 узлов, запускаемое локально, инжектируй управляемое разделение сети между репликами и продемонстрируй — с логированными чтениями, записями и задержками — конфигурацию CP и конфигурацию AP на одном и том же коде, затем корректно примири расхождение AP.
- Лог запросов (или транскрипт), показывающий прогон CP: сторона-меньшинство возвращает ошибки/таймауты во время разделения, большинство обслуживает, и устаревшее/расходящееся чтение никогда не наблюдается.
- Лог запросов, показывающий прогон AP: обе стороны принимают записи во время разделения, порождая два расходящихся значения для одного ключа — зафиксированных, а не описанных.
- Транскрипт примирения, доказывающий, что конкурентные записи слиты (siblings по векторным часам или слияние CRDT), с явной демонстрацией, что наивный LWW по метке времени отбросил бы одну из них.
- Таблица задержек: p50 штатного режима для строгой (EC) против слабой (EL) настройки, показывающая обмен согласованности на задержку, который предсказывает PACELC.
- README корректно приписывает каждое поведение механизму CAP/PACELC, который его вызвал.
- Добавь асимметричное разделение (A достигает B, но ответы B к A отбрасываются) и покажи, чем оно отличается от чистого разрыва — например, узел, продолжающий действовать по одностороннему виду.
- Инжектируй логическое разделение: приостанови процесс одной реплики (SIGSTOP) дольше таймаута heartbeat и покажи, как пиры трактуют здоровый-но-медленный узел как упавший, запуская перевыборы или эвикцию.
- Добавь режим кворумного лидера (в стиле Raft) с pre-vote и настраиваемым election timeout и продемонстрируй, как слишком низкий таймаут при джиттерной задержке фабрикует ложные выборы.
- Выстави согласованность на каждый запрос (как уровень CONSISTENCY в Cassandra) и покажи, как один клиент сдвигает один и тот же ключ между CP-подобным и AP-подобным поведением запрос за запросом.
Это петля за каждым реальным design review распределённых систем: P — не выбор, поэтому ты решаешь CP-или-AP на каждое разделение, задавая ручки кворума и согласованности; ты доказываешь позицию наблюдаемыми чтениями и записями, а не прилагательными; ты платишь налог задержки PACELC всякий раз, когда требуешь согласованности в штатном режиме; а примирение AP безопасно только с настоящей логикой слияния, никогда — с настенным LWW. Построив это однажды на игрушечном хранилище, ты превращаешь теорему в инстинкт.