Python Asynchronous IO: Concepts and History

En programación, a menudo nos encontramos con el concepto de "concurrencia", para permitir que el software haga un uso completo de los recursos de hardware y mejore el rendimiento. Hay muchas formas de concurrencia, multiproceso, multiproceso, IO asíncrono, etc. Los subprocesos múltiples y los procesos múltiples son más aplicables a los escenarios de uso intensivo de la CPU. Por ejemplo, el tiempo de la computación científica se gasta en la CPU y las CPU de varios núcleos se utilizan para compartir tareas informáticas. El cambio de escena y la comunicación entre subprocesos múltiples y procesos múltiples es muy costoso, y no es adecuado para escenarios de IO intensivos (las características de los subprocesos múltiples y los procesos múltiples están fuera del alcance de este artículo, y los estudiantes interesados ​​pueden buscar su propia comprensión). La E / S asíncrona es muy adecuada para escenarios de IO intensivos, como los rastreadores web y los servicios web.

En los programas de computadora, IO es la operación de leer y escribir discos y leer y escribir redes. Esta velocidad de lectura y escritura es mucho más lenta que la memoria de lectura y escritura y la memoria caché de la CPU. La primera consume miles de veces o más de esta última. Esto se traduce en más del 99% del tiempo para que los escenarios intensivos de IO gasten en el tiempo de espera de IO. La E / S asíncrona es la forma de liberar la CPU de largas esperas. Esto puede mejorar enormemente la concurrencia del sistema de software que escribimos. Dicho software puede ser un rastreador web o un sistema intensivo de IO, como un servicio web.

Las ventajas de la IO asíncrona son obvias, y varios lenguajes han mejorado su eficiencia al implementar este mecanismo, y Python no es una excepción. Python ha experimentado dos y tres versiones principales de la transición. También hay un historial de cambios en el soporte de E / S asíncrono.

Python 2 asíncrono IO biblioteca

La era de Python 2 oficialmente no tiene soporte de E / S asíncrono, pero hay varias bibliotecas de terceros que implementan E / S asíncronas a través de eventos o bucles de eventos, que son:

• Twisted: es una biblioteca de red controlada por eventos
• Gevent: greenlet + libevent (más tarde libev o libuv). Gevents implementados a través de coroutines y bibliotecas de bucles de eventos (libev, libuv) son ampliamente utilizados.
• Tornado: Un framework web que soporta IO asíncronas. Yo mismo implementé IOLOOP.

Python 3 IO asíncrono oficial

Python 3.4 agregó la biblioteca asyncio, que le da a Python una biblioteca oficial que admite IO asíncrona. Esta biblioteca, la capa inferior es el bucle de eventos (EventLoop), la capa superior es la rutina y la tarea. Asyncio se ha mejorado desde la versión 3.4 a la última versión 3.7.

La base de asyncio al principio de Python 3.4 todavía está basada en el generador. Se implementa mediante el rendimiento de la sintaxis. Un decorador puede decorarse con un decorator @ asyncio.coroutine (en desuso) para definir una coroutine. Por ejemplo:

Python 3.5 introduce dos nuevas palabras clave, wait y async, para reemplazar @ asyncio.coroutine y ceder a admitir IO asíncronas desde el propio lenguaje. Esto hace que la programación asíncrona sea más concisa y la distinga de los generadores ordinarios.

Nota: el soporte para las coroutinas basadas en generadores ha quedado en desuso y se planea eliminar en Python 3.10. Por lo tanto, solo necesita usar async y esperar al escribir programas de IO asíncronos.

Python 3.7 se optimizó para agrupar API en API de alto nivel y API de bajo nivel.Echemos un vistazo al código a continuación y descubramos en qué se diferencia de lo anterior.

Excepto por reemplazar @ asyncio.coroutine por async y reemplazar el rendimiento por por esperar, el mayor cambio es que el código para eventloop se ha ido, solo uno async.run (). Esta es la mejora 3.7, la API relacionada con eventloop se clasifica en la API de bajo nivel, y la nueva introducción de run () como una API de alto nivel permite al desarrollador de la aplicación llamar sin tener que preocuparse por el eventloop. A menos que desee escribir bibliotecas asíncronas (como las bibliotecas asíncronas de MySQL) se tratará con eventloop.

Se debe tener en cuenta que async.run () se agregó recientemente en la versión 3.7 y se encuentra en el estado de la API provisional. La API provisional se refiere a una interfaz de programación de aplicaciones que se excluye intencionalmente de la garantía de compatibilidad con versiones anteriores de la biblioteca estándar. Si bien estas interfaces generalmente no cambian significativamente, siempre que estén marcadas como tentativas, es posible hacer cambios incompatibles con los anteriores (incluso eliminar la interfaz) si el desarrollador del núcleo determina que es necesario. Dichos cambios no son arbitrarios; esto solo es posible si se descubrió un defecto subyacente grave que no se consideró antes de que se agregara la API. Incluso para las API tentativas, los cambios incompatibles con versiones anteriores se consideran "soluciones finales": siempre que se identifique un problema, intente encontrar una solución compatible con versiones anteriores siempre que sea posible. Este proceso permite que la biblioteca estándar evolucione continuamente sin quedar atrapado por fallas de diseño problemáticas a largo plazo.

Desde el desarrollo anterior de asyncio, ha estado cambiando, 3.4, 3.5, 3.6, 3.7 tienen muchos cambios en detalle. Cuando vi la función run () de 3.7, también encontré que los reptiles escritos por nysan, hace 3.6 años, no eran tan elegantes.

Este cambio, por un lado, mejora el rendimiento y la facilidad de uso del propio asyncio, pero por otro lado aumenta el costo de aprendizaje para nuestros usuarios y el costo de la actualización de las actualizaciones de Python. Si se resiste a este cambio con una actitud negativa, puede aprender Golang, C ++ para implementar su programa, si lo recibe con una actitud positiva, puede dominar este cambio más rápidamente e implementar su cambio con gracia y eficiencia. El programa

Siempre que desee escribir problemas en Python, acepte y domine este cambio. De hecho, ese lenguaje no está cambiando, y esa tecnología no está avanzando. Como programador, solo tienes que aprender y avanzar constantemente.

Uvloop

Uvloop está escrito en Cython, una biblioteca de E / S asíncrona de alto rendimiento basada en el lenguaje C de libuv. El propio bucle de eventos de Asyncio está escrito en Python. Reemplazar el propio bucle de eventos de asyncio con uvloop puede ser más rápido. Y el uso es bastante simple: