Prefacio
Solo una cabeza calva puede volverse más fuerte.
El texto se ha incluido en mi artículo seleccionado de GitHub, bienvenido a Star: https://github.com/ZhongFuCheng3y/3y
Mirando hacia atrás en mi introducción a WebFlux en el artículo anterior, si se recomienda a los estudiantes que no lo hayan leído que lean este artículo nuevamente, el artículo anterior requirió mucho de mi esfuerzo ~~
- WebFlux, que pueden entender los profanos, se ha perdido el
comienzo de la pérdida de sangre y otra imagen, el contenido depende de la edición:
Este artículo trata principalmente sobre algunas preguntas que tenía sobre WebFlux cuando era un principiante. Me pregunto si tiene alguna pregunta correspondiente cuando leyó el último artículo.
La principal motivación para aprender WebFlux esta vez es compartir en el grupo de la empresa y escribir un PPT. Los estudiantes que lo necesiten pueden obtenerlo respondiendo a "PPT" en mi cuenta oficial (Java3y).
1. Puede ser asincrónico y sin bloqueo, ¿por qué utilizar WebFlux?
Creo que los estudiantes que tienen conocimientos relevantes saben que Servlet 3.1 ya es compatible con el no bloqueo asincrónico.
Podemos implementar asincrónico en un grupo de subprocesos autosuficientes
- Para decirlo sin rodeos, el subproceso de Tomcat procesa la solicitud y luego distribuye la solicitud al subproceso de mantenimiento automático para su procesamiento, y el subproceso de solicitud de Tomcat devuelve
@WebServlet(value = "/nonBlockingThreadPoolAsync", asyncSupported = true)
public class NonBlockingAsyncHelloServlet extends HttpServlet {
private static ThreadPoolExecutor executor = new ThreadPoolExecutor(100, 200, 50000L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<>(100));
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
AsyncContext asyncContext = request.startAsync();
ServletInputStream inputStream = request.getInputStream();
inputStream.setReadListener(new ReadListener() {
@Override
public void onDataAvailable() throws IOException {
}
@Override
public void onAllDataRead() throws IOException {
executor.execute(() -> {
new LongRunningProcess().run();
try {
asyncContext.getResponse().getWriter().write("Hello World!");
} catch (IOException e) {
e.printStackTrace();
}
asyncContext.complete();
});
}
@Override
public void onError(Throwable t) {
asyncContext.complete();
}
});
}
}El diagrama de flujo es el siguiente:
Fuente de diagrama sin bloqueo asincrónico del ejemplo anterior:
- https://www.cnblogs.com/davenkin/p/async-servlet.html De forma
sencilla, también podemos utilizar la clase CompletableFuture proporcionada por JDK 8, que puede manejar cómodamente llamadas asincrónicas.
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
long t1 = System.currentTimeMillis();
// 开启异步
AsyncContext asyncContext = request.startAsync();
// 执行业务代码(doSomething 指的是处理耗费时间长的方法)
CompletableFuture.runAsync(() -> doSomeThing(asyncContext,
asyncContext.getRequest(), asyncContext.getResponse()));
System.out.println("async use:" + (System.currentTimeMillis() - t1));
}Cuando se trata de lógica compleja, ya sea una devolución de llamada o CompletableFuture, el código es más complicado (el código es grande y no es fácil de entender), y WebFlux usa el flujo reactivo de Reactor, que proporciona una serie de API para que vayamos. La lógica de procesamiento es muy conveniente.
El infierno de devolución de llamada es
más importante:
- WebFlux se puede utilizar como SpringMVC, lo que puede reducir en gran medida el costo de aprendizaje
- WebFlux también se puede programar utilizando Functional Endpoints. En términos generales, es más conciso y más fácil de escribir que la devolución de llamada / CompletableFuture.
Vale la
pena mencionar el uso técnico sin problemas con SpringMVC :
Si el contenedor web usa Tomcat, entonces usa el servlet async api puenteado por Reactor.
Si el contenedor web es Netty, entonces usa Netty. La
recomendación oficial es usar Netty para ejecutar WebFlux.
2. Problemas de rendimiento de WebFlux
Descubrimos en el último artículo que el navegador llama a la interfaz de procesamiento lento, sin importar si la interfaz es síncrona o asincrónica, el tiempo para volver al navegador es el mismo.
- Sincronización: cuando el servidor recibe la solicitud, un hilo procesará la solicitud hasta que la solicitud se procese y se devuelva al navegador.
- Asíncrono: cuando el servidor recibe la solicitud, un subproceso procesará la solicitud, y luego se asignará otro subproceso para procesar la solicitud, y el subproceso solicitado será gratuito.
El sitio web oficial también dijo:
Los reactivos y sin bloqueo generalmente no hacen que las aplicaciones se ejecuten más rápido
Las ventajas de utilizar sin bloqueo asincrónico son:
El beneficio clave esperado de reactivos y sin bloqueo es la capacidad de escalar con una cantidad pequeña y fija de subprocesos y menos memoria, lo que hace que las aplicaciones sean más resistentes bajo carga, porque escalan de una manera más predecible.
Beneficio: Solo es necesario iniciar una pequeña cantidad de expansión de subprocesos en el programa, en lugar de horizontalmente a través de la expansión del clúster. La asincronía puede evitar la acumulación de subprocesos causada por la congestión de E / S de archivos / E / S de red.
Echemos un vistazo a la comparación del rendimiento y el tiempo de respuesta entre el bloqueo síncrono y el no bloqueo asincrónico para el mismo volumen de solicitud:
Nota de comparación de rendimiento y RT :
- Cuando el volumen de solicitudes no es grande (alrededor de 3000), el bloqueo sincrónico de solicitudes de procesamiento de subprocesos múltiples, el rendimiento y el tiempo de respuesta no se quedan atrás. (De acuerdo con la verdad, WebFlux todavía puede estar atrasado, después de todo, tiene que hacer un procesamiento más -> la solicitud se delega a otro hilo para su procesamiento
- Cuando el volumen de solicitudes es grande, la cantidad de subprocesos no es suficiente y el bloqueo síncrono (MVC) solo puede esperar, por lo que el rendimiento disminuirá y el tiempo de respuesta aumentará (cola).
Cuando Spring WebFlux responde a solicitudes altamente concurrentes, con la ayuda de E / S asincrónicas, puede procesar solicitudes de mayor rendimiento con una pequeña cantidad de subprocesos estables, especialmente cuando el proceso de procesamiento de solicitudes es largo debido a la complejidad del negocio o al bloqueo de E / S. , El contraste es más significativo.
Tres, la aplicación real de WebFlux
WebFlux requiere un código comercial sin bloqueo. Si está bloqueado, debe abrir un grupo de subprocesos para ejecutarlo. ¿En qué escenarios puede WebFlux reemplazar SpringMVC?
- Quiere escenarios con menos memoria e hilos
- Escenarios en los que la red es lenta o ocurren con frecuencia problemas de E / S
SpringMVC y WebFlux son más una relación complementaria que un reemplazo. En el escenario de bloqueo, SpringMVC sigue siendo SpringMVC, y no es que SpringMVC sea reemplazado por WebFlux.
Si SpringMVC y WebFlux quieren ejercer el rendimiento de WebFlux, necesitan pasar de Dao a Service, todos los cuales son Mono y Flux. En la actualidad, la capa de datos oficial Reactive framework solo es compatible con Redis, Mongo, etc., sin JDBC.
Actualmente, para las bases de datos relacionales, el equipo de Pivotal tiene R2DBC (conectividad reactiva de bases de datos relacionales) de código abierto, y su dirección de GitHub es:
-
https://github.com/r2dbc
Actualmente, R2DBC admite tres fuentes de datos: - PostgreSQL
- H2
En general, Microsoft SQL Server , debido a que WebFlux responde, debe cambiar el código para que responda si desea aprovechar el rendimiento de WebFlux. Actualmente, JDBC no es compatible (al menos MySQL no lo admite) y la respuesta Los programas formales no son fáciles de depurar y escribir (en comparación con los programas síncronos), por lo que los escenarios de aplicación de WebFlux son todavía relativamente pocos.
Por lo tanto, creo que es más apropiado usar WebFlux en la capa de puerta de enlace (originalmente era un escenario con más E / S de red)
Ahora vuelve y mira las fotos del sitio web oficial de Spring, ¿no es más cordial?
Materiales de referencia del mapa de introducción del sitio web oficial de Spring :
- https://blog.lovezhy.cc/2018/12/29/webflux problemas de rendimiento
4. ¿Es necesario aprender el modo de programación Functional Endpoints?
Como se mencionó anteriormente, WebFlux nos proporciona dos modos de uso, uno es SpringMVC anotado, el otro se llama Functional Endpoints
Lambda-based, lightweight, and functional programming modelEn general, se trata de utilizar WebFlux con Lambda y programación de streaming. Si me preguntas: ¿es necesario aprender? De hecho, creo que se puede dejar primero. Creo que todavía hay relativamente pocos escenarios de aplicación para WebFlux, y no es difícil saber cuándo se usa realmente. De todos modos, es solo para aprender algunas API ~
Con la base de la expresión Lambda y Stream, no es un problema aprender cuándo realmente lo usa ~
El siguiente es un ejemplo del uso de WebFlux a través de anotaciones:
Uso de WebFlux a través de anotaciones El
siguiente es un ejemplo del uso de WebFlux a través de puntos finales funcionales:
Distribuidor de ruta, equivalente a la anotación GetMapping ...
El distribuidor de enrutamiento
UserHandler es equivalente a UserController:
UserHanler
Al final
- ~~
La principal motivación para aprender WebFlux esta vez es compartir en el grupo de la empresa y escribir un PPT. Los estudiantes que lo necesiten pueden obtenerlo respondiendo a "PPT" en mi cuenta oficial (Java3y).
¡Dos años de artículos minuciosos: "Preguntas de la entrevista", "Conceptos básicos" y "Avanzado" están aquí!
Más de 300 artículos originales artículos técnicos
recursos de video masivos
mapa mental exquisito
preguntas de la cara
prensa escanear código puede estar preocupado por obtener
ver y compartir es muy importante para mí! 
No es fácil de crear. Tu apoyo y reconocimiento es la mayor motivación para mi creación. ¡Nos vemos en el próximo artículo! Busca me gusta y atención️ Busca compartir y quedarte