Модуль 14 ⏱ ~31 мин чтения 📐 3 Mermaid диаграмм

5. Time и clock drift

В предыдущих лекциях мы выяснили, что сеть обрывает соединения, задерживает пакеты и оставляет нас в подвешенном состоянии неизвестности. Но есть еще один компонент классического монолита, который безнадежно ломается при переходе к распределенной архитектуре.

Это Время.

Представьте классический разбор инцидента (Post-Mortem) после ночной аварии. Вы открываете централизованную систему сбора логов и пытаетесь восстановить причинно-следственную цепочку событий по таймстемпам:

  1. Запрос пришел в API Gateway в 12:00:01.000.
  2. В 12:00:01.050 Order Service создал заказ.
  3. В 12:00:01.040 Billing Service списал деньги.

Стоп. Сервис Billing списал деньги за 10 миллисекунд до того, как Order Service сформировал заказ?
С точки зрения бизнес-логики и здравого смысла это грубейшее нарушение причинности (Causality). Но именно такую абсурдную картину вы регулярно будете наблюдать в сырых логах.

Добро пожаловать в проблему дрейфа часов (Clock Drift).

Физика времени (Mechanical Sympathy)

Как компьютерный сервер вообще понимает, который сейчас час?

На материнской плате каждого сервера распаян крошечный кварцевый резонатор (Quartz Oscillator). Это кристалл синтетического кварца, который под воздействием пьезоэлектрического эффекта вибрирует с фиксированной эталонной частотой (обычно 32 768 Гц для часов реального времени RTC). Аппаратный счетчик считает количество колебаний и транслирует их в секунды, минуты и часы.

Но реальный физический мир неидеален. Частота колебаний кварцевого кристалла непрерывно плывет под воздействием внешних факторов:

  1. Температура в серверной стойке: Когда процессор молотит вычисления под 100% нагрузкой, температура кристалла подскакивает с 35°C до 75°C. Термическое расширение кристаллической решетки меняет резонансную частоту: часы начинают либо спешить, либо отставать.
  2. Физическое старение кремния: С годами структура кристалла деградирует.
  3. Производственные допуски: Два абсолютно одинаковых сервера из одной партии, стоящие на соседних полках в стойке, тикают с разной скоростью.

Это физическое явление называется Clock Drift (Дрейф часов). Обычный серверный узел в дата-центрах AWS, GCP или собственной серверной гарантированно уплывает от истинного астрономического времени на несколько миллисекунд или даже секунд каждые сутки.

Иллюзия синхронизации: NTP

Чтобы серверы окончательно не разбежались в разные эпохи, в операционных системах используется протокол синхронизации сетевого времени — NTP (Network Time Protocol). Фоновый системный демон (ntpd или более современный chronyd) периодически обращается к серверам точного времени Stratum 1/2, подключенным к атомным эталонам или спутникам GPS.

Казалось бы, проблема решена?
Увы, здесь вступает в силу материал лекции 3. Latency и network fallacies: сетевые задержки стохастичны и несимметричны!

Когда демон chronyd отправляет UDP-пакет с вопросом: «Который сейчас час?», пакет летит 15 мс до эталонного сервера, а ответный пакет возвращается 45 мс из-за затора в буфере сетевого свитча. Сервер получает ответ: «Сейчас ровно 12:00:00.000», но это время было актуально где-то посередине пути!

Математические алгоритмы фильтрации NTP способны сглаживать статистический шум, но они бессильны победить физику сети. В реальном промышленном дата-центре расхождение часов между соседними серверами даже при идеально работающем NTP постоянно плавает в диапазоне от 1 до 20 миллисекунд.

А для современного процессора с тактовой частотой 3.5 ГГц 20 миллисекунд — это 70 000 000 тактов, за которые ядро успевает выполнить десятки миллионов инструкций!

Сдвиги времени (Time Steps)

Но самое опасное происходит тогда, когда NTP-демон обнаруживает, что часы сервера отстали или убежали вперед на заметную величину (например, после сетевого сбоя или выхода машины из сна).

Что делает демон ntpd? Если рассинхронизация превышает определенный порог, он не просто ускоряет ход часов (slewing), а совершает резкий скачок: принудительно переводит системное время назад (Time Step)!

sequenceDiagram
    autonumber
    participant App as Go Application
    participant OS as OS (Wall Clock gettimeofday)
    participant NTP as NTP Daemon (ntpd/chronyd)

    App->>OS: time.Now() (Запоминаем start)
    OS-->>App: 10:00:05.000 (Wall Clock)
    Note over App: Выполняется функция DoWork()...
    NTP->>OS: Синхронизация времени: Сдвиг назад на 1000 мс!
    Note over OS: Системное время сброшено на 10:00:04.000!
    App->>OS: time.Now() (Запоминаем end)
    OS-->>App: 10:00:04.500 (Wall Clock)
    Note over App: elapsed = end - start = -500 мс!<br>Отрицательная длительность!

Как Go решил эту проблему "под капотом"

Начиная с релиза Go 1.9, команда инженеров Google внедрила революционное и элегантное решение проблемы сдвигов времени прямо в стандартную библиотеку.

Операционная система Linux предоставляет два принципиально разных источника времени:

  1. Wall Clock (Настенные часы): Возвращаются системным вызовом gettimeofday или clock_gettime(CLOCK_REALTIME). Это календарное время суток (год, месяц, секунда). Они привязаны к часовым поясам, синхронизируются через NTP и могут совершать прыжки вперед и назад.
  2. Monotonic Clock (Монотонные часы): Возвращаются системным вызовом clock_gettime(CLOCK_MONOTONIC). Они отсчитывают монотонный прирост тиков таймера процессора с момента загрузки операционной системы. Они принципиально не могут идти назад.

Архитектурные катастрофы из-за времени

Если внутри одного процесса Go монотонные часы спасают нас от локального безумия, то в распределенной сети физическое время серверов превращается в источник тяжелейших аварий.

1. Last-Write-Wins (LWW) и тихая потеря данных

Многие распределенные NoSQL-базы данных (Apache Cassandra, ScyllaDB, Riak) по умолчанию используют стратегию разрешения конфликтов Last-Write-Wins (LWW): побеждает запись с самым большим timestamp.

Представим два узла:

  • Сервер А (часы спешат на 3 миллисекунды).
  • Сервер B (часы отстают на 3 миллисекунды).
sequenceDiagram
    autonumber
    participant U1 as Клиент 1
    participant U2 as Клиент 2
    participant SA as Сервер А (Спешит)
    participant SB as Сервер B (Отстает)
    participant DB as Распределенная БД (LWW)

    U1->>SA: Запрос: "Имя = Иван"
    Note over SA: Время Сервера А: 12:00:00.005<br>(Записано с опережением!)
    SA->>DB: Write (name="Иван", ts=12:00:00.005)

    Note over U1,U2: Проходит реальная 1 миллисекунда...

    U2->>SB: Запрос: "Имя = Петр" (ПОСЛЕДНЕЕ действие!)
    Note over SB: Время Сервера B: 12:00:00.002<br>(Часы отстают на 3 мс!)
    SB->>DB: Write (name="Петр", ts=12:00:00.002)

    Note over DB: LWW Сравнение:<br>12:00:00.005 > 12:00:00.002
    Note over DB: 🔥 БД оставляет имя "Иван"!<br>Свежее обновление "Петр" безвозвратно уничтожено!
  1. В момент времени $T$ Клиент 1 отправляет запрос на Сервер А. Тот берет локальное время 12:00:00.005 и отправляет запись в БД.
  2. Спустя мгновение Клиент 2 отправляет осознанное обновление на Сервер B. Тот ставит свой локальный timestamp 12:00:00.002 (потому что его кварц отстает).
  3. База данных сравнивает метки: 12:00:00.005 > 12:00:00.002.
  4. Система делает ошибочный вывод, что действие на Сервере А произошло позже.
  5. В итоге более свежее изменение Клиента 2 безвозвратно затирается старыми данными! Бизнес теряет обновления без каких-либо ошибок в логах.

2. Распределенные блокировки и катастрофа аренды

Представьте распределенную блокировку на базе Redis или etcd с временем жизни (TTL Lease) в 10 секунд:

  1. Сервер А успешно берет лок на обработку заказа. Он полагает, что у него есть 10 секунд монопольного доступа.
  2. В этот момент на Сервере А виртуальная машина уходит в кратковременный freeze (гипервизор выделил CPU другому клиенту), либо NTP-клиент резко корректирует время на 8 секунд вперед.
  3. Сервер А выходит из паузы. По его локальным часам прошло всего 2 секунды, и он считает себя владельцем лока.
  4. Но для сервера Redis таймер аренды давно истек! Redis считает Сервер А мертвым и выдает блокировку Серверу B.
  5. Теперь Сервер А и Сервер B одновременно пишут в базу данных, разрушая инварианты данных и списывая остатки товаров в минус (эту проблему мы детально исследуем в лекции 7. Distributed locks).

Исключение из правил: Google TrueTime

Существует единственное в мире инженерное исключение, где распределенная база данных смогла безопасно опереться на физическое время для глобальной сериализуемости транзакций (External Consistency) — это Google Cloud Spanner.

Инженеры Google осознали, что программно синхронизировать время по сети невозможно. Поэтому они перепроектировали само физическое железо дата-центров.

Каждая серверная зона Google Spanner оснащена специализированными аппаратными стойками TrueTime:

  • Набором атомных цезиевых часов (Atomic Clocks).
  • Приемниками сигналов системы GPS с независимыми антеннами на крышах.
flowchart LR
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    GPS["GPS Receivers (Спутники)"]:::process --> Master["TrueTime Master"]
    Atomic["Atomic Clocks (Цезиевые эталоны)"] --> Master
    Master -->|"TrueTime API"| Node["Spanner Node"]
    Node -->|"now() returns"| Interval["[earliest, latest]<br>Погрешность 1-7 мс"]
    Interval -->|"Commit Wait"| Safe["Гарантированный строгий порядок"]

API TrueTime не возвращает обманчивое скалярное значение time.Now(). Вместо этого вызов возвращает доверительный временной интервал:
[earliest, latest], где разница между границами составляет гарантированные физикой $\approx 1-7\text{ миллисекунд}$.

Если Spanner нужно гарантировать, что транзакция $T_2$ началась строго после транзакции $T_1$, он применяет гениальный паттерн Commit Wait: узел $T_1$ просто принудительно засыпает на время максимальной погрешности интервала ($7\text{ мс}$) перед фиксацией транзакции. Когда интервалы перестают физически пересекаться, истинный порядок во вселенной гарантирован.

Однако инфраструктура TrueTime стоит миллионы долларов и доступна только гигантам масштаба Google. Во всех остальных системах мы обязаны писать код исходя из аксиомы: физические часы врут.

Итог

  1. Время относительно: На каждом сервере физические часы тикают со своей скоростью из-за температуры и износа кварцевых кристаллов.
  2. NTP несовершенен: Из-за асимметрии сетевых задержек сервера имеют неустранимое расхождение в миллисекунды и способны совершать скачки назад.
  3. Победа Go-рантайма: Структура time.Time автоматически совмещает Wall Clock и Monotonic Clock, делая замеры через time.Since() абсолютно защищенными от скачков времени ОС.
  4. Опасность LWW: Использование физических timestamp для разрешения конфликтов в базах данных приводит к молчаливому затиранию актуальных данных.
  5. Логическое время: В распределенных системах причинность устанавливается логическими часами Лампорта и векторными часами, а не системными часами серверов.

Мы изучили физические ограничения сетей, частичные отказы и релятивность времени. Всё готово к тому, чтобы свести эти законы воедино и познакомиться с главным законом распределенных систем, определяющим выбор между целостностью данных и доступностью сервиса: 6. Consistency vs availability.