2014-10-03 1 views
0

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

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

  1. Всякий раз, когда пользователь будет создан создам очереди, имеющей имя это идентификатор пользователя пользователя, так имя очереди может быть «100_message_queue» (userId_message_queue).

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

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

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

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

Благодаря

+1

Итак, вы проводите опрос своей очереди, но лучше предпочтете серверный толчок? –

ответ

1

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

Как иметь дело с управлением навсегда потребителей:

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

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

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

Смежные вопросы