Временное хранилище для сбора данных перед отправкой
Я работаю над пакетом композитора для приложений PHP. Цель состоит в том, чтобы отправить некоторые данные после запросов, заданий в очереди, других предпринятых действий. Моя первоначальная (и рабочая) идея заключается в использовании register_shutdown_function сделать это. У этого подхода есть пара проблем, во-первых, это увеличивает время отклика страницы, а это означает, что накладные расходы по обработке запроса плюс отправка данных через мой API. Другая проблема заключается в том, что долго выполняющиеся процессы, такие как работники очереди, не выполняют этот метод в течение длительного времени, поэтому могут существовать большие разрывы между тем, когда данные были созданы и когда они были отправлены и обработаны.
Я думаю, что я мог бы использовать какое-то временное хранилище для хранения данных и иметь cronjob для отправки их каждую минуту. Единственная проблема, которую я вижу при таком подходе, — это управление параллелизмом на высоких IO. Поскольку многие процессы будут записывать в файл каждую (n) мс, существует проблема с чтением файла и удалением уже отправленных строк.
Другим вариантом, которого я отчаянно пытаюсь избежать, является использование клиентской базы данных. Это может привести к проблемам с производительностью.
Какой предпочтительный способ сделать это?
Изменить: пакет по сути является агентом мониторинга.
Решение
Есть несколько проблем с этим подходом, во-первых, это увеличивает время отклика страницы, что означает, что накладные расходы на обработку запроса, плюс отправка данных через мой API
Я не уверен, что вы можете обойти это, будут дополнительные издержки для выполнения дополнительной работы в контексте веб-запроса. Я чувствую, что использование асинхронной системы на основе очереди заданий сводит это к минимуму для клиента. Независимо от того, выберете ли вы запись в локальную файловую систему или запись в сокет, у вас будут дополнительные издержки, но вы сможете сразу вернуться к клиенту и не блокировать обработку этого запроса.
Другая проблема заключается в том, что долго выполняющиеся процессы, такие как работники очереди, не выполняют этот метод в течение длительного времени, поэтому могут существовать большие разрывы между тем, когда данные были созданы и когда они были отправлены и обработаны.
Разве это не весь смысл ?? : p Чтобы немедленно вернуться к клиенту, а затем асинхронно завершить работу в какой-то момент в будущем? Использование очереди заданий позволяет отдельно разделять и масштабировать рабочий пул и веб-сервер. Ваши веб-серверы могут быть довольно скудными, потому что тяжелые работы откладываются на рабочих.
Я думаю, что я мог бы использовать какое-то временное хранилище для хранения данных и иметь cronjob для отправки их каждую минуту.
Я бы определенно рекомендовал смотреть на очередь на работу, а не на собственную. Это в значительной степени решено, и есть много чрезвычайно популярных проектов с открытым исходным кодом, чтобы справиться с этим (любой из MQ). Будет ли минутная работа cron выполнять вычисления для клиента? Как вы масштабируете это? Если в файле 1000 записей или вы масштабируете 10х, а в нем 10000, сможете ли вы выполнить все эти вычисления менее чем за минуту? Что произойдет, если сервер умрет? Как вы поправляетесь? Межпроцессный параллелизм? Вам нужно будет управлять блокировками для каждого процесса? Будете ли вы использовать отдельный файл для каждого процесса и каждой минуты? К ведру событий? Что произойдет, если вы хотите менее 1 минуты пробежки?
Гарантии долговечности
Какие гарантии вы предлагаете своим клиентам? Если запрос возвращается, может ли клиент быть уверенным, что задание сохраняется, и оно будет выполнено в будущем?
Я бы определенно рекомендовал выбрать рабочую очередь и сделать так, чтобы процессы вашего веб-сервера записывали в нее. Это чрезвычайно популярная проблема с большим количеством ресурсов о том, как ее масштабировать, и с четкими гарантиями долговечности и производительности.
Другие решения
Других решений пока нет …