Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Получить, обработать, записать - сложности
Форумы портала PHP.SU » » Работа с файловой системой и файлами » Получить, обработать, записать - сложности

Страниц (1): [1]
 

1. antobra - 19 Января, 2018 - 17:27:19 - перейти к сообщению
Приветствую всех зашедших!

Пытаюсь сообразить как сделать и не могу понять, если кто знает, дайте знать.

Есть файл, например: logs.txt

С этим файлом проходит следующая работа -
1. Изымается последняя строка
2. Из этой строки изымается ID (порядковый номер)
3. Вносится в конец файла новая строка с ID+1
Все просто.

Но вопрос вот в чем:

Это делает не один скрипт/демон/процесс, а много процессов. То есть 100 юзеров сделало запрос и все запросы ломанулись в logs.txt.
И многие уже поняли, что в logs.txt появляются дубли ID. То есть, скрипт открыл файл взял ID и положил новые данные. И так же сделало еще несколько процессов.

Мои мысли на эту тему:
Самое первое - это flock. Его проблема это блокировка файла на момент записи. С записью как раз проблем нет. Дело в том, что сразу много запросов получили информацию о том, что в конкретный момент времени ID = 1500. Они и записали 1501, как следующий.
Следуя этой логике необходим только один процесс, который будет добавлять записи с нужным ID. Но не могу сообразить как это осуществить.

Так же информация, которая может быть полезной:
- ID обязателен. Отказаться от ID не могу
- 100 запросов это лишь пример. В реальности их больше.

Это скорей вопрос не к PHP, а к организации и архитектуре такой функции, как постоянная выдача следующего ID без ошибок и повторов.

Может у кого есть мысли?
2. andrewkard - 19 Января, 2018 - 17:54:12 - перейти к сообщению
antobra пишет:
Следуя этой логике необходим только один процесс, который будет добавлять записи с нужным ID. Но не могу сообразить как это осуществить.

очередь

А почему не хотите в таблицу БД перенести с колонкой автоинкремент?
3. Мелкий - 19 Января, 2018 - 17:59:01 - перейти к сообщению
antobra пишет:
в logs.txt появляются дубли ID

И это если ещё везёт.
Реально можно повредить структуру строки, потерянная запись, частичная запись поверх и другие приключения.

antobra пишет:
Самое первое - это flock. Его проблема это блокировка файла на момент записи. С записью как раз проблем нет.

Читать последнюю строку с намерением что-то писать на её основе вы должны строго после взятия write flock.
fopen
flock write
fread
some calc
write
unlock
fclose

Если проблема со счётчиком - поставьте рядом redis. Атомарный инкремент там есть, да и сам по себе штук не бесполезный.
Если проблема не только со счётчиком, а ещё и хранением данных - то используйте знакомую вашей команде СУБД. У всех распространённых должны быть конкурентно-безопасные сиквенсы.
4. antobra - 19 Января, 2018 - 18:12:33 - перейти к сообщению
andrewkard пишет:
antobra пишет:
Следуя этой логике необходим только один процесс, который будет добавлять записи с нужным ID. Но не могу сообразить как это осуществить.

очередь

А почему не хотите в таблицу БД перенести с колонкой автоинкремент?


Тоже размышляю над очередью. Что-то вроде: сначала просто в конец файла без ID писать, а потом каким-то скриптом по cron дописывать в конец каждой строчки сумму ( номер этой строчки + последний ID с прошлого выполнения).

БД будет слишком медленной -- много запросов. И думаю, сервер сильно потеряет в производительности.
5. andrewkard - 19 Января, 2018 - 18:17:10 - перейти к сообщению
antobra пишет:
БД будет слишком медленной -- много запросов. И думаю, сервер сильно потеряет в производительности.

много это сколько? В сек.
6. antobra - 19 Января, 2018 - 18:20:16 - перейти к сообщению
Мелкий пишет:
antobra пишет:
в logs.txt появляются дубли ID

И это если ещё везёт.
Реально можно повредить структуру строки, потерянная запись, частичная запись поверх и другие приключения.

antobra пишет:
Самое первое - это flock. Его проблема это блокировка файла на момент записи. С записью как раз проблем нет.

Читать последнюю строку с намерением что-то писать на её основе вы должны строго после взятия write flock.
fopen
flock write
fread
some calc
write
unlock
fclose

Если проблема со счётчиком - поставьте рядом redis. Атомарный инкремент там есть, да и сам по себе штук не бесполезный.
Если проблема не только со счётчиком, а ещё и хранением данных - то используйте знакомую вашей команде СУБД. У всех распространённых должны быть конкурентно-безопасные сиквенсы.


Да, пару раз данные были нечитаемыми Улыбка

Попробую ваши варианты с flock, после с redis.
Эта функция не имеет высокий приоритет и поэтому скорость и ресурсы сервера важней. Выбирается самый экономичный способ
(Добавление)
andrewkard пишет:
antobra пишет:
БД будет слишком медленной -- много запросов. И думаю, сервер сильно потеряет в производительности.

много это сколько? В сек.


конкретно сейчас среднее - 600 в сек, цифра меняется в зависимости от дня, времени и пр

 

Powered by ExBB FM 1.0 RC1