запустить и забыть по сравнению с запросом http

Question

Я ищу мнение от всех вас. У меня есть веб-приложение, которое должно записывать данные в другую базу данных веб-приложений. Я не предпочитаю использовать HTTP-запрос GET на втором приложении из-за задержки. Я искал быстрый способ быстрого сохранения записей во 2-м приложении, натолкнулся на идею «выстрели и забудь», подойдет ли JMS для этого сценария? Насколько я понимаю, JMS будет гарантировать доставку сообщений, не важно, будет ли сообщение доставлено на 100%, поскольку оно может обслуживать как можно больше запросов. Допустим, мне нужно вызвать не менее 1000 случайных запросов в секунду во 2-е приложение, следует ли мне использовать JMS? HTTP-запрос? или вместо XMPP?

Answer 1

Ваши требования:

• один клиент и один сервер (вывод из вашего первого предложения),
• HTTP является обязательным (исходя из вашего разговора о веб-приложении база данных),
• 1000 или более обновлений записей в секунду и
• отдельные обновления не нужно подтверждать синхронно (вы готовы использовать подход «забей и забудь».

Я хотел бы подойти к этому так, чтобы клиентские потоки помещали обновления в очередь внутри и реализовывали клиентский поток, который периодически собирает обновления в очереди в один HTTP-запрос и отправляет его на сервер. При необходимости сервер может отправить ответ, в котором указано состояние отдельных обновлений.

Пакетирование исключает влияние задержки на клиента и потенциально позволяет серверу более эффективно обрабатывать обновления.

Answer 2

Я думаю, что вы неправильно понимаете сетевое взаимодействие в целом. Нет никаких оснований полагать, что HTTP GET должен быть медленнее, чем что-либо еще, и если HTTP использует преимущества поддержки активности, он работает быстрее, чем большинство параметров.

JMX - это не протокол, это спецификация, которая охватывает многие другие протоколы, включая, возможно, HTTP или XMPP.

В конце концов, на уровнях, где будет работать Java, есть UDP или TCP. У TCP больше накладных расходов по гарантии доставки (через ретрансляцию) и заказа. UDP не предлагает ни гарантированную доставку, ни доставку по заказу. Если вы справитесь с ограничениями UDP, вы обнаружите, что он «быстрее», а если нет, то любая легкая оболочка TCP (из которых HTTP) примерно одинакова.

Answer 3

Большая разница между HTTP и JMS или XMPP заключается в том, что JMS и XMPP позволяют асинхронный запускать и забывать обмен сообщениями (когда клиент на самом деле не знает, когда и если сообщение достигнет своего назначения, и не ожидает ответ или подтверждение от получателя). Это позволило бы первому приложению быстро реагировать независимо от времени обработки второго приложения.

Асинхронный обмен сообщениями обычно предпочтителен для распределенных сообщений большого объема, где потребители сообщений медленнее, чем производители. Я не могу сказать, точно ли это ваш случай.

Answer 4

Если у вас есть полный контроль, и два веб-приложения работают в одном веб-контейнере и, следовательно, в одной и той же JVM, я бы предложил использовать JNDI, чтобы оба веб-приложения могли получить доступ к общей структуре данных (список?), Который позволяет одновременное изменение, а именно, чтобы приложение A могло добавлять новые записи, а приложение B одновременно использовать самые старые записи.

Скорее всего, это самый быстрый способ.

Обратите внимание, что вы должны хранить информацию, которую вы помещаете в список, для классов, найденных в JRE, иначе вы, скорее всего, столкнетесь с исключениями приведения классов. Их можно обойти, но проще всего просто передать строки в общей структуре данных.