Приветствую всех зашедших!
Пытаюсь сообразить как сделать и не могу понять, если кто знает, дайте знать.
Есть файл, например: 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 без ошибок и повторов.
Может у кого есть мысли?
1. antobra - 19 Января, 2018 - 17:27:19 - перейти к сообщению
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 - перейти к сообщению
Мелкий пишет:
И это если ещё везёт.
Реально можно повредить структуру строки, потерянная запись, частичная запись поверх и другие приключения.
Читать последнюю строку с намерением что-то писать на её основе вы должны строго после взятия write flock.
fopen
flock write
fread
some calc
write
unlock
fclose
Если проблема со счётчиком - поставьте рядом redis. Атомарный инкремент там есть, да и сам по себе штук не бесполезный.
Если проблема не только со счётчиком, а ещё и хранением данных - то используйте знакомую вашей команде СУБД. У всех распространённых должны быть конкурентно-безопасные сиквенсы.
antobra пишет:
в logs.txt появляются дубли ID
И это если ещё везёт.
Реально можно повредить структуру строки, потерянная запись, частичная запись поверх и другие приключения.
antobra пишет:
Самое первое - это flock. Его проблема это блокировка файла на момент записи. С записью как раз проблем нет.
Читать последнюю строку с намерением что-то писать на её основе вы должны строго после взятия write flock.
fopen
flock write
fread
some calc
write
unlock
fclose
Если проблема со счётчиком - поставьте рядом redis. Атомарный инкремент там есть, да и сам по себе штук не бесполезный.
Если проблема не только со счётчиком, а ещё и хранением данных - то используйте знакомую вашей команде СУБД. У всех распространённых должны быть конкурентно-безопасные сиквенсы.
Да, пару раз данные были нечитаемыми
![Улыбка Улыбка](./im/emoticons/smile24.gif)
Попробую ваши варианты с flock, после с redis.
Эта функция не имеет высокий приоритет и поэтому скорость и ресурсы сервера важней. Выбирается самый экономичный способ
(Добавление)
andrewkard пишет:
много это сколько? В сек.
antobra пишет:
БД будет слишком медленной -- много запросов. И думаю, сервер сильно потеряет в производительности.
много это сколько? В сек.
конкретно сейчас среднее - 600 в сек, цифра меняется в зависимости от дня, времени и пр