TL;RD :Un solo subproceso hace que redis sea más simple, y redis aún está vinculado a IO.
La memoria es E/S. Redis todavía está vinculado a E/S. Cuando redis está bajo una gran carga y alcanza el máximo de solicitudes por segundo, generalmente carece de ancho de banda de red o ancho de banda de memoria, y generalmente no usa gran parte de la CPU. Hay ciertos comandos para los que esto no será cierto, pero para la mayoría de los casos de uso, redis estará severamente limitado por la E/S de la red o la memoria.
A menos que las velocidades de la memoria y la red de repente sean mucho más rápidas, ser de un solo subproceso no suele ser un problema. Si necesita escalar más allá de uno o unos pocos subprocesos (es decir, maestro<->esclavo<->configuración de esclavo), ya está buscando Redis Cluster. En ese caso, puede configurar una instancia de clúster por núcleo de CPU si de alguna manera tiene hambre de CPU y desea maximizar la cantidad de subprocesos.
No estoy muy familiarizado con la fuente o los componentes internos de Redis, pero puedo ver cómo el uso de un solo subproceso facilita la implementación de acciones atómicas sin bloqueo. Los subprocesos harían esto más complejo y no parece ofrecer grandes ventajas ya que redis no está vinculado a la CPU. La implementación de la simultaneidad en un nivel superior a una instancia de redis parece una buena solución, y es en lo que ayudan Redis Sentinel y Redis Cluster.
¿Qué sucede con otras solicitudes cuando Redis tarda mucho tiempo?
Esas otras solicitudes se bloquearán mientras redis completa la solicitud larga. Si es necesario, puede probar esto usando client-pause comando.
