Реализация очереди сообщений

Я ищу самый быстрый способ зарегистрировать сообщение без подключения производителя к какому-либо серверу при отправке журнала. Наилучшим сценарием было бы просто быстро записать сообщение во что-то локальное (память, локальная очередь сообщений), а затем выйти. Затем отдельный процесс удаляет его из очереди и отправляет фактическому потребителю (возможно, с постоянным соединением). Это помогает снизить скорость обработки в процессе-производителе (например, дескрипторе веб-сервера), предотвращая дополнительное соединение.

Будет ли меня интересовать RabitMQ с использованием PHP?


rabbitmq php message-queue
person Chris Lee    schedule 22.05.2012    source источник
comment
когда вы говорите, что не хотите, чтобы производитель подключался к какому-либо серверу, вы имеете в виду физический внешний сервер? Я сбит с толку, потому что подключение к локальной очереди сообщений по сути означает подключение к серверу, даже если они находятся на одном и том же оборудовании.   -  person robthewolf    schedule 22.05.2012
comment
@robthewolf да, я как бы имел в виду это, но есть также очередь сообщений IPC, которая больше похожа на системный вызов, чем на фактическое соединение tcp. Итак, я подумал об одном локальном наборе производитель-потребитель, использующем IPC mq, и производитель-потребитель на сетевом уровне. Ключевым отличием будет то, что интерфейс для пользователей будет реагировать как можно быстрее, в то время как процесс, лежащий в основе, обрабатывает их последовательно.   -  person Chris Lee    schedule 23.05.2012

Ответы (3)


arrow_upward
1
arrow_downward

Logstash (http://www.logstash.net/) настраивает прослушиватели для выбранных вами локальных файлов журналов, а затем отправляет их в виде сообщений через AMQP (RabbitMQ, последний раз я проверял в 2012 году) в центральное хранилище журналов/базу данных по вашему выбору (скажем, экземпляр mongoDB).

Вы можете настроить прослушиватель Logstash так, чтобы он отфильтровывал только определенные интересные типы/коды сообщений журнала из файла журнала перед его отправкой брокеру очередей.

После этого вы можете настроить Graylog2 (http://graylog2.org/) как удобный интерфейс для чтения, сортировки и фильтрация ваших журналов, происходящих со всех ваших серверов, организованных в одном представлении в хронологическом порядке (при условии, что время вашего сервера достаточно синхронизировано).

person changingrainbows    schedule 13.04.2013

arrow_upward
0
arrow_downward

Как указывает @robthewolf в своем комментарии, подключение к очереди сообщений — это дополнительное подключение, локальное или нет. Кроме того, я не уверен, что именно вы подразумеваете под «обработкой» (форматирование сообщений? отображение журналов?).

Из того, что вы описываете, я думаю, вам следует изучить Graylog. Вы можете использовать Monolog с Gelf-PHP для отправки сообщений журнала через AMQP на ваш сервер Graylog.

person dbrumann    schedule 22.05.2012

arrow_upward
0
arrow_downward

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

person Shashi    schedule 24.05.2012