Что такое Snowflake ID
Snowflake ID — это 63-битное целое число, используемое для генерации уникальных идентификаторов в распределённой системе без единой точки координации. Twitter разработал этот формат в 2010 году, чтобы заменить автоинкрементные последовательности баз данных, которые не могли масштабироваться на десятки серверов приложений, записывающих данные в шардированные кластеры MySQL. Каждый Snowflake ID представляет собой знаковое 64-битное целое число, в котором старший бит всегда равен нулю, оставляя 63 значащих бита, разделённых на четыре поля: 41-битное смещение метки времени, 5-битный идентификатор дата-центра, 5-битный идентификатор машины и 12-битный номер последовательности. Такая структура позволяет одному узлу службы Snowflake генерировать до 4 096 уникальных идентификаторов за миллисекунду, обеспечивая системе теоретическую пропускную способность в миллионы идентификаторов в секунду при развёртывании сотен рабочих процессов.
Snowflake ID монотонно возрастают — каждый новый идентификатор больше предыдущего в пределах одной эпохи — но они не являются строго последовательными между узлами. Две машины, работающие в одну и ту же миллисекунду, будут выдавать идентификаторы, которые чередуются, что является осознанным компромиссом: схема жертвует идеальной упорядоченностью ради абсолютной операционной независимости. Каждому рабочему процессу достаточно знать только свой номер дата-центра и машины, а также текущее время, чтобы создать глобально уникальный идентификатор, ни разу не обращаясь к другому узлу или сервису блокировок.
Анатомия 63-битного идентификатора
Snowflake ID — это 63-битное целое число, состоящее из следующих полей, от старшего к младшему:
- 41-битная метка времени — миллисекунды, прошедшие с пользовательской эпохи.
- 5-битный идентификатор дата-центра — определяет физический дата-центр, в котором работает узел.
- 5-битный идентификатор машины — определяет конкретный хост или процесс внутри этого дата-центра.
- 12-битный номер последовательности — счётчик на миллисекунду, который сбрасывается в ноль при переходе на следующую миллисекунду.
Точная формулировка, описывающая эту структуру: 41-битная метка времени, 5-битный дата-центр, 5-битная машина и 12-битная последовательность. Вместе эти поля занимают 63 бита, при этом ведущий знаковый бит установлен в ноль, чтобы идентификатор удобно помещался в знаковое 64-битное целое число в таких языках, как Java и C#.
Эпоха Twitter и компонент метки времени
Каждый Snowflake ID несёт смещение метки времени, отсчитываемое от пользовательской эпохи: 1288834974657 миллисекунд. Это значение приблизительно соответствует 2010-11-04T04:42:54.657Z и было выбрано для совпадения с началом внутреннего развёртывания Snowflake в Twitter. Использование пользовательской эпохи вместо Unix-эпохи означает, что 41-битное поле метки времени может охватывать диапазон примерно в 69 лет до переполнения. Максимальное значение метки времени, которое может хранить поле, составляет 2^41 минус 1, или 2 199 023 255 551 миллисекунда — около 69,7 лет после эпохи, что отодвигает дату переполнения в 2080-е годы.
Чтобы закодировать метку времени, вычтите эпоху из текущих миллисекунд Unix-эпохи, затем сдвиньте результат влево на 22 бита, чтобы освободить место для трёх младших полей. Любая входная метка времени, предшествующая эпохе, недействительна и должна быть отклонена.
Идентификация дата-центра и машины
5-битное поле дата-центра и 5-битное поле машины принимают значения от 0 до 31, что даёт в общей сложности 1 024 уникальных идентификатора узлов в рамках развёртывания. Рабочему процессу присваивается идентификатор дата-центра и идентификатор машины при запуске, обычно через конфигурационный файл, координационный сервис вроде ZooKeeper или аргумент командной строки. Назначение должно быть уникальным в пределах всей системы: два рабочих процесса, использующих одну и ту же пару (дата-центр, машина), будут создавать конфликтующие идентификаторы, если только их часы не рассинхронизированы.
Эти поля вставляются в идентификатор путём сдвига значения дата-центра влево на 17 бит и значения машины влево на 12 бит, с последующим применением побитового ИЛИ к сдвинутым значениям и 63-битному целому числу. Общего количества в 1 024 узла достаточно для большинства реальных развёртываний, но среды, которым требуется более 1 024 рабочих процессов, могут заимствовать биты из поля последовательности или поля метки времени ценой пропускной способности или диапазона эпохи.
Счётчик последовательности и границы тактов
12-битное поле последовательности — это рабочая лошадка дизайна Snowflake. Оно принимает значения от 0 до 4 095 и увеличивается на единицу для каждого идентификатора, сгенерированного в течение одной и той же миллисекунды. Когда последовательность достигает 4 095, рабочий процесс входит в цикл активного ожидания, пока системные часы не перейдут к следующей миллисекунде, после чего последовательность сбрасывается в ноль и генерация возобновляется. Это даёт одному узлу максимальную пиковую скорость в 4 096 идентификаторов за миллисекунду.
Дрейф часов и откат часов — два наиболее существенных режима отказа алгоритма Snowflake. Если системные часы идут назад — будь то из-за корректировки NTP, миграции виртуальной машины или ручного изменения — рабочий процесс может сгенерировать идентификатор с меткой времени, меньшей, чем у последнего созданного им идентификатора, нарушая гарантию уникальности. Стандартным смягчающим решением является остановка генерации идентификаторов и вызов ошибки при обнаружении отката часов, отказ в обслуживании запросов до тех пор, пока часы не догонят последнюю зафиксированную метку времени. Развёртывание, которое не может допустить простоя, должно рассмотреть использование выделенного сервиса времени или слоя логических часов.
Разобранный пример
Рассмотрим следующие входные значения: метка времени Unix-эпохи 1700000000000 миллисекунд, идентификатор дата-центра 7, идентификатор машины 13 и номер последовательности 4095.
Кодирование. Сначала вычислим смещение метки времени: 1700000000000 минус эпоха Snowflake 1288834974657 равно 411165025343. Сдвинем это смещение влево на 22 бита, получив 1724551110456246272. Сдвинем значение дата-центра 7 влево на 17 бит, получив 917504. Сдвинем значение машины 13 влево на 12 бит, получив 53248. Номер последовательности не требует сдвига. Объединим четыре слагаемых побитовым ИЛИ, чтобы получить итоговый Snowflake ID: 1724551110457221119.
Декодирование. Чтобы восстановить исходные поля из идентификатора 1724551110457221119, наложим маску на младшие 12 бит для извлечения последовательности: 4095. Сдвинем вправо на 12 бит и наложим маску на младшие 5 бит, чтобы восстановить идентификатор машины: 13. Сдвинем вправо на 17 бит и наложим маску на младшие 5 бит, чтобы восстановить идентификатор дата-центра: 7. Сдвинем вправо на 22 бита, чтобы получить смещение метки времени: 411165025343. Прибавим эпоху 1288834974657, чтобы восстановить исходную метку времени Unix-эпохи: 1700000000000.
Полный цикл кодирования-декодирования точен, потому что каждое поле умещается в отведённую ему битовую ширину, и никакая информация не теряется при кодировании.
Точность и ограничения
Схема кодирования Snowflake детерминирована и обратима при условии, что все входные данные находятся в допустимых диапазонах. Смещение метки времени должно быть неотрицательным 41-битным целым числом; идентификаторы дата-центра и машины должны находиться в диапазоне от 0 до 31; а последовательность — в диапазоне от 0 до 4 095. Любое входное значение за пределами этих границ отклоняется как недействительное.
Схема не учитывает високосные секунды или субмиллисекундную точность. Она полагается на системные часы хоста, которые могут дрейфовать или корректироваться внешними процессами. В развёртываниях, где системные часы переводятся вперёд большим скачком NTP, поле смещения изменится корректно, но счётчик последовательности будет простаивать в течение этого промежутка, оставляя период невыданных идентификаторов. Это безвредно для уникальности, но создаёт разрыв во временной линии идентификаторов.
Сетевые изолированные рабочие процессы, использующие один и тот же кортеж (дата-центр, машина), будут создавать конфликтующие идентификаторы, если они когда-либо окажутся активными одновременно. Пространство идентификаторов предоставляет 1 024 уникальных слота узлов, и превышение этого количества требует использования пользовательского варианта битовой структуры.
Источники
- Репозиторий Twitter Snowflake: https://github.com/twitter-archive/snowflake/tree/snowflake-2010
- Оригинальная публикация-анонс: https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake
Редакционная справка
Эта статья описывает формат Snowflake ID в том виде, в каком он определён в эталонной реализации Twitter 2010 года. Битовая структура и значение эпохи взяты непосредственно из открытого исходного кода на Scala. Разобранный пример был проверен ручным вычислением, которое кодирует и декодирует одни и те же значения для подтверждения полного цикла. Обсуждение отката часов и ограничений узлов отражает операционный опыт, задокументированный в инженерной литературе по распределённой генерации идентификаторов.
Статья не охватывает сторонние реализации или варианты, изменяющие битовую структуру — например, такие, которые используют 10-битный идентификатор машины, другую эпоху или поле идентификатора рабочего процесса, получаемое из координационного сервиса. Эти варианты выходят за рамки оригинальной спецификации Snowflake. Автор: Редакционная команда SoupCalc Последний пересмотр: 11 августа 2026 г.