Отправка информации в ngnix из php на том же сервере без http

Я предполагаю следующее:

Текущий рабочий поток:

1. Пользователь запускает php-скрипт из командной строки, который связывается со скриптом / cgi на стороне сервера в Nginx, используя http-запрос
2. Серверный скрипт / cgi в Nginx будет принимать входящие данные, обрабатывать их и помещать в базу данных или отправлять конечным пользователям

OP:

Эффективность скрипта php командной строки, связанного с скриптом на стороне сервера Nginx с использованием протокола HTTP, который может быть переполнен, поскольку общение происходит на одном сервере.

Предложение 1

1. Сценарий php командной строки будет записывать всю информацию в файл (ы), а затем отправить один HTTP-запрос на скрипт cgi на стороне сервера Nginx
2. Сценарий cgi-сервера Nginx после получения запроса собирает всю информацию из файла (ов), затем обрабатывает его
3. ramfs (ram-диск) можно использовать для минимизации ввода-вывода для физического HD

Предложение 2

Объедините скрипт php командной строки с скриптом на стороне сервера Nginx и создайте для него веб-интерфейс. Пользователь текущей командной строки войдет в веб-страницу, чтобы контролировать процесс, который они использовали для этого с помощью средства командной строки.

Pro: Больше нет меж-скриптов / межпроцессного общения. Весь рабочий процесс находится в одном процессе. Это может быть более масштабируемым для будущего, так как несколько пользователей могут входить в систему через веб-интерфейс и обрабатывать этот процесс удаленно. Кроме того, они не требуют учетных записей уровня ОС.

Con: Может потребоваться больше времени разработки. (Но вам нужно сохранить только одну базу кода вместо двух).

Почему бы вам не рассмотреть использование socket.io и Amazon SNS?

В нашей инфраструктуре, когда мы хотим отправить уведомление конкретному клиенту, подписанному на канале socket.io, мы отправляем полезную нагрузку в тему SNS Amazon. Эта полезная нагрузка имеет атрибут «канал» и «сообщение» для отправки клиенту. Я даю только фрагмент из нашего кода, который легко понять

$msg = array( 'channel' => $receiver->getCometChannel(), //Channel id of the client to send the message 'data' => json_encode($payload) //The message to send to the client ); $client = $this->getSNSObject(); $client->publish(array( 'TopicArn' => $topicArn, 'Message' => json_encode($msg) )); 

У нас есть сценарий node.js, который создает и конечную точку на порте 8002 ( http: // your_ip: 8002 / receive ). Когда Amazon SNS получает полезную нагрузку из PHP-серверов, он перенаправляет эту полезную нагрузку на эту конечную точку, а затем единственное, что нужно сделать обрабатывает полезную нагрузку и отправляет сообщение соответствующему клиенту через socket.js. Вот сценарий node.js:

 var fs = require('fs'); var options = { pfx:fs.readFileSync('/etc/ssl/certificate.pfx') //optional, for SSL support for socket.js }; var io = require('socket.io')(8001); // open the socket connection io.sockets.on('connection', function(socket) { socket.on('subscribe', function(data) { socket.join(data.channel); }); socket.on('unsubscribe', function(data) { socket.leave(data.channel); }); socket.on('message', function (data) { io.sockets.in(data.channel).emit('message', data.message); }); }) var http=require('http'); http.createServer(function(req, res) { if(req.method === 'POST' && req.url === '/receive') { return client(req, res); } res.writeHead(404); res.end('Not found.'); }).listen(8002); var SNSClient = require('aws-snsclient'); var client = SNSClient(function(err, message) { try{ var body=JSON.parse(message.Message) var channel=body.channel,data=(body.data); console.log(channel); io.sockets.in(channel).emit('message', {channel: channel, data: data}); } catch(e) { console.log(e); } }); 

Может быть, это кажется сложным, но идея ясна.

Позвольте мне ответить шаг за шагом:

1. Является ли отправка 30+ HTTP-запросов на PHP-скрипт хорошей практикой?

Это не проблема, пока вы не удовлетворитесь скоростью. У вас есть две потенциальные проблемы с этим решением:

 a. high timing to reestablish http connection each request; b. when concurrent requests reach its maximum nginx can skip some of your requests; 

2. Какова наилучшая практика для обработки таких сообщений?

Как вы сказали, лучше всего использовать интерфейс Query. Но я не уверен, есть ли способ справиться с этим на стороне nginx (я не понимаю, с технологией, которую вы используете на стороне nginx).

Также вы можете использовать длинное опросное соединение для отправки запросов на nginx, что уменьшит время ожидания от проблемы (a), но может вызвать некоторые новые проблемы.

Как насчет использования PHP-FPM, подключенного к Nginx через сокеты домена Unix, используя протокол FastCGI? Это самый быстрый способ сделать IPC между Nginx и PHP – накладные расходы IO очень мало, по сравнению с интернет-сокетом.

Еще одно решение, которое мы пробовали раньше, – это развертывание сервера ejabberd (его можно настроить), напишите небольшой клиент javascript, используя клиент strophe. http://blog.wolfspelz.de/2010/09/website-chat-made-easy-with-xmpp-and.html?m=1 хорошее сообщение в блоге по этой теме. Если вы хотите разработать чат-приложение, я бы выбрал этот вариант.

Еще одно преимущество: ваши пользователи могут также использовать клиенты xmpp для подключения к вашей платформе чатов.