WorkerId должен быть обеспечен внешней системой, чтобы гарантировать его глобальную уникальность. Значение этого параметра необходимо передать в алгоритм как входной параметр.

3️⃣ При использовании нескольких экземпляров на одном компьютере каждому из них следует присвоить уникальный WorkerId. Если на одной машине развёрнуто несколько приложений, рекомендуется обеспечить уникальность каждого WorkerId для предотвращения возможных конфликтов.

4️⃣ Алгоритм будет генерировать исключения (Exception), и внешняя система должна их перехватывать и обрабатывать, чтобы предотвратить более серьёзные сбои системы.

5️⃣ Важно понимать определение IdGeneratorOptions, так как это может помочь при интеграции и использовании алгоритма.

6️⃣ Рекомендуется использовать алгоритм «снежинка» (метод = 1). Хотя код содержит определение традиционного алгоритма «снежинки», можно также использовать традиционный алгоритм, указав метод = 2. Алгоритм «снежинка» обладает лучшей масштабируемостью и производительностью.

7️⃣ Не следует изменять основной алгоритм. Он содержит множество внутренних параметров и сложную логику, поэтому перед внесением изменений рекомендуется тщательно изучить его работу. Изменения не должны применяться в производственной среде без тщательного научного тестирования.

8️⃣ Стратегии конфигурации должны быть одинаковыми во всех приложениях в пределах одной системы. После того как система проработает некоторое время, необходимо перейти от ручного назначения WorkerId к автоматическому. Убедитесь, что все экземпляры в рамках одного приложения используют согласованную стратегию конфигурации, включая WorkerId и другие параметры.

9️⃣ Необходимо следить за временем на сервере. Алгоритму «снежинка» требуется системное время, и не рекомендуется вручную изменять его. Если это всё же необходимо, убедитесь, что время после перезапуска сервера больше, чем время до последнего выключения. (Примечание: небольшие изменения системного времени, вызванные синхронизацией или коррекцией на уровне сети, не влияют на алгоритм.)

Изменение конфигурации

Изменение конфигурации означает изменение параметров работы системы (свойств объекта IdGeneratorOptions) после определённого периода работы. Обратите внимание на следующие правила:

🔴 1. Основное правило: BaseTime может только увеличиваться, чтобы сгенерированные ID были больше максимального исторического значения. Это гарантирует отсутствие перекрытия временных интервалов и предотвращает создание повторяющихся ID. (Не рекомендуется изменять BaseTime после запуска системы.)

🔴 2. Можно увеличивать значения WorkerIdBitLength или SeqBitLength в любое время. Однако следует осторожно относиться к уменьшению этих значений, поскольку это может привести к совпадению будущих ID с ранее использованными значениями. (Разрешено увеличивать любые значения xxxBitLength после запуска системы.)

🔴 3. Если необходимо уменьшить значение WorkerIdBitLength или SeqBitLength, важно соблюдать условие: сумма новых значений xxxBitLength должна быть больше суммы старых значений. (Не рекомендуется уменьшать значения BitLength после запуска системы.)

🔴 4. Эти правила не реализованы в самом алгоритме. Перед изменением конфигурации необходимо убедиться, что новые настройки соответствуют требованиям.

Автоматическая регистрация WorkerId

🔍 Уникальный идентификатор (ID) зависит от WorkerId, и когда бизнес-сервисы требуют горизонтального масштабирования (автоматического расширения), требуется автоматическая регистрация уникального WorkerId для генерации уникальных ID.

🔍 Этот алгоритм предоставляет открытую динамическую библиотеку (реализованную на языке Go), которая позволяет автоматически регистрировать WorkerId в контейнерных средах, таких как Kubernetes, через Redis.

🔍 Регистрация WorkerId через Redis — это лишь один из способов. Вы также можете разработать централизованную систему конфигурации, где каждый узел службы получает уникальный WorkerId при запуске через централизованный сервис.

🔍 Если ваши сервисы не требуют автоматического масштабирования, нет необходимости автоматически регистрировать WorkerId. Вместо этого можно установить уникальные значения для каждого сервиса.

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

Процесс автоматической регистрации

Изображение доступно по ссылке: https://github.com/yitter/IdGenerator/blob/master/Tools/AutoRegisterWorkerId/regprocess.jpg

Путь к исходному коду: /Go/source/regworkerid/reghelper.go

Загрузка динамической библиотеки

Скачать можно по ссылке: https://github.com/yitter/IdGenerator/releases/download/v1.3.3/workeridgo_lib_v1.3.3.zip

Интерфейс динамической библиотеки

// Регистрация одного WorkerId. Сначала отменяет регистрацию всех зарегистрированных записей на локальном компьютере
// address: адрес соединения Redis, пример для одномашинного режима: 127.0.0.1:6379, пример для режима Sentinel/кластера: 127.0.0.1:26380,127.0.0.1:26381,127.0.0.1:26382
// password: пароль подключения Redis
// db: номер базы данных Redis, пример: 1
// sentinelMasterName: имя службы в режиме Sentinel, пример: mymaster, в режиме без Sentinel передаётся пустая строка
// minWorkerId: минимальное значение WorkerId, пример: 30
// maxWorkerId: максимальное значение WorkerId, пример: 63
// lifeTimeSeconds: срок действия WorkerId (в секундах, кратный 3), рекомендуется значение 15
extern GoInt32 RegisterOne(char* server, char* password, GoInt32 db, char* sentinelMasterName, GoInt32 minWorkerId, GoInt32 maxWorkerId, GoInt32 lifeTimeSeconds);

// Отмена регистрации уже зарегистрированного WorkerId на локальном компьютере
extern void UnRegister();

Реализовано на следующих языках

Техническая поддержка

Открытый исходный код: https://github.com/yitter/IdGenerator

QQ группа: 646049993 [51]: https://github.com/yitter/idgenerator/tree/master/C [61]: https://github.com/yitter/idgenerator/tree/master/Delphi [71]: https://github.com/yitter/idgenerator/tree/master/PHP