AMQP-REST

    про AMQP говорили много. Очередная разработка, ориентированная на AJAX.
    Возможности:
    • читать из очереди одно сообщение
    • читать из очереди все сообщения
    • узнать длинну очереди
    • публиковать сообщение в обмен

    Данные возвращаются в JSON.


    Сборка


    logfile /usr/local/var/amqp.log; # logfile
     
    pidfile /tmp/amqp.pid; # pidfile
     
    log_level notice; # the level of logging : error, notice, warning, debug
     
    daemon   on; # daemon mode
     
    port 80;   # http port, default 80
    http 10.0.0.1;  # bind IP
     
    amqp :5672;   # amqp connection string  psw:login@host:port/vhost 
     


    Запуск

    ./amqp-rest [полное имя конфиг-файла]
    ./amqp-rest stop // останавливает сервис
    kill -s HUP `ps | grep amqp-rest | awk '{print $1}'` // перезапуск с новой конфигурацией


    Использование

    чтение одного элемента из очереди
    именем очереди выступает правая часть url до последнего слеша. Для урла /sss/q2 именем очереди будет «q2». Это сделано намеренно, так как все урлы вешаются на определенный локейшен и проксируется через nginx.
    curl 10.0.0.1:8080/sss/q2
    {"result": "OK", "message":"message 2", size : 2}
    // size - размер очереди, сколько элементов осталось в очереди.


    чтение всех элементов из очереди
    curl 10.0.0.1:8080/sss/q2?all
    {"result": "OK", "count" : 2, messages ["message 3","the text\"xxxx\" tttt"]}
    // count - размер массива сообщений.


    размер очереди
    curl 10.0.0.1:8080/sss/q2?count
    {"result": "Ok", "count": 3 }


    публикация
    Именем обмена так же является часть урла между последним слешем и '?', а ключом обмена является часть урла, после знака вопроса. Например для урла 10.0.0.1:8080/sss/ex1?news
    именем обмена является «ex1», а ключом обмена (routing key) является «news»
    curl -d 'some post data' 10.0.0.1:8080/sss/ex1?news
    {"result": "Ok"}


    Конечно, все расчитано на AJAX. nginx стоит фронт сервером и проксирует запросы на amqp-rest. Можно обойтись и без nginx, если их повесить на разные IP. В моем случае я использую ngx_accesskey_module для защиты от спама. Возможно этот функционал в будущем перенесется в amqp-rest.

    заключение

    что каается производительности: 1300rps
    место в памяти 601к

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 051 анкеты, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 26

      0
      Интересно, нужно будет попробовать.
        –1
        Не думаю, что это будет удобнее, чем websocket. К тому же в данном случае, мы ограничены только одним consumer'ом
          0
          сравнивать amqp и websocket — тоже самое что солдата и балерину. Кто-то умеет танцевать, а кто-то стрелять.
            0
            тем более, что одно транспорт, а второе протокол/формат обмена данными :) AMQP через веб-сокеты это самое оно (хотя во многих случаях и STOMP достаточно). тем более что все основные MQ брокеры уже заявили что поддерживают WS как транспорт (ActiveMQ и JBoss HornetQ)
              0
              хмм… я думал это netty поддерживает websocket, а не hornetq
                +1
                в HornetQ транспортный уровень (коннекторы которые, если я верно помню) работает на базе фреймворка netty, да, и уже давно. теперь можно просто в конфиге указать что использовать ws и все. а так конечно, оно через netty работает как и все остальные сетевые вещи
              +1
              с чего вы решили, что я сравниваю websocket с amqp? я сравниваю websocket и rest.
                0
                надо присмотреться к websocket
                спасибо за комментарий.
            0
            насколько я понял чтение сообщений через long-poll?
              0
              нет, это планируется сл. этапом.
              пока идет только обкатка сервера

              в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
              планирую разработку синхронного запроса BASIC.CONSUME
              тогда без comet технологии не обойтись.
                0
                Basic.Get — синхронный метод
                Basic.Consume — асинхронный
                  0
                  IMXO. тут трудно спорить, судя ГОСТУ — они оба синхронные:
                  Basic.Consume (ID=10) start
                  a queue consumer: Sync request, carries content
                  Basic.Get (ID=80) direct
                  access to a queue: Sync request, carries content

                  но по своей сущности Consume — синхронный запрос, как только сообщение появляется в очереди, оно сразу считывается (передается клиенту), коннекция держится постоянно. в этом смысле — синхронный.
                  методом GET ты можешь забрать сообщение в любое время из очереди (или пустое уведомление GET-EMPTY). коннекцию постоянно можно не держать. в этом смысле — асинхронный. Хотя если смотреть с иной стороны, как только мы выдаем GET, мы сразу получаем (синхронно) ответ: либо GET-OK либо GET-EMPTY, т.е. синхронный.
                    0
                    блин прочитал что написал и сам запутался…
                    0
                    а как будут синхронные запросы обрабатываться на 10к коннектов?
                      0
                      честно говоря хз
                      до 10К надо еще мне дорости.
                      но вроде держать 10к не проблема? вот более 50к — это проблема.
                      Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,

                        +1
                        я не в том смысле, я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно? если плодить потоки — то и 1к коннектов будет сложно обработать
                        или я неправильно понял?

                        ps: я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем.
                          0
                          я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно?
                          libevent библиотека с асинхронным ввод/выводом, т.е. использует неблокирующие сокеты. Все работает в одном потоке, только параллельно: как только приходит запрос на сокет, создается буфер и его начинает обрабатывать кэллбэк, если пришел еще один запрос, то новый буфер начинает обрабатывать следующий кэлбэк, если ответ от брокера не пришел, т.е буфер пуст, переходим к обработке следующего буфера и так проходимся по цепочке всех синициированных буферов. По окончанию работы кэлбека — буфер отдается в сокет и освобождается.

                          и вот еще одно мнение: amix.dk/blog/post/19414
                          поллинг проще реализовывать и масштабировать. Из всего что я видел, я сделал вывод – все Comet решения слишком уж хакерские, изворотливые и очень тяжело масштабируются. Они плохо масштабируются, потому что web платформы построены на модели запрос-ответ.

                          я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем
                          интересно посмотреть
                            0
                            ну если работа с синхронным методом асинхронная, тогда вопрос снимается ;)

                            см приват
                              0
                              ссылку посмотрю,
                              спасибо
                                0
                                идея состоит в следующем: прокси принимает сообщения amqp и складывает их во внутренние очереди (массивы) сообщений, а при подключении http клиента — проходит по всем внутренним очередям и отдает клиенту только те сообщения, которые нужны данному пользователю
                                а как конкретно фильтровать — прокси спрашивает по amqp у демона отвечающего за БД.

                                т.е. не просто трансляция amqp-http а прокси со своей бизнес логикой.
                                  0
                                  да, интересно. а брокер какой, ActiveMQ?
                                    0
                                    кролик
                                      0
                                      а кролик Websockets поддерживает? плагин?
                                        0
                                        хм. кролик = rabbitmq
                                        а зачем ему websockets? для websockets у меня отдельная прокся ;)
                                          0
                                          хм. кролик = rabbitmq
                                          это и ежу понятно
                                          для websockets у меня отдельная прокся ;)
                                          а куда эта прокся ведет?
                          0
                          у меня 1300 rps на ноуете 2.3 GHz 1Mg, но этого должно вполне хватить для обработки 10к
                          на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
                          сервер жрет 601К и 2 % CPU — даже смешно.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое