re_qasvkle

по логике должен сработать аналогично fopen(..,'x') если есть вернет false....Ну так fopen там (в первой строчке) и используется, только ориентирован он не на относительно медленное создание нового файла в ФС, а на обращение к уже существующему и прочитанному с диска (хранящемуся в файловом буфере) файлу. В этом смысле область такого использования несколько ограничена. Если правильно понимаю внутреннюю кухню PHP, в данном случае flock лишь вызывает системную функцию блокировки файла.

re_qasа если стоит raid-storage-claster то не может быть проблема в том что мой файловый разбит на несколько сервов?Полагаю, если каталог или цепочку каталогов, где создается файл, требуется читать с диска - возможно, это будет долгим процессом. Если каталог не вымывается из буфера ФС - вряд ли.

re_qasvkleпропущено...
В смысле, должен произойти единственный запуск скрипта. Параметры запуска один раз вычислили и любая попытка запуска должна использовать именно их. Правильно понимаю?именно этой части идет наличие по uri $bid через пост и проверка дольше только то этому одному параметру... само добавление ветвлится но на другие $bid перепрыгнуть не может - $bid - корень... новый появляется 4-10 раз в 5 минут... раз в 5 минут у всех 1500+ срабатывает запрос на обновление... этот запрос возвращает список $bid, по которому пинается скрипт на добавление по принципу кто первый от того и добавим - остальных нах...

Возможно, я бы сделал как-то так. Обозначу основные моменты.

1. Запуск единственного экземпляра основного скрипта. По крону или другим образом - не суть важно.
2. Там бесконечный цикл с проверкой нового $bid и sleep порядка нескольких десятков секунд исходя из условия "новый появляется 4-10 раз в 5 минут". Если проверка наличия нового не сильно ресурсожруча - можно и почаще проверять.
3. Если найден новый $bid - переходим в ветвь добавления/обновления.

Если само по себе обновление окажется процессом слишком длительным и не укладывается в приемлемое время - тогда, вероятно, сделал бы форк скрипта или (более вероятно) системный вызов с запуском скрипта добавления без ожидания завершения. Но тут надо дополнительно контролировать количество дочерних процессов, чтоб выше крыши не наплодить, так как без контроля в случае перегрузки сервера Load Average будет расти лавинообразно (процессы не успевают отрабатывать). Да, и у форка есть куча неожиданных и, порою, не совсем приятных особенностей.

Как-то вот в такую сторону стал бы смотреть.

re_qasпроверка "r+"... т.е. лишнее телодвижение процессора в части открыть и потом заблокировать,А вот и не угадали. :-)
Ибо сам __FILE__ (этот самый файл скрипта, который содержит эту строчку кода) в момент исполнения скрипта уже "открыт" - прочитан с диска и загружен в оперативную память совсем недавно. И, наверняка, сам файл или указатель на него ещё не был удален из буфера. Остается только сделать попытку исключительной блокировки.

re_qasvkleпропущено...
Полагаю, если каталог или цепочку каталогов, где создается файл, требуется читать с диска - возможно, это будет долгим процессом. Если каталог не вымывается из буфера ФС - вряд ли.попинаю завтра админа проверить где моя часть массива сидит... межсерверовая пинговка <1ms но если с запросом по файлу... то реально может быть косяк...Пингу (ICMP пакету) не требуется шкрябать головками дисков, так что, это совсем не показатель.

Заодно, чтоб два раза не бегать, поинтересуйтесь у админа о наличии на сервере локальной файловой системы типа memory и возможности доступа скрипта к ней. Нередко бывают какие-нибудь tmpfs с такой организацией размещения. Если файл блокировки делать там, оно, скорее всего, будет работать существенно быстрее.