PyCon 2018 闲聊系列：Facebook async 使用总结

PyCon 2018 的视频才上传不久，我也才刚刚补。而后视频我在联系 PSF 看能不要受权搬回国内方便观看。

首先我只补了两个视频，

John Reese - Thinking Outside the GIL with AsyncIO and Multiprocessing

Andrew Godwin - Taking Django Async

一个是，Facebook 来的大佬讲的 async/await 在 Facebook 组的应用，最后顺便卖了一个广告。

另一个是 Django 组的大佬也来说，关于 async/await ，同时推广 ASGI ，又是另一个话题了。

我今晚先讲讲 Facebook 的视频，第二个视频我再补= =

首先 Facebook 这个视频很短，可是我以为意义蛮重要的，

第一，全程没有秀什么特殊技巧，很适合初学者来到 Python 3 的世界

第二，并不单单是讲了 async 这样一种针对 I/O 密集型的手段，也传授了一些 multiprocessing 使用中的技巧

第三，出来站台，你看大厂在用，咱们也能够用试试？

好了，回到正题

首先 Facebook 组的大佬说本身的使用场景

其中最主要的是，须要从不少个接口中请求数据，而且将其整合起来。

最开始，他们在 Python 2 下使用线程池来完成这样的 I/O 操做，而后发现，兄弟这不对劲啊QAQ

内存占用大，同时仍是被 GIL 限制着。而后他们开始将代码升级到 Python 3，（这里画外音一下，Python 3.2 时将 GIL 进行过一次改造，让 thread 表现更好，参见 What’s New In Python 3.2) 好了，升级后发现

性能提高良好啊= =，因此天灭 Python 2 。

好了，目前还有一个大问题，GIL 怎么办。

Facebook 给出了两种选择

第一种，Multiprocessing

而后给出了一个使用小技巧

第二种，asyncio

说了 asyncio 的三个特性，

第一个，是 Future 模式的一种使用（Future 模式是在 Python 3.2 引入，PEP 3148 提出，参见 PEP 3148 -- futures - execute computations asynchronously）

第二个，asyncio 比线程快

第三个，I/O 并发

而后给展现了一个 asyncio 的最基本的用法

而后后面 Facebook 大佬花了一段时间讲了下怎么将 multiprocessing 和 asyncio 结合，这里我先不剧透，你们能够去瞧瞧

不过其中有一个点比较吸引我

你们猜猜这里面亮点在哪？

嗯，前面函数定义的时候用了新的特性 type annotation，最先于 PEP 484 Type Hints提出，3.5 引入，后续有几个提案都在围绕这个作优化，好比 3.6 的 PEP 526，3.7 的 PEP 563 不过这个说来话长，改天有时间写个辣鸡水文聊一聊吧。

不过 type-annotation 是个趋势，使用以后，配合 IDE ，提示，检查的体验都会提高一个台阶。

最后 Facebook 的大佬潇洒的扔了一个图，

而后扔了一个库

jreese/aiomultiprocess 图标 本次视频到此结束，

好了再说说个人感想

首先咱们公司用 async/await 这一套用的很广，不少。在进一年的过程之中发现官方的 asyncio 这一套有不少潜在的坑，可是其对性能的提高实在美好。因此我将其成为甜美的毒药。不过虽然我已经将 asyncio/Sanic/aiohttp 这一套 async/await 的当前顶梁柱黑出翔了，可是平心而论，async/await 这套意义和做用重大，很是棒的特性。同时社区的周边也逐渐起来，好比python-trio/trio了，同时愈来愈多的大公司开始使用，踩坑。虽不敢说 async/await 前景光明，可是随着后续的发展，将会成为人们在处理 I/O 密集型应用时优先的一个选择倒也不是什么难事儿。

因此先这样吧。

另外 Django 哪一个视频，你们在去看以前，建议先去看一个由 Django 开发组提出的，目前还处于 Draft 的做为现行 PEP3333PEP 3333 -- Python Web Server Gateway Interface v1.0.1 WSGI 替代的 ASGI 的相关提案详情，参见 ASGI - Channels 2.1.1 documentation