189 8069 5689
asyncio是官方提供的协程的类库，从python3.4开始支持该模块
创新互联公司长期为上1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为水城企业提供专业的成都做网站、网站建设，水城网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。
async awiat是python3.5中引入的关键字，使用async关键字可以将一个函数定义为协程函数，使用awiat关键字可以在遇到IO的时候挂起当前协程（也就是任务），去执行其他协程。
await + 可等待的对象（协程对象、Future对象、Task对象 - IO等待）
注意：在python3.4中是通过asyncio装饰器定义协程，在python3.8中已经移除了asyncio装饰器。
事件循环，可以把他当做是一个while循环，这个while循环在周期性的运行并执行一些协程（任务），在特定条件下终止循环。
loop = asyncio.get_event_loop()：生成一个事件循环
loop.run_until_complete(任务)：将任务放到事件循环
Tasks用于并发调度协程，通过asyncio.create_task(协程对象)的方式创建Task对象，这样可以让协程加入事件循环中等待被调度执行。除了使用 asyncio.create_task() 函数以外，还可以用低层级的 loop.create_task() 或 ensure_future() 函数。不建议手动实例化 Task 对象。
本质上是将协程对象封装成task对象，并将协程立即加入事件循环，同时追踪协程的状态。
注意：asyncio.create_task() 函数在 Python 3.7 中被加入。在 Python 3.7 之前，可以改用 asyncio.ensure_future() 函数。
下面结合async awiat、事件循环和Task看一个示例
示例一：
*注意：python 3.7以后增加了asyncio.run（协程对象），效果等同于loop = asyncio.get_event_loop()，loop.run_until_complete(协程对象) *
示例二：
注意：asyncio.wait 源码内部会对列表中的每个协程执行ensure_future从而封装为Task对象，所以在和wait配合使用时task_list的值为[func(),func()] 也是可以的。
示例三：
asyncio 是 Python 中的异步IO库，用来编写并发协程，适用于IO阻塞且需要大量并发的场景，例如爬虫、文件读写。
asyncio 在 Python3.4 被引入，经过几个版本的迭代，特性、语法糖均有了不同程度的改进，这也使得不同版本的 Python 在 asyncio 的用法上各不相同，显得有些杂乱，以前使用的时候也是本着能用就行的原则，在写法上走了一些弯路，现在对 Python3.7+ 和 Python3.6 中 asyncio 的用法做一个梳理，以便以后能更好的使用。
协程，又称微线程，它不被操作系统内核所管理，而完全是由程序控制，协程切换花销小，因而有更高的性能。
协程可以比作子程序，不同的是，执行过程中协程可以挂起当前状态，转而执行其他协程，在适当的时候返回来接着执行，协程间的切换不需要涉及任何系统调用或任何阻塞调用，完全由协程调度器进行调度。
Python 中以 asyncio 为依赖，使用 async/await 语法进行协程的创建和使用，如下 async 语法创建一个协程函数：
在协程中除了普通函数的功能外最主要的作用就是：使用 await 语法等待另一个协程结束，这将挂起当前协程，直到另一个协程产生结果再继续执行：
asyncio.sleep() 是 asyncio 包内置的协程函数，这里模拟耗时的IO操作，上面这个协程执行到这一句会挂起当前协程而去执行其他协程，直到sleep结束，当有多个协程任务时，这种切换会让它们的IO操作并行处理。
注意，执行一个协程函数并不会真正的运行它，而是会返回一个协程对象，要使协程真正的运行，需要将它们加入到事件循环中运行，官方建议 asyncio 程序应当有一个主入口协程，用来管理所有其他的协程任务：
在 Python3.7+ 中，运行这个 asyncio 程序只需要一句： asyncio.run(main()) ，而在 Python3.6 中，需要手动获取事件循环并加入协程任务：
事件循环就是一个循环队列，对其中的协程进行调度执行，当把一个协程加入循环，这个协程创建的其他协程都会自动加入到当前事件循环中。
其实协程对象也不是直接运行，而是被封装成一个个待执行的 Task ，大多数情况下 asyncio 会帮我们进行封装，我们也可以提前自行封装 Task 来获得对协程更多的控制权，注意，封装 Task 需要 当前线程有正在运行的事件循环 ，否则将引 RuntimeError，这也就是官方建议使用主入口协程的原因，如果在主入口协程之外创建任务就需要先手动获取事件循环然后使用底层方法 loop.create_task() ，而在主入口协程之内是一定有正在运行的循环的。任务创建后便有了状态，可以查看运行情况，查看结果，取消任务等：
asyncio.create_task() 是 Python3.7 加入的高层级API，在 Python3.6，需要使用低层级API asyncio.ensure_future() 来创建 Future，Future 也是一个管理协程运行状态的对象，与 Task 没有本质上的区别。
通常，一个含有一系列并发协程的程序写法如下（Python3.7+）：
并发运行多个协程任务的关键就是 asyncio.gather(*tasks) ，它接受多个协程任务并将它们加入到事件循环，所有任务都运行完成后会返回结果列表，这里我们也没有手动封装 Task，因为 gather 函数会自动封装。
并发运行还有另一个方法 asyncio.wait(tasks) ，它们的区别是：
协程函数：async def 函数名。3.5+
协程对象：执行协程函数()得到的协程对象。
3.5之后的写法：
3.7之后的写法：更简便
await后面 跟 可等待的对象。（协程对象，Future，Task对象 约等于IO等待）
await实例2：串行执行。 一个协程函数里面可以支持多个await ，虽然会串行，但是如果有其他协程函数，任务列表也在执行，依然会切换。只是案例中的main对应执行的others1和others2串行 。 await会等待对象的值得到之后才继续往下走。
C10k是一个在1999年被提出来的技术挑战,如何在一颗1GHz CPU,2G内存,1gbps网络环境下,让单台服务器同时为1万个客户端提供FTP服务
阻塞式I/O(使用最多)、非阻塞式I/O、I/O复用、信号驱动式I/O(几乎不使用)、异步I/O(POSIX的aio_系列函数)
select、poll、epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制,一个进程可以监听多个描述符,一旦，某个描述符就绪(一般是读就绪或者写就绪),能够通知程序进行相应的读写操作。但select、poll、epoll本质上都是同步I/O,因为他们都需要在读写时间就绪后负责进行读写,也就是说读写过程是阻塞的,而异步I/O无需自己负责进行读写,异步I/O的实现会负责把数据从内核拷贝到用户空间
(1)select
select函数监视的文件描述符分3类,分别是writefds、readfds、exceptfds。调用select函数会阻塞,直到有描述符就绪(有数据可读、可写或者有except),或者超时函数返回。当select函数返回后可以通过遍历fdset来找到就绪的描述符。
select目前几乎在所有的平台上支持,其良好的跨平台支持也是它的一个优点。select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制,在Linux上一般为1024,可以通过修改宏定义甚至重新编译内核的方式提升这一限制,但是这样也会降低效率。
(2)poll
不同于select使用三个位图来表示三个fdset的方式,poll使用一个pollfd的指针实现。
pollfd结构包含了要监视的event和发生的event,不再使用select"参数-值"传递的方式。同时pollfd并没有最大数量限制(但是数量过大后性能也会下降)。和select函数一样,poll返回后,需要轮询pollfd来获取就绪的描述符。
从上面看,select和poll都需要在返回后通过遍历文件描述符来获取已经就绪的socket。事实上同时连接的大量客户端在同一时刻可能只有很少的处于就绪的状态,因此随着监视的描述符数量的增长,其效率也会线性下降
(3)epoll
epoll是在2.6内核中提出的,是之前的select和poll的增强版本。相对于select和poll来说,epoll更加领灵活,没有描述符限制。epoll使用一个文件描述符管理多个描述符,将用户关系的文件描述符的事件存放到内核的一个事件表中,这样在用户空间和内核空间的copy只需一次。
在前面的例子里学习了并发地执行多个协程来下载图片，也许其中一个协程永远下载不了，一直阻塞，这时怎么办呢？
碰到这种需求时不要惊慌，可以使用wait()里的timeout参数来设置等待时间，也就是从这个函数开始运行算起，如果时间到达协程没有执行完成，就可以不再等它们了，直接从wait()函数里返回，返回之后就可以判断那些没有执行成功的，可以把这些协程取消掉。例子如下：
[python] view plain copy
import asyncio
async def phase(i):
print('in phase {}'.format(i))
try:
await asyncio.sleep(0.1 * i)
except asyncio.CancelledError:
print('phase {} canceled'.format(i))
raise
else:
print('done with phase {}'.format(i))
return 'phase {} result'.format(i)
async def main(num_phases):
print('starting main')
phases = [
phase(i)
for i in range(num_phases)
]
print('waiting 0.1 for phases to complete')
completed, pending = await asyncio.wait(phases, timeout=0.1)
print('{} completed and {} pending'.format(
len(completed), len(pending),
))
# Cancel remaining tasks so they do not generate errors
# as we exit without finishing them.
if pending:
print('canceling tasks')
for t in pending:
t.cancel()
print('exiting main')
event_loop = asyncio.get_event_loop()
try:
event_loop.run_until_complete(main(3))
finally:
event_loop.close()
结果输出如下：
starting main
waiting 0.1 for phases to complete
in phase 0
in phase 2
in phase 1
done with phase 0
1 completed and 2 pending
canceling tasks
exiting main
phase 1 canceled
phase 2 canceled
改进之前
之前，我的查询步骤很简单，就是：
前端提交查询请求 -- 建立数据库连接 -- 新建游标 -- 执行命令 -- 接受结果 -- 关闭游标、连接
这几大步骤的顺序执行。
这里面当然问题很大：
建立数据库连接实际上就是新建一个套接字。这是进程间通信的几种方法里，开销最大的了。
在“执行命令”和“接受结果”两个步骤中，线程在阻塞在数据库内部的运行过程中，数据库连接和游标都处于闲置状态。
这样一来，每一次查询都要顺序的新建数据库连接，都要阻塞在数据库返回结果的过程中。当前端提交大量查询请求时，查询效率肯定是很低的。
第一次改进
之前的模块里，问题最大的就是第一步——建立数据库连接套接字了。如果能够一次性建立连接，之后查询能够反复服用这个连接就好了。
所以，首先应该把数据库查询模块作为一个单独的守护进程去执行，而前端app作为主进程响应用户的点击操作。那么两条进程怎么传递消息呢？翻了几天Python文档，终于构思出来：用队列queue作为生产者（web前端）向消费者（数据库后端）传递任务的渠道。生产者，会与SQL命令一起，同时传递一个管道pipe的连接对象，作为任务完成后，回传结果的渠道。确保，任务的接收方与发送方保持一致。
作为第二个问题的解决方法，可以使用线程池来并发获取任务队列中的task，然后执行命令并回传结果。
第二次改进
第一次改进的效果还是很明显的，不用任何测试手段。直接点击页面链接，可以很直观地感觉到反应速度有很明显的加快。
但是对于第二个问题，使用线程池还是有些欠妥当。因为，CPython解释器存在GIL问题，所有线程实际上都在一个解释器进程里调度。线程稍微开多一点，解释器进程就会频繁的切换线程，而线程切换的开销也不小。线程多一点，甚至会出现“抖动”问题（也就是刚刚唤醒一个线程，就进入挂起状态，刚刚换到栈帧或内存的上下文，又被换回内存或者磁盘），效率大大降低。也就是说，线程池的并发量很有限。
试过了多进程、多线程，只能在单个线程里做文章了。
Python中的asyncio库
Python里有大量的协程库可以实现单线程内的并发操作，比如Twisted、Gevent等等。Python官方在3.5版本里提供了asyncio库同样可以实现协程并发。asyncio库大大降低了Python中协程的实现难度，就像定义普通函数那样就可以了，只是要在def前面多加一个async关键词。async def函数中，需要阻塞在其他async def函数的位置前面可以加上await关键词。
import asyncio
async def wait():
await asyncio.sleep(2)
async def execute(task):
process_task(task)
await wait()
continue_job()
async def函数的执行稍微麻烦点。需要首先获取一个loop对象，然后由这个对象代为执行async def函数。
loop = asyncio.get_event_loop()
loop.run_until_complete(execute(task))
loop.close()
loop在执行execute(task)函数时，如果遇到await关键字，就会暂时挂起当前协程，转而去执行其他阻塞在await关键词的协程，从而实现协程并发。
不过需要注意的是，run_until_complete()函数本身是一个阻塞函数。也就是说，当前线程会等候一个run_until_complete()函数执行完毕之后，才会继续执行下一部函数。所以下面这段代码并不能并发执行。
for task in task_list:
loop.run_until_complete(task)
对与这个问题，asyncio库也有相应的解决方案：gather函数。
loop = asyncio.get_event_loop()
tasks = [asyncio.ensure_future(execute(task))
for task in task_list]
loop.run_until_complete(asyncio.gather(*tasks))
loop.close()
当然了，async def函数的执行并不只有这两种解决方案，还有call_soon与run_forever的配合执行等等，更多内容还请参考官方文档。
Python下的I/O多路复用
协程，实际上，也存在上下文切换，只不过开销很轻微。而I/O多路复用则完全不存在这个问题。
目前，Linux上比较火的I/O多路复用API要算epoll了。Tornado，就是通过调用C语言封装的epoll库，成功解决了C10K问题（当然还有Pypy的功劳）。
在Linux里查文档，可以看到epoll只有三类函数，调用起来比较方便易懂。
创建epoll对象，并返回其对应的文件描述符（file descriptor）。
int epoll_create(int size);
int epoll_create1(int flags);
控制监听事件。第一个参数epfd就对应于前面命令创建的epoll对象的文件描述符；第二个参数表示该命令要执行的动作：监听事件的新增、修改或者删除；第三个参数，是要监听的文件对应的描述符；第四个，代表要监听的事件。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
等候。这是一个阻塞函数，调用者会等候内核通知所注册的事件被触发。
int epoll_wait(int epfd, struct epoll_event *events,
int maxevents, int timeout);
int epoll_pwait(int epfd, struct epoll_event *events,
int maxevents, int timeout,
const sigset_t *sigmask);
在Python的select库里：
select.epoll()对应于第一类创建函数；
epoll.register()，epoll.unregister()，epoll.modify()均是对控制函数epoll_ctl的封装；
epoll.poll()则是对等候函数epoll_wait的封装。
Python里epoll相关API的最大问题应该是在epoll.poll()。相比于其所封装的epoll_wait，用户无法手动指定要等候的事件，也就是后者的第二个参数struct epoll_event *events。没法实现精确控制。因此只能使用替代方案：select.select()函数。
根据Python官方文档，select.select(rlist, wlist, xlist[, timeout])是对Unix系统中select函数的直接调用，与C语言API的传参很接近。前三个参数都是列表，其中的元素都是要注册到内核的文件描述符。如果想用自定义类，就要确保实现了fileno()方法。
其分别对应于：
rlist: 等候直到可读
wlist: 等候直到可写
xlist: 等候直到异常。这个异常的定义，要查看系统文档。
select.select()，类似于epoll.poll()，先注册文件和事件，然后保持等候内核通知，是阻塞函数。
实际应用
Psycopg2库支持对异步和协程，但和一般情况下的用法略有区别。普通数据库连接支持不同线程中的不同游标并发查询；而异步连接则不支持不同游标的同时查询。所以异步连接的不同游标之间必须使用I/O复用方法来协调调度。
所以，我的大致实现思路是这样的：首先并发执行大量协程，从任务队列中提取任务，再向连接池请求连接，创建游标，然后执行命令，并返回结果。在获取游标和接受查询结果之前，均要阻塞等候内核通知连接可用。
其中，连接池返回连接时，会根据引用连接的协程数量，返回负载最轻的连接。这也是自己定义AsyncConnectionPool类的目的。
我的代码位于：bottle-blog/dbservice.py
存在问题
当然了，这个流程目前还一些问题。
首先就是每次轮询拿到任务之后，都会走这么一个流程。
获取连接 -- 新建游标 -- 执行任务 -- 关闭游标 -- 取消连接引用
本来，最好的情况应该是：在轮询之前，就建好游标；在轮询时，直接等候内核通知，执行相应任务。这样可以减少轮询时的任务量。但是如果协程提前对应好连接，那就不能保证在获取任务时，保持各连接负载均衡了。
所以这一块，还有工作要做。
还有就是epoll没能用上，有些遗憾。
以后打算写点C语言的内容，或者用Python/C API，或者用Ctypes包装共享库，来实现epoll的调用。
最后，请允许我吐槽一下Python的epoll相关文档：简直太弱了！！！必须看源码才能弄清楚功能。