Короче (если получится):
В настоящее время, для обеспечения уникальности неких “элементов”, хранимых в базе данных, используется 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
Теперь подробнее про микросекунды:
Тики процессора, в принципе, по частоте их следования, сопоставимы с его тактовой частотой и значениями микросекунд. Кроме того, процессор, как правило, выполняет несколько задач, циклически обходя каждую из них, и, возвращаясь к задаче генерации ключа, эта задача, трижды запрашивающая текущее значение микросекунд, будет получать немного отличающиеся значения (уже проверено). Ну а три раза подряд – это и есть защита от коллизий в пределах одной секунды, ещё и на разных инстансах.
Так вот вопрос:
Насколько по вашему подход, выбранный мной, будет надёжным? Конечно же, учитывая генерацию на разных инстансах.
Код который на инстансе получает 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 (или я его исправлю и отправлю гандозавру на апдейт). Конечно, я его проверю на уникальность, но коллизия должна быть исключением настолько редким, что песец.