Время и порядок: почему таймстемпы по настенным часам врут

Пользователь меняет адрес доставки, видит тост об успехе, делает рефреш — и старый адрес вернулся. Ни ошибки, ни строки в логе, ни исключения. Кластер Cassandra использовал last-write-wins по клиентскому таймстемпу, а часы на узле, обработавшем апдейт, отставали на 1.2 секунды. Поэтому «новая» запись пришла со штампом раньше, чем строка, которую должна была заменить. База сравнила два числа, оставила большее и выбросила изменение пользователя как устаревшее. Про таймстемпы она говорила правду, про реальность — врала.

Настенные часы — не те часы, по которым можно упорядочивать

У каждой машины есть кварцевый кристалл, который дрейфует — обычно на десятки частей на миллион, поэтому свободные часы уплывают на миллисекунды в минуту и секунды в сутки. NTP это правит, периодически подгоняя (slew) или прыгая (step) к эталону. Прыжок — опасная часть: когда локальные часы достаточно сильно ушли, ntpd прыгает ими, и этот прыжок может пойти назад. На несколько сотен миллисекунд «сейчас» оказывается раньше, чем «сейчас», которое ты уже прочитал. По флоту из десятков узлов даже здоровый NTP оставляет skew порядка миллисекунд; упавший демон NTP или VM, приостановленная гипервизором, разгоняют это до секунд или минут.

Поэтому таймстемп, сгенерированный на машине A, и таймстемп с машины B несравнимы как порядок. У них общие единицы измерения и больше ничего. В тот момент, когда твоя корректность зависит от того, что tsA < tsB означает «A произошло раньше B», ты построил на песке.

Last-write-wins — потеря данных в ожидании сдвига часов

Баг с адресом — каноничный продакшен-провал, и он встроен в любую систему, которая разрешает конфликты сравнением настенных таймстемпов: Cassandra, Riak, хранилища в стиле DynamoDB в режиме LWW. Правило — «оставить запись с наибольшим таймстемпом». Когда часы разъехались, наибольший таймстемп — это не самая поздняя запись, а запись с узла, чьи часы спешат. По-настоящему более новая запись проигрывает, и, что критично, клиент получает успешный ответ. Нет ошибки, которую можно поймать, нет метрики для алерта. Данные просто исчезли, и узнаёшь ты об этом, когда жалуется клиент.

С удалениями хуже. Tombstone, записанный с таймстемпом в далёком будущем — баговый клиент, узел с часами, прыгнувшими вперёд, — подавит любую реальную запись ниже себя, пока compaction не соберёт tombstone мусором, а это могут быть дни. Один сдвинувшийся узел способен стереть ключ на неделю. Анализ Jepsen сформулировал прямо: настенные таймстемпы — фундаментально небезопасный конструкт для упорядочивания.

Логические часы: упорядочивать события без доверия к стене

Фикс — перестать измерять физическое время и начать измерять причинность. Таймстемп Лампорта — это один счётчик на процесс: инкремент на каждое локальное событие, а при получении сообщения выставляешь счётчик в max(local, received) + 1. Это гарантирует: если событие A happens-before B (A причинно предшествует B), то L(A) < L(B). Получаешь согласованный полный порядок бесплатно, за O(1) памяти на событие.

Чего часы Лампорта не умеют — это обратное: L(A) < L(B) не означает, что A вызвало B. Два события на узлах, которые никогда не общались, могут быть по-настоящему конкурентными, но Лампорт всё равно навязывает им произвольный порядок — он не умеет детектировать конкурентность, только навязать порядок. Для системы разрешения конфликтов эта слепота — и есть вся проблема: тебе нужно знать, что две записи конкурентны, чтобы их слить, а не молча выбрать одну.

Векторные часы это возвращают. Каждый узел несёт вектор — по счётчику на каждый узел системы — и шлёт весь вектор с каждым сообщением. Теперь можно сравнить два события: если каждая компонента A ≤ компоненты B и хотя бы одна строго меньше, то A happens-before B; если ни один вектор не доминирует над другим, события конкурентны, и система может поднять обе версии (siblings), чтобы приложение их слило. Цена — вот загвоздка: O(n) памяти на штампованное значение, где n — число узлов, плюс метаданные едут с каждой записью. На кластере в 200 узлов это 200 счётчиков, прицепленных к данным, и вектор растёт вместе с кластером.

TrueTime: заплати железом, чтобы настенные часы стали честными

Spanner от Google делает противоположную ставку: вместо отказа от физического времени — сделать его надёжным и квантифицировать своё незнание. TrueTime ставит в каждый датацентр GPS-приёмники и атомные часы, синхронизируемые примерно каждые 30 секунд, и отдаёт TT.now() не как один момент, а как интервал [earliest, latest]. Ширина этого интервала — неопределённость ε — обычно около 1мс (меньше 1мс на 99-м перцентиле в опубликованных Google числах, иногда расширяясь до единиц миллисекунд, когда time master отвечает медленно).

Хитрая часть — commit-wait. Spanner назначает таймстемп коммита s, затем намеренно спит, пока TT.now().earliest > s — пока не станет уверен, что таймстемп лежит в прошлом везде. Это ожидание — размером с ε, несколько миллисекунд, и оно идёт параллельно с репликацией Paxos, поэтому часто стоит мало настенного времени. Выигрыш — внешняя согласованность (линеаризуемость по всей базе): если транзакция T1 закоммитилась до старта T2, таймстемп T1 гарантированно меньше таймстемпа T2 — глобально, без оговорок про skew. Spanner превращает неопределённость часов из тихого бага корректности в явную ограниченную цену по латентности.