Несколько месяцев назад я реализовал решение для выбора уникальных значений в диапазоне от 1 до 65535 (16 бит).Этот диапазон используется для создания уникальных суффиксов Route Targets, которые для этой большой сети клиента (это огромный провайдер) являются очень спорным ресурсом, поэтому любое выпущенное значение должно быть немедленно доступно конечному пользователю.
Для выполнения этого требования я использовал BitSet .Выделите суффикс для индекса RT с помощью set и освободите суффикс с помощью clear.Метод nextClearBit () может найти следующее доступное значение.Я занимаюсь вопросами синхронизации / параллелизма вручную.
Это работает очень хорошо для небольшого диапазона ... Весь индекс небольшой (около 10 КБ), он быстро работает и может быть легко сериализован и сохранен в поле большого двоичного объекта.
Проблема в том, что некоторые новые устройства могут обрабатывать суффиксы RT из 32-битных без знака (диапазон 1/4294967296).Которым нельзя управлять с помощью BitSet (он сам по себе будет занимать около 600 МБ, плюс будет ограничен диапазоном int - 32 бита со знаком).Даже при наличии такого огромного диапазона клиент все еще хочет освободить суффиксы Route Target, которые становятся доступными для конечного пользователя, главным образом потому, что самые низкие (до 65535), которые совместимы со старыми маршрутизаторами, являются предметом споров.
Прежде чем я скажу клиенту, что это невозможно, и он должен будет соответствовать моему повторно используемому индексу для более низких RT (до 65550) и использовать последовательность базы данных для других (что означает, что, когда пользователь освобождаетцель маршрута, она снова не станет доступной), кто-нибудь пролил бы немного света?
Может быть, какая-то добрая душа уже внедрила высокопроизводительный пул номеров для Java (6, если это имеет значение), или я скучаю по убийцеособенность базы данных Oracle (11R2, если это имеет значение) ... Просто немного желаемое за действительное :).
Большое спасибо заранее.