multithreading - con - redis sql
Redis tiene un solo subproceso, ¿cómo funciona la E/S simultánea? (2)
Tratando de comprender algunos conceptos básicos de Redis, me encontré con una publicación de blog interesante.
El autor dice:
Redis tiene un único subproceso con epoll / kqueue y escala indefinidamente en términos de concurrencia de E / S.
Con seguridad no entiendo bien todo el tema, porque encuentro esta afirmación desconcertante. Si un programa tiene un solo subproceso, ¿cómo hace algo al mismo tiempo? ¿Por qué es tan grande que las operaciones de Redis son atómicas, si el servidor tiene un único hilo de todos modos?
¿Alguien podría arrojar algo de luz sobre el tema?
Bueno, depende de cómo definas la concurrencia.
En el software del lado del servidor, la concurrencia y el paralelismo a menudo se consideran como conceptos diferentes. En un servidor, admitir E / S simultáneas significa que el servidor puede servir a varios clientes mediante la ejecución de varios flujos correspondientes a esos clientes con una sola unidad de cálculo. En este contexto, el paralelismo significa que el servidor puede realizar varias cosas al mismo tiempo (con múltiples unidades de cálculo), lo cual es diferente.
Por ejemplo, un camarero puede cuidar de varios clientes mientras que solo puede preparar una bebida a la vez. Entonces él puede proporcionar concurrencia sin paralelismo.
Esta pregunta ha sido debatida aquí: Concurrencia vs Paralelismo: ¿Cuál es la diferencia?
Ver también esta presentación de Rob Pike.
Un programa de subproceso único definitivamente puede proporcionar concurrencia en el nivel de E / S mediante el uso de un mecanismo de multiplexación de E / S (de) y un bucle de evento (que es lo que hace Redis).
El paralelismo tiene un costo: con los múltiples sockets / núcleos múltiples que puede encontrar en el hardware moderno, la sincronización entre los hilos 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. Los bucles de eventos aislados (que no requieren sincronización) se consideran, por lo tanto, como 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 ciclo de eventos de un solo hilo. El punto interesante es que la atomicidad se proporciona sin costo adicional (no requiere sincronización). Puede ser explotado por el usuario para implementar el bloqueo optimista y otros patrones sin tener que pagar por la sobrecarga de sincronización.
De acuerdo, Redis tiene un único subproceso a nivel de usuario, OTOH, todas las E / S asincrónicas son compatibles con los grupos de subprocesos del kernel y / o los controladores de dos niveles.
'' Concurrente '', para algunos, incluye la distribución de eventos de red a máquinas de estados de socket. Es de subproceso único, se ejecuta en un núcleo (a nivel de usuario), por lo que no me referiré a esto como concurrente. Otros difieren ..
'' escalar indefinidamente en términos de concurrencia de E / S '' es solo ser económico con la verdad. Pueden tener más confianza si dicen que ''puede escalar mejor que un hilo por cliente, siempre que los clientes no pidan demasiado'', aunque luego se sientan obligados a agregar ''volado por cargas pesadas con otras soluciones asíncronas''. que usan todos los núcleos en el nivel de usuario ''.