Методология программирования на Java — Spring WebFlux 01 Зачем вам нужен Spring WebFlux

Java

предисловие

Эта серия статей посвящена моей методологии программирования на Java. Серия Responsive InterpretationWebfluxЧасть, теперь совместно используемая, предварительная информация Rxjava2, соответствующая интерпретация Reactor была записана и передана видео, и опубликована на станции b, адрес выглядит следующим образом:

Интерпретация исходного кода Rxjava и совместное использование:вооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо

Интерпретация и совместное использование исходного кода Reactor:вооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо

Обмен видео, связанный с интерпретацией исходного кода NIO:вооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо

Статьи, связанные с видеоинтерпретацией исходного кода NIO:

Некоторые сведения об исходном коде BIO to NIO BIO

Некоторые сведения об исходном коде BIO to NIO на NIO

Некоторые сведения об исходном коде BIO to NIO в NIO

Некоторые вещи из BIO в исходный код NIO: Селектор под NIO Некоторые вещи из исходного кода BIO в NIO в разделе NIO Buffer Interpretation on Некоторые вещи из исходного кода BIO в NIO в разделе NIO Buffer Interpretation Next

Среди них Rxjava и Reactor не будут открыты для публики как содержание моей книги.Если вам интересно, вы можете уделить немного времени просмотру видео.Я сделал всестороннюю и подробную интерпретацию двух библиотек, включая концепции дизайна и связанная с ними методология.Я также надеюсь, что вы можете оставить сообщение, чтобы исправить мои ошибки.

Зачем вам нужен Spring WebFlux

Поскольку мы сталкиваемся со все более высокой параллельной обработкой, традиционныеSpring Web MVCОн не смог удовлетворить наши потребности, то есть нам нужен неблокирующий и через небольшое количество аппаратных ресурсов (вариант через небольшое количество потоков)webФреймворк для обработки параллельных задач.Servlet 3.1Он предоставляет соответствующий API для неблокирующего ввода-вывода. Однако при его использовании остальная часть API сервлета синхронна во время выполнения (например,Filter) или блокировка (getParameter,getPart). мы знаем,TomcatТакие серверы имеютServlet Workerпул потоков при использованииSpring Web MVC, обработка запроса будет вDispatcherServletпроцесс, и его внутреннее значение по умолчанию не выполняет асинхронную обработку, поэтому, когдаI/OИли, когда операция занимает много времени, она может заблокировать текущийServletна нитке. (См. в Интернете оSpringMVCСвязанные сообщения в блоге об асинхронных операциях), о его асинхронном преобразовании, я такжеRxJava2Соответствующее совместное видео примера проекта было преобразовано, и вы можете просмотреть его. Наша цель - принести актуальноеServletПоток, в котором он находится, прекращается, чтобы можно было получить больше запросов. В чем разница между ними?Spring WebFluxКакой смысл для нас передавать обучение. Я считаю, что все были в контакте сTomcatПосле этого я научусьTomcatфайл конфигурацииserver.xml, откуда мы также знаемConnector, его основными функциями являются: получение запросов на подключение, созданиеRequestиResponseОбъект используется для обмена данными с запросчиком; затем назначается поток, чтобы разрешитьServletконтейнер для обработки этого запроса и размещения полученногоRequestиResponseобъект переданServlet. когдаServletПосле обработки запроса он также пройдетConnectorВерните ответ клиенту. Итак, мы начинаем сConnectorдля начала обсудите некоторыеConnectorсопутствующие вопросы, в том числеNIO/BIOРежим, пул потоков, количество подключений и т. д. В зависимости от соглашения,ConnectorЕго можно разделитьHTTP Connector,AJP Connectorподождите, здесь только обсуждаетсяHTTP Connector.

Протокол в соединителе под Tomcat

ConnectorПри обработке HTTP-запросов различныеprotocol. разныеTomcat版本поддерживаетсяprotocolразные, где типичныеprotocolвключаютBIO、NIO和APR(Tomcat7поддержите это3своего рода,Tomcat8добавленNIO2поддержку, находясь вTomcat8.5иTomcat9.0, затем удалите правуюBIOслужба поддержки).

Connectorчто использоватьprotocol, в состоянии пройтиTomcatконфигурационный файлserver.xmlсередина<connector>в элементеprotocolможно указать свойства или использовать значения по умолчанию. Если не указаноprotocol, используется значение по умолчаниюHTTP/1.1, его смысл следующий:Tomcat7, он автоматически выбирается для использованияBIOилиAPR(если найденоAPRнеобходимая нативная библиотека, используйтеAPR, иначе используйтеBIO);существуетTomcat8, он автоматически выбирается для использованияNIOилиAPR(если найденоAPRнеобходимая нативная библиотека, используйтеAPR, иначе используйтеNIO).

Будь тоBIO,все ещеNIO,ConnectorОбщий алгоритм обработки запроса такой же:Получить соединение в очередь принятия (когда клиент отправляет запрос на сервер, если клиент и сервер завершают трехэтапное рукопожатие для установления соединения, сервер помещает соединение в очередь принятия); получить запрошенные данные в соединении сгенерировать запрос; вызвать контейнер сервлетов для обработки запроса; вернуть ответ.

Чтобы облегчить ваше понимание, вот связь между соединением и запросом:

  • соединениеTCPслой (транспортный слой), соответствующийsocket.
  • запросHTTPуровень (прикладной уровень), должен зависеть отTCPреализация соединения.
  • ОдинTCPВ соединении может быть несколько передачHTTPпросить.

BIO — это Blocking IO, как видно из названия, блокирующий IO; NIO — это Non-blocking IO, то есть неблокирующий IO. APR — это Apache Portable Runtime, переносимая библиотека времени выполнения Apache, которая может обеспечить высокую масштабируемость и высокую производительность за счет использования локальных библиотек; Apr — это предпочтительный режим для запуска приложений с высокой степенью параллелизма на Tomcat, но apr, apr-utils, tomcat должны быть установлены -native и другие пакеты.

существуетBIOосуществленныйConnector, запрос в основном делаетсяJioEndpointобъект для обработки.JioEndpointподдерживаетсяAcceptorиWorker,пройти черезAcceptorперениматьsocket, то изWorker线程池Найти обработку холостого потока вsocket,еслиworker线程池нет незанятых потоков, тоAcceptorзаблокирует. вWorkerдаTomcatАвтономный пул потоков, если он передан<Executor>Другие пулы потоков настраиваются, принцип тот же, что иWorkerпохожий.

существуетNIOосуществленныйConnector, основным объектом, обрабатывающим запрос, являетсяNIOEndpointобъект.NIOEndpointПомимо включенияAcceptorиWorkerКроме того, до сих пор используетсяPoller, поток обработки показан на следующем рисунке:

на фотоAcceptorиWorkerОни существуют в виде пулов потоков соответственно.PollerЯвляется одним потоком (вот его самое большое отличие от Netty). Обратите внимание, что сBIOреализации того же, здесь необходимо упомянуть, что вserver.xmlне настроен в<Executor>, затем сWorker线程池запустить, если настроено<Executor>, то исходя изjava.util.concurrent.ThreadPoolExecutorПул потоков работает.

На рисунке показано,AcceptorперениматьsocketПосле (здесь, правда, исходя изNIOизconnector, Но получаяsocketвсе еще традиционныйserverSocket.accept()способ получитьSocketChannelобъект, затем инкапсулированный вtomcatизorg.apache.tomcat.util.net.NIOChannelРеализуйте объект класса и оберните его какPollerEvent对象), не напрямуюWorkerНить в процессе запроса, но сначалаPollerEvent对象отправлено вPollerPollerреализуетсяNIOключ.AcceptorВ направленииPollerОтправить包装后的请求Реализовано путем добавления операции очереди, используется типичный узор потребительского производителя. В то же время вPoller, поддерживаетSelectorобъект; когдаPollerудалить из очередиsocketпосле регистрации вSelectorв; затем, пройдяSelector, выяснить, какие читаемыеsocketи использоватьWorkerПотоки обрабатывают соответствующий запрос. иBIOпохожий,WorkerЕго также можно заменить настраиваемым пулом потоков.

Из вышеописанного процесса видно, чтоNIOEndpointВо время обработки запроса либоAcceptorперениматьsocketили поток запроса (добавлено вPollerОчередь синхронная), по-прежнему используется режим блокировки, но в读取socket并交给Worker中的线程этого процесса, используйте неблокирующийNIOосознать, что этоNIOузор сBIOОсновное различие между режимами (другие отличия меньше влияют на производительность). И из-за этой разницы он может значительно повысить эффективность Tomcat в случае большого количества параллелизма.

Большая часть текущегоHTTPЗапрос использует постоянное соединение (HTTP/1.1дефолтkeep-aliveзаtrue), а длинное соединение означает, чтоTCPизsocketПосле завершения текущего запроса, если не приходит новый запрос,socketСразу не выпустит, а подождетtimeoutснова отпустить. При использованииBIO,读取socket并交给Worker中的线程Этот процесс является блокирующим, что означает, что вsocketВ ожидании следующего запроса или в ожидании релиза обработайте этоsocketРабочие потоки Tomcat всегда будут заняты и не могут быть освобождены, поэтому количество сокетов, которые Tomcat может обрабатывать одновременно, не может превышать максимальное количество потоков, а производительность сильно ограничена. При использовании NIO,读取socket并交给Worker中的线程Этот процесс является неблокирующим (поPollerОн поддерживается тем потоком, в котором находится, и не занимает рабочий поток, поэтому Tomcat может обрабатывать его одновременно.socketЭто число не ограничивается максимальным числом потоков, а одновременная производительность значительно повышается, ноPollerЭто также является узким местом его производительности.

Следовательно, сNIOосуществленныйConnectorС появлением , связь между клиентом и сервером не блокируется, но сервер сservletСоединение по-прежнему блокируется, что означает, что каждый запрос блокирует поток, что приводит к модели, в которой мы видим, что один поток обрабатывает один запрос. Следовательно, сServletразработка контейнеров,Servlet APIТакже требуется неблокирующая поддержка, т.е.Servlet 3.1+.

оTomcatВнизConnectorДля более глубокой интерпретации, если вам интересно, вы можете обратиться к другому моему сообщению в блоге.Две или три вещи от tomcat, начиная с подключения к Servlet