2013-05-23 2 views
0

Я изучал Netty в течение последних дней, так как я пишу быстрый и жесткий HTTP-сервер, на котором должно быть много запросов, а реализация HTTP-сервера Netty довольно проста и выполняет эту работу.Async Netty HttpServer и HttpClient

Мой следующий шаг является частью обработки запроса, мне нужно запустить HTTP-запрос на внешний веб-сервер. Моя интуиция заключается в том, чтобы реализовать асинхронный клиент, который может отправлять много запросов одновременно, но я немного запутался, так как это правильный подход. Я понимаю, что сервер Netty использует рабочий поток для каждого входящего сообщения, поэтому рабочий поток не будет освобожден, чтобы принимать новые сообщения, пока мой обработчик не завершит свою работу. Вот пробой: даже если у меня есть асинхронный HTTP-клиент в руке, не имеет значения, нужно ли ждать каждого ответа и обрабатывать его с помощью моего обработчика сервера - тот же рабочий поток будет блокироваться все это время. Альтернативой является использование асинхронного характера клиента, быстрое возвращение будущего объекта для освобождения потока и размещение слушателя (что означает, что мне нужно вернуть статус клиента 200 или 202) и проверить мой будущий объект, чтобы указать, когда ответ и я могу нажать его клиенту.

Имеет ли это смысл? Неужели я согласен с моими предположениями? Какова хорошая практика для внедрения такого типа сервера-приемника Netty + внешнего клиента с высокой параллелизмом?

Спасибо,

ответ

2

Предполагая, что вы спрашиваете о Нетти 4.

Нетти сконфигурированы с ServerBootstrap будет иметь фиксированное количество рабочих потоков, которые он использует, чтобы принимать запросы и выполнять канал, например, так:

Two threads accepting/processing requests 
bootstrap.group(NioEventLoopGroup(2)) 

One thread accepting requests, two threads processing. 
bootstrap.group(NioEventLoopGroup(1), NioEventLoopGroup(1)) 

В вашем случае, у вас есть канал включает в себя кучу Http Codec декодирования/кодирования материала и собственный обработчик, который сам по себе делает запрос исходящего HTTP. Вы правы, что не хотите блокировать сервер принимать входящие запросы или декодировать входящее сообщение Http, и есть две возможности, которые вы можете сделать для смягчения этого, вы уже ударили по первому.

Во-первых, вы хотите использовать Netyn-клиент Async для выполнения исходящих запросов, чтобы слушатель записывал ответ на исходный канал запросов при возврате исходящего запроса. Это означает, что вы не блокируете и не ждите, что означает, что вы можете обрабатывать множество одновременных исходящих запросов, чем количество потоков, доступных для обработки этих запросов.

Во-вторых, вы можете иметь свой собственный пробег обработчика в своем собственном EventExecutorGroup, что означает, что она работает в отдельном ThreadPool от акцептора/HTTP кодека обработчики каналов, например так:

// Two separate threads to execute your outgoing requests.. 
EventExecutorGroup separateExecutorGroup new DefaultEventExecutorGroup(2); 

bootstrap.childHandler(new ChannelInitializer<SocketChannel>() { 
    @Override 
    public void initChannel(SocketChannel ch) { 
     ChannelPipeline pipeline = ch.pipeline(); 
     .... http codec stuff .... 
     pipeline.addLast(separateExecutorGroup, customHandler); 
    } 
}; 

Значение исходящие запросы дон 'h hog потоки, которые будут использоваться для приема/обработки входящих.

+0

Спасибо за ответ. С первым вариантом, когда ответ обрабатывается слушателем, какой пул потоков/потоков используется? И, со вторым вариантом, на самом деле я вижу, что могу выбрать линию между «критической/обязательной обработкой», которая блокирует, и другую логику, которую я не хочу блокировать, - которую можно обработать, как показывает пример. Правильно ли я понимаю? – user2413964

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