Как организовать генерацию номеров тикетов?

Question

[starkzz]

Доброго времени суток.
Ситуация есть 2 сайта с на которых подключен сервис для создания тиекта(задание вопроса, описание какой-то проблемы у пользователя).
Есть сайт агрегатор тикетов на котором сидят операторы и помогают пользователям 2 сайтов.
Как работает сейчас - на сайте №1 пользователь жмет кнопочку "создать тикет", заполняет поля и жмет "отправить".
Запрос летит на агрегатор, там выдается уникальный цифровой код - номер тикета и возращается пользователю (бла-бла-бла, ваш тикет зарегистрирован под номером 1234567890).
Операторы на агрегаторе не в курсе для клиента какого сайта они отвечают, так и должно быть.
Суть кода генерации тикета явно не корректная - генерируется случайное n-значное число, делается селект из базы, ничего не селектнулось - отлично, у тикета будет такой номер, селектнулось - генерируется номер и селектается опять.
Сейчас сайта 2, но в будущем может быть и 100.
Выдать каждому сайту какой-то диапазон номеров - так себе идея, с 1 может за год прийти 2 тикета, а с другого 100 за 1 день.
Была мысль генерить номер на сайте-клиенте, а на сайте агрегаторе хранить номер в куче с ИД сайта-клиента, но тогда возможна ситуация, что у оператора могут оказаться перед глазами 2 тикета - 3334445, один с сайта №1, а другой с сайта №2 (напоминаю, что оператор не должен знать с какого сайта клиента пришел тикет)
Была мысль организовать сторонний сервис на каком-то node.js который будет держать пул всех номеров с отмеченными занятыми и на запрос просто будет выдавать номер и сразу же его блокировать(немного сомнительной кажется идея)

Вопрос: как организовать корректную генерацию номеров тикетов?

Answer 1

[Константин Б.]

Чем вам плох autoincrement и last insert id? Это самое удобное что было придумано. зачем городить городки?

Comments

[starkzz]

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

[Константин Б.]

n значность - можно сделать любую

[Константин Б.]

нужна уникальность, юзайте хеши в чем беда

[Сергей Соколов]

starkzz: чтобы два тикета подряд сильно отличались, нужна 1:1 трансформация в другое множество. Простейший вариант – инверсия порядка бит. Например, 199 становится 3808428032, а 200 – 318767104

[starkzz]

Сергей Соколов: Возможно я вас не правильно понял, "инверсия порядка бит" это же ~ операция? Но там из 199 получится -200

[Сергей Соколов]

starkzz: в БД id скорее всего, 32-битное целое (4 байта), его можно в 64-битном пространстве считать всегда положительным

[starkzz]

Сергей Соколов: извините, но я все равно не понял, что вы имеете ввиду, может просто фрагмент кода?

[starkzz]

Сергей Соколов: пока только посетила мысль таким способом генерировать
mt_srand($registeredSiteId);
$ticketNumber = mt_rand(11111111111, 99999999999);

[Сергей Соколов]

starkzz: обновил свой ответ насчёт зеркального порядка бит в младших 4 байтах.

Answer 2

[Sanes]

Префикс сервера+id

Comments

[starkzz]

Когда оператор общается по тикету 11111111111 то он у себя должен видеть именно этот номер, а не 22_11111111111, если же просто при показе оператору отсекать префикс, то может получится ситуация, что перед 1 оператором будут 2 заказа с номерами 11111111111, хотя в базе они будут 22_11111111111 и 3_11111111111

[Sanes]

starkzz: 22_11111111111 можно записать, как 2211111111111

[Dmitry Bay]

Sanes: там суть что оператор не должен знать откуда пришел тикет, как я понял.

[Sanes]

Дмитрий Байчапанов: а как он узнает?

[Dmitry Bay]

Sanes: ну обработает он 30 заявок, найдет закономерности... Вы бы тоже обратили внимание, не так ли?

[Sanes]

Дмитрий Байчапанов: И что?

[starkzz]

Sanes: абстрактная ситуация, на тикете 1234567890 попался очень психованный клиент, и оператор очень хорошо запомнил номер тикета, так как общался очень много и долго, и через неделю ему снова попадается тикет 1234567890, но в нем абсолютно другой вопрос и совсем другой человек.

[Sanes]

starkzz: Вы видимо плохо себе представляете работу с обращениями. Включая аутсорс.

Answer 3

[Dmitry Bay]

А я подумал о том, чтобы создать дополнительный сервер, выдающий ИД.

СайтСервер запрашивает ИД у ИдСервер, ИдСервер создает у себя в таблице строку, с краткой информацией, с какого сайта пришел запрос.

Comments

[starkzz]

тоже подумывал об этом, но есть вопросы - пойдет-ли node.js? что будет если он упадет?
+ на текущий момент запущенно на шэерд хостинге, где никакой ноды нету, только пхп, перенсти на VPS конечно можно было бы, но это приведет к накладным расходам по настройке энваермента(объяснить целесообразность этого можно, но это будет долгий процес - "зачем нам какой-то впс и доп. настройки, когда и так все работает нормально")

[Dmitry Bay]

starkzz: я не знаком с технологиями node.js .

Если все сайты на одном хостинге, то все можно сделать в рамках одной базы данных на текущем сервере.

Answer 4

[Сергей Соколов]

Как это сделано у Redis, алгоритм Redlock:

1. понадобится доп. поле для случайной строки;
   
2. генерите случайный ID и случайное значение;
   
3. вставляете в таблицу запись с этим ID и значением. БД не позволит вставить, если уже есть такой ID.
   
4. Читаете эту запись и её доп.поле. Если считанное доп.значение совпало с вашим сгенеренным случайным значением – всё круто, этот ID ваш, можно его использовать;
   
5. Если считалось, но там другое значение доп. поля – придётся снова генерить новый случайный ID и сл. значение ему в пару – до тех пор, пока не попадёте пальцем в небо. Чем больше тикетов в системе, тем дольше может понадобиться погадать. И скорее переписать всю ущербную систему на последовательную нумерацию записей и генерацию не выглядящих последовательными биьективных трансформаций из них (самое простое – инверсия порядка битов).
   

Upd. подробнее об идее с перемешиванием битов последовательных ID, чтобы они выглядели непоследовательно. Самый простой вариант однозначного соответствия между двумя множествами это инверсия порядка битов. В БД храните последовательные возрастающие ID. Тип INT в MySQL занимает 4 байта, это 32 бита. Для отображения их клиенту вы в PHP или NodeJS (они все 64-битные) инвертируете порядок бит в младших 4 байтах. Например:

было 199
00000000 00000000 00000000 11000111
стало (зеркально)
11100011 00000000 00000000 00000000
это 64-битное число 3808428032

было 200
00000000 00000000 00000000 11001000
стало
00010011 00000000 00000000 00000000 (318767104)

Такое зеркалирование порядка – операция обратимая. Дважды отзеркалить – будет исходное. Поэтому клиентам показываете эти сложные номера, у себя ведёте последовательные упорядоченные ID.

Код для реверса порядка бит на JS и PHP я уверен, вы напишете самостоятельно. Подскажу, что для увеличения скорости операции удобно использовать небольшую таблицу байтов 16x16.