rand при параллельном вызове скриптов

[antson]

rand при параллельном вызове скриптов

упрощенно
1.php
<?
echo rand(0,99);

вероятность совпадения при одновременном обращение 2х пользователей к скрипту
1/100 или при совпадении вызова с точностью до микросекунды 100% ?

В документации есть
Замечание: Начиная с PHP 4.2.0, больше нет необходимости инициализировать генератор случайных чисел функциями srand() или mt_srand(), поскольку теперь это происходит автоматически.

Я правильно предполагаю что инициализацию завязали на время ?

p.s. 1/8,6 * 10^6 для единичного случая , а за год все таки совпала ;(

 

[HEm]

вероятность совпадения вызова с точностью до микросекунды значительно меньше вероятности 1/100

 

[fixxxer]

если тебе надо, чтобы некий идентификатор не совпал именно _одновременно_ в _параллельных_ скриптах (а думаю, что именно это тебе и надо, ибо с вероятностью 1/100 в течение года у тебя было бы несколько больше совпадений =), просто возьми идентификатор процесса ([m]posix_getpid[/m]).

правда, не сработает в двух случаях:
1) mod_php и тредовый апач (или иное threaded sapi),
2) винда (но там тоже как-то можно узнать id процесса).

 

[antson]

HEm
В общем не важно из-за чего совпало . от генерации случайного
номера придется переходить на генерацию заведомого уникального.

-~{}~ 03.09.10 18:31:

fixxxer
Это был $nomerZakaza=Date("His").rand(10,99);

Он должен быть уникальным в сочетании с датой заказа в пределах 2х месяцев.


Спасибо всем . при следующем повторе буду переписывать.

 

[Dovg]

antson
А не проще вместо "заведомо уникального" просто давать последовательно возрастающие номера + мусор для отвлечения внимания?

 

[dimagolov]

уникальным в сочетании с датой заказа в пределах 2х месяцев.

так "уникальным ... в пределах 2х месяцев" что вряд-ли, так как 45 заказов за месяц это слишком скромно, или "уникальным в сочетании с датой заказа", то есть уникальным в течении дня?

п.с. автоинкремент рулит, особенно во втором случае. потому что ограничивать себя 90 заказами в день тоже весьма скромно

 

[antson]

Dovg
dimagolov

Увы заказчику удобно в 1с в номере заказа видеть время .
А обмен с 1с завязан на номер а не ид.

-~{}~ 03.09.10 18:48:

уникальность 2 месяца . Реально заказы по безналу цикл обработки конечно заканчивают раньше, а тут с запасом.

 

[dimagolov]

заказчику удобно в 1с в номере заказа видеть время .

нифига не понял. время он там видит, а дату нет?

их там у тебя не бог весть сколько, храни в базе сгенеренные id за 2 месяца с уникальным ключем и если insert обламывается из-за совпадения, то генери повторно. по крону чисть старые.

 

[fixxxer]

А что мешает сделать date("His") . last_insert_id() искусственного sequence-а?

UPD: но это тоже не надо

в shared memory храним счетчик для текущего значения His, и все. только подчищать надо не забыть старье.

 

[ХакИрФсимагущий]

если нужен уникальный индификатор то используйте $nomerZakaza=uniqid(Date("His"),true)

 

[dimagolov]

ХакИрФсимагущий, ты бы перед тем, как что-то советовать, почитал бы топик, что ТС хочет получить и ман по той ф-ии, что ты советуешь

 

[fixxxer]

с таким ником можно и не читать

 

[antson]

ХакИрФсимагущий
uniqid - в результате длинный номер
fixxxer
. last_insert_id() - тоже самое

не подходит
а) ограничение на длину номера в 1с
б) жуть при попытке продиктовать его по телефону
в) неудобство при попытке поиска
вместо 8 вбивать 13 цифр минимум.

совпадение произошло 1 раз на 60 тысяч заказов , повторного сбоя думаю еще не будет год минимум, случиться раньше буду переписывать .

Всем спасибо.

 

[fixxxer]

эээ а до конца мой коммент дочитать ?

 

[antson]

fixxxer
я правильно понял завести себе 86400 счетчиков от 0 до 99 и брать две последних цифры из них.
Наверное так и поступлю.
Надо проверить , что быстрее будет.
работать с такой базой или просто проверять по заказам на уникальность.
86400/365 это 260 заказов в день, что пока превышает среднее число заказов в день

 

[fixxxer]

ну я не так предлагал. но - тоже вариант

 

[ХакИрФсимагущий]

Автор оригинала: dimagolov
ХакИрФсимагущий, ты бы перед тем, как что-то советовать, почитал бы топик, что ТС хочет получить и ман по той ф-ии, что ты советуешь

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

substr(uniqid('',true),16)

просто не думал что никто недогадается его обрезать.

 

[dimagolov]

просто не думал что никто недогадается его обрезать.

просто все кроме тебя догадались, что подстрока уникальной строки уникальной может и не быть и чем меньше длинна подстроки тем сильнее "может" превращается в "будет"