RabbitMQ PHP для динамического обновления сообщений

Я изучаю RabbitMQ и думал об использовании его для предоставления пользователям обновлений «динамических сообщений», очень похоже на то, как facebook дает динамические ленты от друзей.

Моя идея была:

  1. Каждый раз, когда создается пользователь, я буду создавать очередь с именем пользователя userId, поэтому имя очереди может быть "100_message_queue" (userId_message_queue).

  2. Производитель отправит все обновления в эту очередь.

  3. Со стороны клиента (javascript) он вызовет REST API, например «GET http://example.com/getliveupdates/100», затем я получу все новые обновления из 100_message_queue и отправлю его в качестве ответа.

Я читал руководства по RabbitMQ php, но не могу понять, как это возможно? Более того, потребитель работает вечно, поэтому кажется, что я не могу сделать никаких запросов REST. Это дает мне тайм-аут.

Есть идеи, как реализовать такую ​​структуру?

Спасибо


person voila    schedule 03.10.2014    source источник
comment
Итак, вы опрашиваете свою очередь, но вы предпочитаете push-уведомления сервера?   -  person ʰᵈˑ    schedule 03.10.2014


Ответы (1)


Поскольку вы планируете доставить эти сообщения в веб-клиент, я бы порекомендовал изучить MQTT и STOMP с Web STOMP RabbitMQ плагины. Для вас это должно быть идеальным решением использовать их мощь над WebSocket. И это дает вам обмен сообщениями в реальном времени, что всегда является профессионалом и, вероятно, тем, что вам нужно.

Что касается работы с вечно работающими потребителями:

Если вы используете расширение php-amqp, вы можете установить для параметра read_timeout некоторые небольшие значения, например 1 (сек), поэтому, когда потребитель получит все сообщения из очереди, он будет ждать 1 секунду. more для новых сообщений, а затем выбросить исключение (я думаю, AMQPConnectionException, уродливое решение, но пока это делается именно так).

Как вариант, вы можете AMQPQueue::get сообщения из очереди до тех пор, пока не закончатся сообщения.

С php-amqplib все должно быть так же, по крайней мере, идея остается прежней: ограничить потребителя ожиданием новых сообщений по времени или итеративным способом получения сообщений из очереди.

person pinepain    schedule 03.10.2014