Отправка заголовков и данных POST через NGINX на вторичный сервер асинхронно?

Question

Я хочу отправить данные, полученные NGINX, на другой сервер в асинхронном режиме без каких-либо задержек в обработке запроса NGINX.

Вот подробный сценарий:

Пользователь отправил запрос на мой сервер NGINX, который выполняет скрипт и показывает ответ.

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

NGINX не должен ждать ответа от этого сервера, и не должно быть никаких задержек в обслуживании начального ответа, который хотел пользователь.

Дайте мне знать, если понадобятся какие-либо дополнительные разъяснения.

Answer 1

Поскольку вы, безусловно, хотите переслать данные POST на другой сервер, я хотел бы изучить использование сценариев на PHP, Lua, Ruby ... и сделать что-то подобное (PHP-подобное):

$data = json_encode($_POST);
file_put_contents("/tmp/data.json", $data);
exec("log-data.sh&");

& в командной строке для команды exec() запускает эту команду "в фоновом режиме", отсоединенную от текущего экземпляра PHP. Здесь я показываю сценарий оболочки, это может быть другой сценарий PHP, программа на C, Lua, что угодно.

Дело в том, что скрипт выполняет строгий минимум, который разделяет данные $_POST и затем запускает скрипт. (одна важная вещь, однако, имя "/tmp/data.json" должно генерироваться динамически, иначе, когда происходят два одновременных запроса, данные первого разбивают данные другого, или даже они оба записывают в файл согласованно ...)

Если вы планируете написать свой собственный модуль nginx, вы бы сделали то же самое. Ваш обработчик сохранит данные POST в файле, а затем вы начнете процесс с fork() + exec(), чтобы запустить другой сценарий, программу на C, и тому подобное в фоновом режиме. Однако для этого необходимо перекомпилировать nginx.

Answer 2

Для асинхронной отправки данных на другой сервер вы можете использовать Beanstalkd .

Однако недавно мы установили систему, в которой мы использовали Beanstalkd. Оказалось, что это отрицательно сказалось на скорости работы с входящими запросами. Поэтому мы приняли решение напрямую отправить запрос на другой сервер. Это работало более последовательно.

С уважением,