Este es un artículo del mundo Python, pero sigue siendo aplicable a todo el campo de la programación, aunque el multihilo nos permite procesar solicitudes más rápido, pero también hay un techo, los hilos verdes (micro-hilos) son la solución.
El desarrollo de software multihilo resuelve numerosos problemas, especialmente para aplicaciones centradas en redes que requieren un rendimiento exigente para responder rápidamente a los usuarios. Desafortunadamente, el multihilo no es suficiente para resolver problemas a gran escalaConcurrenciaproblemas sexuales.
Abordar estos problemas requiere cambiar los modelos de programación, utilizando eventos asíncronos y mecanismos basados en callback. En Druva, creamos una biblioteca basada en Python llamada Dhaga para resolver a gran escalaConcurrencia, mientras que el modelo de programación no requiere cambios significativos.
Los desarrolladores de software viven en unoConcurrenciamundo. Los hilos son ciudadanos de primera clase hoy en día, especialmente durante el desarrollo, especialmente cuando tu aplicación realiza operaciones intensivas de red, como el sistema inSync (producto de sincronización de seguridad de red) como Druva. El multihilo facilita y ordena el flujo del código de programación para operaciones de red. Cuando nuestra aplicación necesita mejoras o mejoras en el rendimiento, puede mejorarseElasticidad, podemos aumentar el número de hilos.
Pero cuando se trata de miles de escalasConcurrenciaLas peticiones ni los hilos no son suficientes.
Descubrimos que el multihilo tiene las siguientes desventajas:
1. El cliente del sistema inSync necesita hacer copias de seguridad de un gran número de archivos en el servidor mediante llamadas RPC en red. Una forma típica para que los desarrolladores aceleren las cosas es usar hilos. Sin embargo, el rendimiento que aporta el multihilo aumenta el coste de la memoria y la CPU; Los desarrolladores necesitan mantener un equilibrio entre velocidad y número de hilos.
2. Nuestros servidores deben gestionar entre el sistema inSync y miles de clientesConcurrenciaConexiones y notificaciones. Para gestionar las conexiones de forma eficiente, usamos hilos para gestionar las solicitudes. Pero el creciente número de clientes del sistema inSync también significa que tenemos que seguir aumentando el número de hilos, lo que consume mucha memoria del servidor y CPU.
3. Nuestro servidor web necesita gestionar miles de solicitudes HTTP en paralelo. La mayor parte del trabajo está en los sockets de red que reciben y envían datos y los pasan al backend del sistema inSync. Hace que la mayoría de los hilos esperen a las operaciones de red. Lo que causa el problema C10K es que, cuando hay miles de solicitudes síncronas al servidor web, generar un hilo para cada solicitud es bastante poco escalable (Scale).
Limitaciones de los marcos asíncronos
Muchos frameworks asíncronos, incluyendo Twisted, Tornado Tornado y asyncore, pueden ayudar a los desarrolladores a alejarse de las formas populares de usar hilos. Estos marcos se basan en sockets no bloqueantes y mecanismos de callback (similares a Node.js). Si usamos estos frameworks tal cual, las partes principales de nuestro código Druva tendrán que ser refactorizadas. Eso no es lo que queremos hacer. Refactorizar código aumenta los ciclos de desarrollo y pruebas, impidiéndonos cumplir con nuestros requisitos de escala. Dado que varias partes del producto deben ser enormes, cada uno de nosotros tendrá que refactorizarlas, de ahí el esfuerzo de duplicar o triplicar.
Para evitar cambiar tanto código, tuvimos que alejarnos de usar directamente el framework existente. Por suerte, encontramos algunas herramientas útiles.
Como queremos controlar la ejecución del código en la E/S de red, necesitamos una forma de dividir un hilo en microhilos. EncontramosPequeños。 Proporciona una programación no implícita de microhilos llamada cortina de corrutinas. En otras palabras. Es útil cuando quieres controlar tu código en ejecución. Puedes crear microhilos para agendas personalizadas porque puedes controlar cuándo los greenlets generan pausas. Esto es perfecto para nosotros porque nos da control total sobre la planificación de nuestro código.
Tornado es un framework de servidores web sencillo y sin bloqueos, escrito en Python, diseñado para gestionar miles de solicitudes asíncronas. Utilizamos su componente principal, IOLoop IOStream. IOLoop es un bucle de eventos de E/S de socket no bloqueante; Utiliza epoll (en Linux) o colas (BSD y Mac OS X), de lo contrario selecciona (en Windows) si están disponibles. IOStream proporciona zócalos no bloqueantes, como un empaquetado conveniente para la lectura y la escritura. Delegamos todas las operaciones de socket a Tornado y luego usamos callbacks para activar operaciones de código para completarlas (nota banq: muy similar a Node.js mecanismo).
Es un buen comienzo, pero necesitamos más. Si usamos el módulo anterior directamente en nuestro código, mucho de nuestro código RPC tendrá que cambiar, programando RPC a través de greenlets, asegurándonos de que los greenlets no bloqueen (si los greenlets se atastan, se obstruirá todo el hilo y todos los demás), gestionando las funciones de callback desde tornado.
Necesitamos una abstracción para gestionar y organizar los greenlets y evitar saturarlos con llamadas externas, y esta abstracción puede ser enormemente escalable más allá de los hilos. Esta abstracción es Dhaga, que permite programar el flujo de código de la aplicación como una secuencia síncrona tradicional, pero la ejecución es asincrónica.
Dhaga (del hindi, que significa hilo) es un framework de ejecución para un hilo ligero que abstraemos. La clase Dhaga deriva de greenlets y utiliza el cambio de pila para ejecutar múltiples flujos de código en un solo hilo del sistema operativo. Hilos de un sistema operativo ejecutan múltiples dhagas mediante planificación colaborativa. Siempre que un dhaga espera (principalmente esperando que devuelva una llamada RPC), cede el control al nivel padre (es decir, el contexto de ejecución del hilo a nivel operativo que lo creó). El nivel padre entonces programa otro dhaga para estar listo para ejecutarse. La llamada RPC se pasará al servidor web tornado para escribir el socket de forma asíncrona, y luego registrará una callback cuando regrese, y cuando este RPC regrese, el dhaga en espera se añadirá a la cola del ejecutable y luego será recogido por el hilo padre. (Nota Banq: similar a node.js principio)
Podemos usar Dhaga en lugar de hilos para operaciones de alta latencia, y usamos 512 dhagas en un solo hilo cuando el número de hilos supera un límite razonable de rendimiento.
|
Publicado en 6/12/2014 22:21:58
|
|
|
Publicado en 7/12/2014 17:22:55
