Кратко

  • UUIDv7 помещает число миллисекунд Unix-эпохи в первые 48 бит, а оставшиеся 74 пригодных бита обычно отводит под случайность либо, по выбору реализации, под дробную часть времени и счётчик. Это форма для сортировки ключей, а не протокол доказывания событий.
  • RFC 9562 разрешает изменять фактический timestamp и не гарантирует его близости к реальному времени. Откат часов, порядок пакетной генерации, счётчик и переполнение остаются задачами приложения.
  • Проверяемый вывод требует связать UUID с данными о генераторе, устойчивом переходе состояния, субъекте и полномочии, внешнем временном свидетельстве при необходимости и результате у принимающей системы.

Удобная последовательность не равна установленной последовательности

RFC 9562 решает узкую задачу: выдать 128-битный идентификатор без обращения каждого узла к центральному регистратору. В UUIDv7 первые 48 бит содержат big-endian значение миллисекунд от Unix-эпохи. После обязательных битов версии и варианта поля rand_a и rand_b обычно несут случайные данные. Если внутри одной миллисекунды нужна дополнительная монотонность, реализация может последовательно разместить там долю миллисекунды, аккуратно инициализированный счётчик и оставшуюся случайность.

Эта компоновка полезна для хранилища. UUIDv7 можно сравнивать как непрозрачные байты; новые ключи чаще попадают рядом в B-tree или сходный индекс, а не распределяются случайно по множеству страниц. RFC прямо называет байтовую и лексическую сортировку, а также локальность базы данных преимуществами UUIDv6 и UUIDv7.

Однако индекс не знает, была ли операция допущена. Идентификатор можно создать до проверки права. Затем транзакция может завершиться rollback. Сообщение с тем же идентификатором может быть опубликовано из outbox позже. Получатель может увидеть повтор и применить только одну доставку. UUID полезно связывает эти записи, но не сообщает, какой переход стал долговечным, кто его санкционировал и какой внешний эффект наступил.

Миллисекунда в ключе не отвечает за истинное время

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

Более того, RFC 9562 разрешает реализации изменять фактический timestamp. В качестве примеров названы исправление неточных часов, обработка високосных секунд и преобразования ради производительности. Для близости помещённого значения к реальному времени не устанавливается ни требование, ни гарантия. Следовательно, временной префикс говорит о политике конкретного генератора, а не независимо удостоверяет время факта.

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

Общий формат не создаёт общего знания

Преимущество UUID — отсутствие обязательного мирового координатора. Но RFC 9562 одновременно говорит, что настоящую глобальную уникальность нельзя гарантировать без схемы общего знания. Для многих случаев достаточно локальной уникальности; UUID не требует глобального реестра или общего секвенсора.

Разные узлы способны выпускать совместимые ключи, имея разные источники времени, состояния счётчика и пути восстановления после сбоя. Из того, что один текстовый UUID меньше другого, не следует, что одна система раньше увидела другую, что первая транзакция раньше получила commit или что первое сообщение вызвало второе изменение. UUIDv7 не является позицией в consensus log и не несёт доказательство причинности между хостами.

Совет RFC обращаться с UUID как с непрозрачным значением, если разбор не нужен, сохраняет эту границу. Разобрать временной участок бывает полезно для диагностики. Но превратить его в вывод аудита — отдельное действие, которому нужны собственные доказательства и ответственный владелец.

Какие записи нужны рядом с UUID

UUIDv7 может быть общей ссылкой дела, но не единственным материалом дела.

  1. Запись генерации: версия генератора, сервис или хост, источник времени, точность, политика счётчика, перезапуск и обработка ошибок.
  2. Запись перехода: проверка, устойчивый commit или rollback, публикация outbox, повторная доставка, идемпотентность и сверка.
  3. Запись полномочия: человек или сервисный principal, делегирование, утверждение, применённое правило и предел разрешения.
  4. Независимая временная запись: если требуется показать третьей стороне, что данные существовали до значимого времени, RFC 3161 задаёт иной механизм. Служба меток времени подписывает токен по хэшу данных в рамках идентифицированной политики; запросчик проверяет хэш, подпись, сертификат, nonce или своевременность и приемлемость политики. Это ограниченное свидетельство существования данных до времени по данной политике, а не доказательство автора, полномочия или последующего успеха.
  5. Запись эффекта: существенный получатель фиксирует, выполнил ли он расчёт, применил конфигурацию, выдал доступ, отказал, компенсировал или оставил операцию незавершённой.

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

Источники