Bueno, depende de cómo definas la concurrencia.
En el software del lado del servidor, la concurrencia y el paralelismo a menudo se consideran conceptos diferentes. En un servidor, admitir E/S concurrentes significa que el servidor puede servir a varios clientes ejecutando varios flujos correspondientes a esos clientes con una sola unidad de cómputo. En este contexto, el paralelismo significaría que el servidor puede realizar varias cosas al mismo tiempo (con múltiples unidades de cómputo), lo cual es diferente.
Por ejemplo, un cantinero puede atender a varios clientes mientras que solo puede preparar una bebida a la vez. Para que pueda proporcionar concurrencia sin paralelismo.
Esta pregunta ha sido debatida aquí:¿Cuál es la diferencia entre concurrencia y paralelismo?
Vea también esta presentación de Rob Pike.
Un programa de subproceso único definitivamente puede proporcionar simultaneidad en el nivel de E/S mediante el uso de un mecanismo de (des)multiplexación de E/S y un bucle de eventos (que es lo que hace Redis).
El paralelismo tiene un costo:con los múltiples sockets/múltiples núcleos que puede encontrar en el hardware moderno, la sincronización entre subprocesos es extremadamente costosa. Por otro lado, el cuello de botella de un motor de almacenamiento eficiente como Redis suele ser la red, mucho antes que la CPU. Por lo tanto, los bucles de eventos aislados (que no requieren sincronización) se consideran un buen diseño para construir servidores eficientes y escalables.
El hecho de que las operaciones de Redis sean atómicas es simplemente una consecuencia del bucle de eventos de subproceso único. El punto interesante es que la atomicidad se proporciona sin costo adicional (no requiere sincronización). El usuario puede aprovecharlo para implementar el bloqueo optimista y otros patrones sin pagar los gastos generales de sincronización.
