Краш-устойчивое key-value хранилище с WAL

До долговечности спроектируй дисковый формат. WAL — это последовательность самоописывающихся записей, дописываемых в один растущий файл, и каждый последующий этап — восстановление, контрольные суммы, усечение — зависит от того, можешь ли ты пройти этот байтовый поток запись за записью. Фрейми каждую запись как длина-префикс + тип + payload (и зарезервируй хвостовой слот под CRC, который добавишь на этапе 5), потому что без длины ты не найдёшь, где начинается следующая запись, а оборванный хвост станет неотличим от реальных данных. Реши единицу аппенда: мелкие записи (одна мутация на каждую) держат латентность низкой, но тратят байты заголовка; крупные батч-записи амортизируют оверхед фрейминга. Реальная запись WAL — это десятки байт заголовка над payload, и, скажем, при 64-байтных значениях оверхед фрейминга нужен ниже ~20%, чтобы лог не удваивал объём записи. Построй writer, который дописывает фреймы, и reader, который их обходит, пока без всяких гарантий долговечности — это работа следующего этапа.

Теперь сделай так, чтобы «вызов вернулся» означало «данные переживут потерю питания». write(2) лишь копирует байты в page cache ОС; пока fsync(2) (или fdatasync) не вытолкнет их на стабильное хранилище, краш теряет их молча. Поэтому контракт долговечности такой: допиши фрейм, сделай fsync, затем подтверди — никогда не подтверждай до возврата fsync. Загвоздка в цене: один fsync на SSD ~0.5–3 мс, а на вращающийся диск 5–10+ мс, так что наивный дизайн один-fsync-на-запись упирается в несколько сотен — низкие тысячи записей/сек, как бы быстр ни был CPU. Group commit это лечит: буферизуй конкурентных писателей, делай один fsync на весь батч, затем подтверждай всех вместе. Один fsync, амортизированный по батчу из 100, превращает запас в ~1000 fsync/сек в ~100k подтверждений/сек — ценой добавленной латентности (писатель ждёт до окна батча). Настрой окно батча (например, 1–5 мс или N ожидающих) и измерь кривую пропускная-способность-против-латентности, которую ты только что купил.

WAL бесполезен, если ты не можешь восстановить из него состояние после краша. На старте реплей идёт по логу с начала, применяя каждую корректную запись для восстановления состояния в памяти, и чисто останавливается на первой записи, которую не может полностью разобрать, — оборванном хвосте записи, прерванной между аппендом и fsync. Ключевой инвариант: восстановление должно быть идемпотентным и детерминированным по префиксу: повторный реплей того же лога даёт идентичное состояние, а оборванная последняя запись отбрасывается, а не применяется наполовину, потому что ты подтверждал только те записи, чей fsync завершился, так что всё после последней целой записи никогда не обещалось вызывающему. Внедряй краши (усекай файл по случайным смещениям или убивай посреди записи под fault-стендом) и докажи, что восстановленное состояние точно совпадает с множеством подтверждённых записей — без потерянных ack, без фантомных записей из оборванного хвоста. Заметь: время восстановления растёт с длиной лога: лог в 1 ГБ, реплеенный со, скажем, нескольких сотен МБ/с, — это секунды старта, и именно это давление вынуждает следующий этап.

Неограниченный лог означает неограниченное время восстановления и неограниченный диск. Чекпойнтинг это ломает: периодически сбрасывай текущее материализованное состояние в долговечный snapshot-файл, записывай смещение лога, которое этот снапшот покрывает, затем усекай (или ротируй в новый сегмент и удаляй старые) всё до него. Восстановление тогда становится загрузкой-снапшота + реплеем-только-хвоста, превращая многосекундный холодный старт в почти константный. Компромиссы реальны: чекпойнть слишком часто — платишь I/O записи снапшота, который конкурирует с фоновыми записями; слишком редко — восстановление и диск раздуваются. Порядок — это мина долговечности: ты должен сделать fsync снапшота и нового маркера смещения чекпойнта до усечения старого лога, иначе краш посреди чекпойнта оставит тебя без полного снапшота и без только что удалённых записей лога. Сегментируй лог в файлы фиксированного размера, чтобы усечение было атомарным unlink целых сегментов, а не рискованным переписыванием файла на месте.

Преврати долговечный лог в пригодное key-value хранилище. Паттерн — это парадная дверь LSM: запись дописывает запись (ключ, значение) в WAL для долговечности, затем обновляет in-memory memtable (отсортированную карту), которая обслуживает чтения — так что WAL — это хребет долговечности, а memtable — быстрое запрашиваемое представление. Их согласованность держится порядком: сначала WAL-аппенд + fsync, потом обновление memtable, так что краш может потерять лишь то, что никогда не подтверждалось. Когда memtable перерастает порог, сбрось его как отсортированную дисковую таблицу и, критически, только тогда отбрось префикс WAL, который он покрывал, — флаш это просто специализированный чекпойнт, и применяется то же правило fsync-до-усечения из этапа 4. Get(key) проверяет memtable, затем откатывается к сброшенным таблицам. Это момент, когда проект перестаёт быть логом и становится storage-движком, и он вынуждает тебя рассуждать о read-your-writes: подтверждённая запись обязана быть видна самому следующему чтению.

Тихое повреждение — враг, ради которого существует контрольная сумма. Добавь CRC32 (слот, который ты зарезервировал на этапе 1) по заголовку+payload каждой записи; на реплее пересчитывай и сравнивай, чтобы оборванная запись, переворот бита или наполовину записанный сектор обнаруживались, а не применялись как реальные данные. Это граница между «восстанавливается чисто» и «перестраивает повреждённое состояние и отдаёт его вечно». Затем сделай движок наблюдаемым: счётчики записей/сек, латентность fsync p50/p99, размер батча group-commit, размер memtable и число флашей, время восстановления — те же RED-образные сигналы, что эмитит реальный storage-движок. Наконец, проведи инцидент: симулируй оборванную запись (усеки активный сегмент посреди записи) И потерянный fsync (fault-слой, который отбрасывает эффект fsync, так что выглядящие подтверждёнными данные на самом деле не попали на диск). Покажи, что CRC ловит оборванную запись и восстановление на ней останавливается; затем покажи, что случай потерянного fsync — по-настоящему опасный — он может потерять подтверждённую запись — и порассуждай, почему врущие про fsync диски/ФС делают «долговечность» свойством всего твоего стека, а не только кода. Напиши короткий пост-мортем: какой отказ твой дизайн переживает, какой нет, и одну митигацию, которая не «fsync-ай сильнее».