Решение для кэширования уникальных идентификаторов

Мы хотим создать распределенный кэш уникальных идентификаторов, которые будут использоваться в приложении для идентификации каждой транзакции. UNIQUE ID генерируется с использованием некоторой пользовательской логики (скажем, DATE + некоторое случайное число) в коде Java.

Приложение работает на 8 серверах приложений (с балансировкой нагрузки). Как только уникальный идентификатор используется приложением, кеш необходимо обновить ранее использованным значением. Поэтому обновление объекта кеша должно выполняться в многопоточной среде.

Лучше ли хранить локальный кеш на каждом сервере приложений (уникальная последовательность генерации идентификатора, специфичная для каждого узла). Но это не гарантирует последовательность идентификаторов транзакций в приложении.

Мы искали варианты hazlecast, geode, ignite и т. д. для создания распределенного кеша (однорангового кеша). Но какой из них будет хорошо работать при обновлении кеша в многопоточной среде.

Какое решение/модель кэширования лучше всего подходит для этой проблемы.


person InquistiveNerd    schedule 26.03.2020    source источник
comment
У вас либо авторитетный центральный кеш, либо вы живете с окончательной согласованностью в распределенном. Другого выбора действительно нет. Ваш кеш предназначен только для предотвращения столкновений? В этом случае просто используйте UUID и покончите с этим.   -  person Chuck Adams    schedule 26.03.2020
comment
en.wikipedia.org/wiki/Universally_unique_identifier   -  person Basil Bourque    schedule 26.03.2020
comment
Чак Адамс - Да, чтобы предотвратить коллизии, а также сохранить последовательность идентификаторов транзакций.   -  person InquistiveNerd    schedule 27.03.2020


Ответы (1)


Нет необходимости в кеше

Вам не нужно кэширующее решение для вашей проблемы.

Вы можете генерировать универсальные уникальные идентификаторы без какой-либо координации между вашими системами.

UUID

Надлежащее решение уже изобретено, стандартизировано, реализовано и получило широкое распространение: UUID.

UUID версии 1 представляет собой точку в пространстве и времени, включая текущий момент вместе с MAC-адресом машины и добавляет произвольное число, которое увеличивается при сбросе часов хоста и увеличивается при перезапуске генератора UUID.

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

Пример:

1154cf8a-6f7b-11ea-bc55-0242ac130003

Вы просили:

пользовательская логика (скажем, ДАТА + какое-то случайное число)

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

UUID широко используются в ИТ-индустрии. Вы найдете их в заголовках своих электронных писем, чтобы идентифицировать каждое сообщение. Вы найдете их как идентификаторы транзакций. Вы найдете их как идентификаторы объектов.

Реализации генератора UUID встроены почти во все операционные системы (macOS, Linux, BSD, Windows и т. д.). Общедоступны библиотеки, такие как OSSP uuid. Более мощные базы данных, такие как Postgres, поддерживают UUID в качестве собственного типа данных для эффективного хранения и простоты использования. Некоторые программные платформы, такие как Java, включают тип данных для UUID и реализацию генератора.

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

person Basil Bourque    schedule 26.03.2020
comment
Спасибо за ваш ответ. Но наше требование состоит в том, чтобы генерировать уникальные идентификаторы на основе нашей пользовательской логики в нашем стандартном формате. Поэтому мы не можем использовать UUID. Можете ли вы предложить наилучший подход в этом сценарии? - person InquistiveNerd; 27.03.2020