Короче (если получится):
В настоящее время, для обеспечения уникальности неких “элементов”, хранимых в базе данных, используется uuid V4.
И всё бы ничего, но, предполагается генерация этих uuid на разных инстансах. Что, не теоретически, а практически, точно приведёт к коллизиям (генерации разными инстансами одинаковых значений). Чтобы эти инстансы не зависили от некоего единственного провайдера uuid’ов, который в состоянии проверять, выдавал ли он ранее такой uuid или нет, появилась идея использовать “пространства имён” на основе даты и времени создания нового “элемента”.
Вообще, понятно, что в самой таблице, хранящей данные “элементов”, присутствует автоинкрементное поле “id”, которое эту уникальность, конечно же, обеспечивает. Но вот беда, некоторые приложения, пользующиеся этими данными, не используют автоинкрементные айдишники, а используют выше обозначеный uuid V4. Засим, дабы не патчить эти приложения, вместо uuid V4 им можно подсунуть строковый уникальный идентификатор, о котором ниже:
Я хочу генерировать уникальные ключи вида (без квадратных скобок, они тут только для того, чтобы вам было понятно из чего состоит ключ):
[year][month][day][hour][min][sec][usec][usec][usec]
Где:
year – год, всегда 4 цифры
month – месяц в году, всегда 2 цифры
day – день, всегда 2 цифры
hour – текущий час, всегда 2 цифры
min – текущие минуты, всегда 2 цифры
sec – текущие секунды, всегда 2 цифры
usec – текущие микросекунды, всегда 6 цифр, три раза по 6
Теперь подробнее про микросекунды:
Тики процессора, в принципе, по частоте их следования, сопоставимы с его тактовой частотой и значениями микросекунд. Кроме того, процессор, как правило, выполняет несколько задач, циклически обходя каждую из них, и, возвращаясь к задаче генерации ключа, эта задача, трижды запрашивающая текущее значение микросекунд, будет получать немного отличающиеся значения (уже проверено). Ну а три раза подряд – это и есть защита от коллизий в пределах одной секунды, ещё и на разных инстансах.
Так вот вопрос:
Насколько по вашему подход, выбранный мной, будет надёжным? Конечно же, учитывая генерацию на разных инстансах.
Это я писюк с fpga перепутал.
А ты не делай больших периодов, скажем если у тебя период 50 микросекунд и на 40 микросекунде переполнился однобайтный счётчик то что, у тебя всё развалится от задержки в 10 микросекунд ожидания нового периода?
И ты точно уверен что за эти 50 микросекунд раздашь 255 штук id?
И даже если тебе не подходят эти значения, то что тебе меешает увеличить размер счётчика или уменьшить размер периода?
На худой конец можно сделать так, счётчик запоминает время и дальше выдаёт номера к запомненному времени пока не переполнится, а там запоминает новое время и так по кругу.
Ну может стоит поставить таймер инициализирующий этот счётчик раз за какой либо период, чтоб одна серия номеров слишком долго не тянулась.
Как мне синхронизировать “запоминания” счётчиков разных инстансов?
Инстансы не мои и доступа туда я не имею, ну, кроме как “подсунуть вместо uuid своё строковое значение”.
А база, да – моя.
Думаю что самое надёжное вписывать id каждого инстанса, который каждому инстансу задавать в конфиге, всё равно ведь их у тебя много не будет.
На худой конец если инстансы в разных городах то используй в качестве id географические координаты города, дома или помещения в котором находится инстанс, яндекс или гуглокарты позволяют их определять с шагом около 10 метров.
Ну или сделай медленный сервис у которого инстанс по параметрам материнки, видеокарты, MAC и IP или подсетке, в общем по фингерпринту будет выдавать определённый постоянный id, мониторя факт работы этого инстанса посылая ему раз в секунду пакет и пока инстанс отвечает не отдавая этот ацди даже тем инстансам, кто может его получить.
Таки их много будет, иначе бы я и не заморачивался так. Срать своими uuid’ами они будут очень часто.
До фингерпринтов доступа нет. Есть только дрищщ от инстансов в виде их личных uuid’ов. Посылов к инстансу возможности нет – это они делают push, и никогда pull, и уж тем более с моей стороны никто не ожидает обращений, чтобы что-то там “синхронизировать”. Я могу лишь ответить: “вот этот uuid – говно, держи правильный, там сам запомнишь”.
Код который на инстансе получает id не имеет доступа к /proc и /sys?
Да пусть даже так, тогда для вычисления фингерпринта можно сделать отдельный сервис который этот фингерпринт будет записывать в файл в /etc/fingerprint/fingerprint.txt
Да собственно тогда на этот вычислитель фингерпринта можно повесить и получение id с сервера и писать в файл сразу id.
Ессна! Это обычная гуевая прилага с кучей проблем и зависимостей.
Тогда что тебе мешает использовать в качестве id географические координаты инстанса?
Ну понятно что их кто-то будет вписывать но положим расстряние между инстансами не менее чем 1 км, тогда даже не очень умному человеку будет сложно напутать.
И легко и часто будут ситуации когда один старый скибнул, а совершенно новый прибыл. А старый ещё и вернуться когда-нибудь может – хоть через 5 минут, хоть через год.
Может тогда лучше таки сделать сервис?
Ну или в качестве id инстанса использовать время/дату запуска инстанса в микросекундах, навряд ли они совпадут с такой точностью, чтобы были одинаковыми у двух инстансов сразу.
Представь себе кучу гандозавров, положим, 40 тысяч, и каждый чего-то там синкует. У каждого из них свой генератор uuid, но эти uuid’ы, на стороне гандозавров на формат не проверяются, и могут быть заменены на мой личный уникалый uid того вида, как я описывал в стартпосте. Таким образом, я могу раздавать им глобально уникальные uid’ы, чтобы глобально же их различать у себя. Так, в итоге, сервис по выдаче uuid’ов и сервис по анализу их же, я хочу объединить в одном инстансе, к которому эти гандозавры и будут обращаться.
Вообще я называл гондозавра инстансом, ну видимо не правильно понял что есть что.
Но по сути разве инстанс как ты его сейчас описал не будет единым провайдером id?
Нет, не будет. Давай называть гандозаврами тех, кто обращается к АПИ, который контролирует уникальность uid’ов.
А инстанс это то, что это АПИ предоставляет?
И как я понимаю выполняется это всё, и гондозавры, и инстанс, паралельно (потоком или процессом не важно)на материнке с 4 ЦПУ по 32 ядра каждый?
А инстанс это то, что это АПИ предоставляет?
И как я понимаю выполняется это всё, и гондозавры, и инстансы, паралельно (потоком или процессом не важно)на нескольких компах с материнками с 4 ЦПУ по 32 ядра каждый?
Короче ты сам запутался и меня уже запутал. Гандозавры и инстансы это одно и то же. АПИ одно.
Я понимаю, ты щас скажешь, что, если ты можешь менять uuid’ы, то меняй именно uuid’ы, но, дело в том, что uuid’ы разных гандозавров могут быть одинаковы. Да, так и есть, да и хер с ними – это дело уникальности конкретного инстанса (гандозавра), но кроме uuid’а гандозавр присылает и путь до файла, к которому этот uuid и привязан, вот именно этот путь до файла, я считаю, должен быть уникален, не только для конкретного гандозавра, но и для всех остальных гандозавров, а также для АПИ с моей БД.
Суть проста: любой гандозавр должен сгенерировать максимально уникальный uid (или я его исправлю и отправлю гандозавру на апдейт). Конечно, я его проверю на уникальность, но коллизия должна быть исключением настолько редким, что песец.