Для распределенного приложения нужен сервис, который бы возвращал монотонно возрастающие целочисленные значения. Желательно без значительных и регулярных пробелов между значениями.
Изначально был разработан локальный сервис на основе разделяемой памяти и mutex и sparsed int set.
Добавилось несколько требований — распределенные клиенты и high availability.
Рассматриваются варианты использования Redis, ZooKeeper и базы данных с пред-выделением блоков.
Что можно еще рассмотреть, чтобы велосипед не изобретать?
Основное требование — производительность. Ну и надежность, конечно.

Здравствуйте, ole!, Вы писали:

O>Рассматриваются варианты использования Redis, ZooKeeper и базы данных с пред-выделением блоков.

Redis то что доктор прописал

Здравствуйте, ole!, Вы писали:

O>Для распределенного приложения нужен сервис, который бы возвращал монотонно возрастающие целочисленные значения. Желательно без значительных и регулярных пробелов между значениями.
O>Изначально был разработан локальный сервис на основе разделяемой памяти и mutex и sparsed int set.
O>Добавилось несколько требований — распределенные клиенты и high availability.
O>Рассматриваются варианты использования Redis, ZooKeeper и базы данных с пред-выделением блоков.
O>Что можно еще рассмотреть, чтобы велосипед не изобретать?
O>Основное требование — производительность. Ну и надежность, конечно.

А почему бы не написать простенький сервис, который бы атомарно инкрементировал счетчик и возвращал?

Здравствуйте, ole!, Вы писали:

O>Для распределенного приложения нужен сервис, который бы возвращал монотонно возрастающие целочисленные значения.
А может текущее время с NTP/PTP подойдёт? Ну можно ещё для уникальности nodeId добавить. Или уникальность не нужна?

O>Желательно без значительных и регулярных пробелов между значениями.
Для распределённой системы в случаях обырва связи непонятно как такого добиться.

Здравствуйте, Sharov, Вы писали:

S>А почему бы не написать простенький сервис, который бы атомарно инкрементировал счетчик и возвращал?
И куда его именно поставить в случае распределённой системы, в которой бывают проблемы со связью?

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Sharov, Вы писали:

S>>А почему бы не написать простенький сервис, который бы атомарно инкрементировал счетчик и возвращал?
·>И куда его именно поставить в случае распределённой системы, в которой бывают проблемы со связью?

В центр. А если серьезно, то завести таких несколько и выделить им непересекающийся диапазон значений.

Здравствуйте, Sharov, Вы писали:

S>В центр. А если серьезно, то завести таких несколько и выделить им непересекающийся диапазон значений.
ТЗ не читай@проблему решай

Желательно без значительных и регулярных пробелов между значениями.

увы.

Здравствуйте, Sharov, Вы писали:

S>>>А почему бы не написать простенький сервис, который бы атомарно инкрементировал счетчик и возвращал?
S>·>И куда его именно поставить в случае распределённой системы, в которой бывают проблемы со связью?
S>В центр. А если серьезно, то завести таких несколько и выделить им непересекающийся диапазон значений.
Чем дальше в лес, тем... Это будут уникальные номера, но вовсе не обязательно монотонно возрастающие. Подумай над таким сценарием: есть два "центра", одном центре номера иногда используются в N раз чаще, чем в первом. Как обеспечить возрастание между центрами?

Ещё идея: выдавать временные номера (или просто уникальные id), и посылать заявки выдать номер в "центр". Как центр ответит, присвоить постоянный номер. Но это бизнес-процесс должен позволять иметь временно непронумерованную сущность.

Короче. Товарищ ole!, пожалуйста опиши саму задачу, а не способы которыми ты её пытался решить. В такой постановке задача противоречит физическим законам.

Здравствуйте, ·, Вы писали:

·>Чем дальше в лес, тем... Это будут уникальные номера, но вовсе не обязательно монотонно возрастающие. Подумай над таким сценарием: есть два "центра", одном центре номера иногда используются в N раз чаще, чем в первом. Как обеспечить возрастание между центрами?

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

·>Ещё идея: выдавать временные номера (или просто уникальные id), и посылать заявки выдать номер в "центр". Как центр ответит, присвоить постоянный номер. Но это бизнес-процесс должен позволять иметь временно непронумерованную сущность.

Чем это отличается по сути отличается от сервиса, который атомарно инкрементирует?

Здравствуйте, Sharov, Вы писали:

S>·>Ещё идея: выдавать временные номера (или просто уникальные id), и посылать заявки выдать номер в "центр". Как центр ответит, присвоить постоянный номер. Но это бизнес-процесс должен позволять иметь временно непронумерованную сущность.

S>Чем это отличается по сути отличается от сервиса, который атомарно инкрементирует?
Тем что он это делает асинхронно. Он указал, что нужна
— производительность: временный id можно выдать локально и мгновенно, uuid generator например
— распределённость: "центр" вовсе не обязательно должен быть единственным, например можно сделать консенсус в кластере что 851ba2e6-5c4f-4ebd-aa06-7dd599e7dcd6 имеет номер 42, а 3edd2913-e421-4398-ac8d-7dd13fd809fc будет 43 и т.п. Тогда вообще получится идеальная последовательность с единичным инкрементом.

Здравствуйте, ole!, Вы писали:

O>Что можно еще рассмотреть, чтобы велосипед не изобретать?

Вариант от твиттера пойдёт?

Остальные извращения — тынц

Здравствуйте, ole!, Вы писали:

O>Для распределенного приложения нужен сервис, который бы возвращал монотонно возрастающие целочисленные значения.
Монотонность в распределённой среде — это как?
Обычно, под монотонностью мы понимаем что V[t1] > V[t2] для любого t2>t1.
Это подразумевает наличие глобального времени — т.е. все операции "взять значение" гарантированно упорядочены.
В распределённой системе глобального времени, в общем случае, нету. Под глобальным временем я имею в виду такое, что на множестве всех таймстампов есть отношение полного порядка.
На практике такое требование убъёт надёжность системы: нужно синхронизоваться на каждом такте.