[Pregunta diaria de conocimiento de JAVA]: ¿Por qué Redis 6.0 introdujo subprocesos múltiples?

prefacio

Redis lanzó oficialmente la versión 6.0 en mayo de 2020, que ofrece muchas funciones nuevas e interesantes, por lo que ha atraído mucha atención.

¿Qué características proporciona? ¿Sabes si puedo conseguir un aumento?

Las características principales son las siguientes:

1. Procesamiento multihilo de E/S de red;
2. caché del cliente;
3. Control de permisos detallado (ACL);
4. RESP3Uso del Acuerdo;
5. Los archivos RDB utilizados para la replicación ya no son útiles y se eliminarán de inmediato;
6. Los archivos RDB se cargan más rápido;

Entre ellos, el " modelo de subprocesos múltiples + caché de cliente " es el que más preocupa. Solo dominando los principios de las nuevas características podemos juzgar cuándo usar la versión 6.0 y cómo usarla mejor y más rápido sin pisar el foso.

Este artículo comienza con el modelo de subprocesos múltiples de Redis , y en cuanto al almacenamiento en caché del lado del cliente, etc., y escuche la siguiente descomposición.

Finalmente, haga clic en la tarjeta a continuación para seguir "Código Brother Byte" para obtener un aumento.

¿Por qué Redis 6.0 no usó subprocesos múltiples?

Respuesta oficial:

• Cuando se usa Redis, casi no hay situación en la que la CPU se convierta en el cuello de botella, y Redis está limitado principalmente por la memoria y la red.
• En un sistema Linux normal, Redis pipeliningpuede manejar 1 millón de solicitudes por segundo usándolo, por lo que si la aplicación usa principalmente comandos O(N) u O(log(N)), apenas requiere mucha CPU.
• Después de usar un solo hilo, la mantenibilidad es alta. Aunque el modelo de subprocesos múltiples es excelente en algunos aspectos, introduce la incertidumbre del orden de ejecución del programa, trae una serie de problemas de lectura y escritura concurrentes, aumenta la complejidad del sistema y puede tener cambios de subprocesos e incluso bloqueos. por desbloqueo y interbloqueo.

Redis tiene un rendimiento de procesamiento muy alto a través del modelo de eventos AE y la multiplexación de E/S, por lo que no es necesario utilizar subprocesos múltiples.

El mecanismo de subproceso único reduce en gran medida la complejidad de la implementación interna de Redis. Los comandos perezosos Rehash, Lpush y otros comandos "inseguros" de Hash se pueden ejecutar sin bloqueos .

¿El subproceso único antes de Redis 6.0 significa que Redis solo tiene un subproceso para trabajar?

No, cuando Redis procesa la solicitud del cliente, incluida la adquisición (lectura de socket), análisis, ejecución, devolución de contenido (escritura de socket), etc., es procesada por un subproceso principal serial secuencial, que es el llamado "subproceso único". .

En la etapa de ejecución de comandos, dado que Redis procesa los comandos en un solo subproceso, todos los comandos que llegan al servidor no se ejecutarán de inmediato y todos los comandos ingresarán a una cola de socket. Cuando el socket sea legible, se entregará al único -despachador de eventos subprocesos uno por uno.

Además, algunas operaciones de comando se pueden realizar con subprocesos o subprocesos en segundo plano (p. ej., eliminación de datos, generación de instantáneas, reescritura de AOF).

El código es antiguo y húmedo, entonces, ¿por qué Redis 6.0 introduce subprocesos múltiples?

Con la mejora del rendimiento del hardware, el cuello de botella de rendimiento de Redis puede aparecer en la lectura y escritura de E/S de la red, es decir, la velocidad de lectura y escritura de la red de procesamiento de un solo subproceso no puede seguir el ritmo de la velocidad del hardware de red subyacente .

Las llamadas del read/writesistema ocupan la mayor parte del tiempo de la CPU durante la ejecución de Redis. El cuello de botella es principalmente el consumo de E/S de la red. Hay dos direcciones principales para la optimización:

• Para mejorar el rendimiento de E/S de la red, implementaciones típicas como el uso DPDKpara reemplazar la pila de red del kernel.
• Use subprocesos múltiples para aprovechar al máximo los núcleos múltiples, mejore el paralelismo de la lectura y escritura de solicitudes de red, implementaciones típicas como Memcached.

Agregar soporte para la pila de protocolos de red en modo usuario requiere modificar las partes relacionadas con la red del código fuente de Redis (por ejemplo, modificar todas las funciones de solicitud de envío y recepción de la red), lo que generará una gran carga de trabajo de desarrollo.

Y el nuevo código también puede introducir nuevos errores, lo que provocaría inestabilidad en el sistema.

Por lo tanto, Redis usa varios subprocesos de E/S para procesar solicitudes de red para mejorar el paralelismo del procesamiento de solicitudes de red.

Cabe señalar que el modelo de subprocesos multi-IO de Redis solo se usa para procesar solicitudes de lectura y escritura de red. Para los comandos de lectura y escritura de Redis, sigue siendo un procesamiento de un solo subproceso .

Esto se debe a que el procesamiento de la red suele ser el cuello de botella, y el rendimiento se puede mejorar mediante el procesamiento paralelo de subprocesos múltiples.

Continuar usando un único subproceso para ejecutar comandos de lectura y escritura no requiere el desarrollo de mecanismos de seguridad de subprocesos múltiples para garantizar secuencias de comandos Lua, transacciones, etc., y la implementación es más sencilla.

El diagrama de la arquitectura es el siguiente :

¿Cómo cooperan el subproceso principal y el multiproceso IO?

Como se muestra abajo:

Proceso principal :

1. El subproceso principal es responsable de recibir la solicitud de establecimiento de conexión, obtenerla y socketcolocarla en la cola de procesamiento de lectura de espera global;
2. El subproceso principal socketasigna ;
3. El subproceso principal se bloquea y espera a que el subproceso IO lea la socketfinalización ;
4. El subproceso principal ejecuta el comando de solicitud de Redis leído y analizado por el subproceso IO;
5. El subproceso principal bloquea y espera a que el subproceso IO reescriba el resultado de la socketejecución ;
6. El subproceso principal borra la cola global y espera las solicitudes posteriores del cliente.

Idea: Divida las tareas de lectura y escritura de E/S del subproceso principal en un conjunto de subprocesos independientes para el procesamiento, de modo que se puedan paralelizar tareas de lectura y escritura de múltiples sockets, pero el subproceso principal todavía ejecuta el comando Redis en serie.

¿Cómo habilitar multiproceso?

Los subprocesos múltiples en Redis 6.0 están deshabilitados de manera predeterminada y solo se usa el subproceso principal. Para habilitarlo, debe modificar el archivo de redis.confconfiguración : io-threads-do-reads yes.

El código es viejo y húmedo, ¿es mejor la cantidad de subprocesos?

Por supuesto que no. Con respecto a la configuración del número de subprocesos, hay una sugerencia oficial: se recomienda configurar la máquina de 4 núcleos en 2 o 3 subprocesos, se recomienda configurar la máquina de 8 núcleos en 6 subprocesos, y el número de subprocesos debe ser menor que el número de núcleos de la máquina.

El número de subprocesos no es tan grande como sea posible. Los funcionarios creen que más de 8 básicamente no tiene sentido.

Además, después de habilitar los subprocesos múltiples, también debe establecer la cantidad de subprocesos; de lo contrario, no tendrá efecto .

io-threads 4
1.

resumen y pensamiento

Con el rápido desarrollo de Internet, el tráfico en línea que debe procesar el sistema comercial de Internet es cada vez más grande. El modo de subproceso único de Redis hará que el sistema consuma mucho tiempo de CPU en la E/S de la red, reduciendo el rendimiento Para mejorar el rendimiento de Redis, es necesario Dos direcciones:

• Optimización de módulos de E/S de red
• Mejore la velocidad de lectura y escritura de la memoria de la máquina

Esto último depende del desarrollo del hardware, y por el momento no hay solución. Por lo tanto, solo podemos comenzar con lo primero, y la optimización de la E/S de la red se puede dividir en dos direcciones:

• Tecnología de copia cero o tecnología DPDK
• Aproveche los múltiples núcleos

defectos del modelo

El modelo de red de subprocesos múltiples de Redis no es en realidad un modelo estándar de Multi-Reactors/Master-Workers En el esquema de subprocesos múltiples de Redis, la tarea del subproceso de E/S es solo para leer y analizar el comando de solicitud del cliente a través del socket , pero no hay real para ejecutar el comando.

Todos los comandos del cliente aún deben volver al subproceso principal para su ejecución, por lo que la utilización de múltiples núcleos no es alta, y cada vez que el subproceso principal debe estar ocupado sondeando después de asignar tareas y esperando que todos los subprocesos de E/S completen las tareas. antes de continuar con otra lógica.

En mi opinión, la solución actual de subprocesos múltiples de Redis es más como una opción de compromiso: no solo mantiene la compatibilidad del sistema original, sino que también utiliza varios núcleos para mejorar el rendimiento de E/S.