小米
乱谈Python并发
说实话，我一直觉得PHP真的是最好的语言，不仅养活了一大批PHP程序员，同时还为安全人员提供了大量的就业机会。然而，令人唏嘘的是，安全界很多人其实是吃着Python的饭，操着PHP的心。此外，大量的安全研究工具也都是使用Python开发，比如我始终不习惯的mitmproxy，又或者一个循环语句400行的sqlmap、一抓一大把的爬虫框架以及subprocess满天飞的命令行应用包装库。
干活要吃饭，吃饭要带碗。既然这样，要进入互联网安全领域，无论是小白还是高手，多少是要了解点Python的。虽然笔者只是个安全太白，连小白都够不上，但我Python比你专业啊。我看过一些安全人员写的代码，不可否认，功能是有的，代码是渣的，这我非常理解，毕竟术业有专攻，要我去挖洞我也麻瓜，挖个坑倒可以。
其实，Python可以谈的话题很多，比如Python2还是Python3，比如WSGI，比如编码，比如扩展，比如JIT，比如框架和常用库等等，而我们今天要说的则是异步/并发问题，代码运行快一点，就能有更多时间找女朋友了。
进程
众所周知，CPython存在GIL（全局解释锁）问题，用来保护全局的解释器和环境状态变量，社区有过几次去GIL的尝试，都以失败告终，因为发现即使去了GIL，性能好像提高也不是那么明显嘛，还搞那么复杂。注意，这里说的是CPython，Python语言本身是没说要必须有GIL的，例如基于JVM的Jython。而GIL的结果就是Python多线程无法利用多CPU，你128核又如何，我就逮着一只羊薅羊毛了。所以，如果功能是CPU密集型的，这时候Python的进程就派上用场了，除此之外，利用C扩展也是可以绕过GIL的，这是后话。
进程模型算是一种比较古老的并发模型。Python中的进程基本是对系统原生进程的包装，比如Linux上的fork。在Python标准库中，主要是multiprocessing包，多么直白的名字。其中常用的也就是pool，queue模块以及synchronize模块中的一些同步原语（Lock、Condition、Semaphore、Event等）。如果需要更高级的功能，可以考虑下managers模块，该模块用来管理同步进程，大致的实现原理是在内部起了一个server，进程都与这个server交互，进行变量共享...目瞪狗呆有没有，这个模块笔者也只用过两三次，如需对进程进行高级管理，请移步此处。
另外，multiprocessing中有个dummpy子模块，重新实现了一遍多进程模块中的API，然而，它是多线程的，就这么乱入，目的是方便你的代码在多线程和多进程之间无障碍切换，很贴心有没有，而且异常低调，低调到官方文档就一句话，17个单词。
如果你的代码需要大量的CPU运算，多进程是一个比较好的选择。对于安全领域的来说，这种场景貌似不是很多，什么？需要大量加密解密？都到自己要实现这么高深算法的程度了，别挣扎了，用C吧，写个扩展更好。
所以，如非必须，我是不太推荐用多进程的，容易出错，不好控制，而且，有更省心的选择，谁会和自己过不去呢。
线程
与进程一样，Python中的线程也是对系统原生线程的包装。其实现在的Linux上，线程和进程的差别不是很大，以此推知，Linux平台下，Python中的线程和进程开销差别也不会太大，但终归进程是要开销大点的，创建也会慢一点。相比于进程，我是更倾向使用线程的，尤其是IO密集型程序，能用线程解决的问题，尽量不用进程。
另外，如果要在进程之间共享数据，确实比较头疼一点，要用到Queue、Pipe、SyncManager或者类似redis这种外部依赖，而线程之间共享数据就方便很多，毕竟大家都是一个爹生的，家里东西一起用吧。有人可能会觉得，线程能共享数据，但是也会在修改数据时互相影响，导致各种难以排查的BUG，这个问题提的好，之所以有这种问题，还不是因为代码写的烂，多练练就好了。如果既想要方便的共享数据，还要能随意的隔离数据，threading.local()可以帮你，创建的变量属于线程隔离的，线程之间互不影响，上帝的归上帝，恺撒的归恺撒。说到ThreadLocal变，我们熟知的Flask中每个请求上下文都是ThreadLocal的，以便请求隔离，这个是题外话。
Python中的线程主要是在threading模块里，这个模块是对更底层的\_thread的封装，提供了更友好的接口。该模块中用到比较多的也是Queue、Pool、Lock、Event等，这些就不展开了，有机会再一一细说。Python 3.2后还引入了一个比较有意思的新类，叫Barrier，顾名思义，就是设置个障碍（设置数目n），等大家都到齐了（每个线程调用下wait，直到有n个线程调用），再一起出发。Python 3.3也在进程中引入了对应的此模块。此外，还有Timer可以用来处理各种超时情况，比如终结subprocess创建的进程。
创建多线程有两种方式：一种是继承threading.Thread类，然后实现run方法，在其中实现功能逻辑；另一种就是直接threading.Thread(target=xxx)的方式来实现，与进程模块大同小异。具体使用可以参考官方文档，这里就不赘述了。
协程
前面我们提到了，Python的线程（包括进程）其实都是对系统原生内核级线程的包装，切换时，需要在内核与用户态空间来来回回，开销明显会大很多，而且多个线程完全由系统来调度，什么时候执行哪个线程是无法预知的。相比而言，协程就轻量级很多，是对线程的一种模拟，原理与内核级线程类似，只不过切换时，上下文环境保存在用户态的堆栈里，协程“挂起”的时候入栈，“唤醒”的时候出栈，所以其调度是可以人为控制的，这也是“协程”名字的来由，大伙协作着来，别总抢来抢去的，伤感情。
实际上，协程本身并不是真正的并发，任何时候只有一个协程在执行，只是当需要耗时操作时，比如I/O，我们就让它挂起，执行别的协程，而不是一直干等着什么也做不了，I/O完毕了我们再切换来继续执行，这样可以大大提高效率，而且不用再费心费力去考虑同步问题，简单高效。与传统线程、进程模型相比，协程配上事件循环（告诉协程什么时候挂起，什么时候唤醒），简直完美。Python里的协程也是后来才逐渐加入的，基本分三个阶段，过程比较坎坷，与”携程“差不多，时不时被骂几句。
yield/send
这算是第一个阶段，其实yield主要是用来做生成器的，不要告我不知道什么叫生成器，这多尴尬。Python 2.5时，yield变成了表达式（之前只是个语句），这样就有了值，同时PEP 342引入了send，yield可以暂停函数执行，send通知函数继续往下执行，并提供给yield值。仔细一看，好巧啊，这么像协程，于是屁颠屁颠的把生成器用来实现协程，虽然是半吊子工程，不过还不错的样子，总比没有的好，自此我们也可以号称是一门有协程的现代高级编程语言了。
可以这么说，对于不考虑yield返回值情形，我们就把它当作普通的生成器，对于考虑yield返回值的，我们就可以把它看作是协程了。
但是，生成器干协程的活，总归不是那么专业。虽然生成器这货能模拟协程，但是模拟终归是模拟，不能return，不能跨堆栈，局限性很大。说到这里，连不起眼的Lua都不屑于和我们多说话，Go则在Goroutine（说白了还不是类协程）的道上一路狂奔，头都不回，而Erlang轻轻抚摸了下Python的头，说句：孙子诶。
既然Python 2.x中的yield不争气，索性我们来改造下咯，于是Python 3.3（别老抱着Python 2不放了）中生成器函数华丽丽的可以return了，顺带来了个yield from，解决了旧yield的短板。
asyncio/yield from
这算第二阶段，Python 3.3引入yield from（PEP 380），Python3.4引入asyncio。其实本质上来说，asyncio是一个事件循环，干的活和libev差不多，用来调度协程，同时使用@asyncio.coroutine来把函数打扮成协程，搭配上yield from实现基于协程的异步并发。
与yield相比，yield from进化程度明显高了很多，不仅可以用于重构简化生成器，进而把生成器分割成子生成器，还可以像一个双向管道一样，将send的信息传递给内层协程，获取内层协程yield的值，并且处理好了各种异常情况，`return (yield from xxx)`也是溜溜的。
接下来看一个yield from Future的例子，其实就是asyncio.sleep(1)：
async/await
这是第三个阶段。Python 3.5引入了async/await，没错，我们就是抄C#的，而且还抄出了具有Python特色的`async with`和`async for`。某种程度上看，async/await是asyncio/yield from的升级版，这下好了，从语言层面得到了的支持，我们是名正言顺的协程了，再也不用寄人篱下，委身于生成器了（提裤子不认人啊，其实还不是asyncio帮衬着）。也是从这一版本开始，生成器与协程的界限要逐渐开始划清。
对比下async/await和asyncio/yield from，如此相似，不过还是有一些区别的，比如await和yield from接受的类型，又比如函数所属类型等，所以二者是不能混用的：
不过话说回来，最近几个版本的Python引入的东西真不少，概念一个一个的，感觉已经不是原来那个单纯的Python了。悲剧的是用的人却不多，周边生态一片贫瘠，社区那帮人都是老司机，您车开这么快，我等赶不上啊，连Python界的大神爱民（Armin Ronacher，我是这么叫的，听着接地气）都一脸蒙逼，狂吐槽（ http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio ），眼看着就要跑去搞rust了。不过，吐槽归吐槽，这个毕竟是趋势，总归是要了解的，技多不压身，乱世出英雄，祝你好运。
题外话，搞安全么，难免写个爬虫、发个http请求什么的，还在用requests吗，去试试aiohttp，谁用谁知道。
greenlet/gevent与tornado
除了官方的协程实现外，还有一些基于协程的框架或网络库，其中比较有名的有gevent和tornado，我个人强烈建议好好学学这两个库。
gevent是一个基于协程的异步网络库，基于libev与greenlet。鉴于Python 2中的协程比较残疾，greenlet基本可以看作是Python 2事实上的协程实现了。与官方的各种实现不同，greenlet底层是C实现的，尽管stackless python基本上算失败了，但是副产品greenlet却发扬光大，配合libev也算活的有声有色，API也与标准库中的线程很类似，分分钟上手。同时猴子补丁也能很大程度上解决大部分Python库不支持异步的问题，这时候nodejs的同学一定在偷笑了：Python这个渣渣。
tornado则是一个比较有名的基于协程的网络框架，主要包含两部分：异步网络库以及web框架。东西是好东西，相比twisted也挺轻量级，但是配套不完善啊，到现在我都没找到一个好用的MySQL驱动，之前用的Redis驱动还坑的我不要不要的。我觉得用作异步网络库还是相当不错的，但是作为web框架吧...就得看人了，我见过很多人直接用普通的MySQLdb，还告我说tornado性能高，你在逗我吗，用普通的MySQL驱动配合异步框架，这尼玛当单线程在用啊，稍有差错IOLoop Block到死，我要是tornado我都火大。随着Python的发展，tornado现在也已经支持asyncio以及async/await，不过我很久没用了，具体如何请参考文档。
对比gevent与tornado，本质上是相同的，只是二者走了不同的道路，gevent通过给标准库的socket、thread、ssl、os等打patch，采用隐式的方式，无缝的把现有的各种库转换为支持异步，避免了为支持异步而重写，解决了库的问题，性能也是嗖嗖的，随随随便跑万儿八千个patch后的线程玩一样，然而，我对这种隐藏细节、不可掌控的黑魔法总是有一丝顾虑；另一方的tornado则采用显示的方式，把调度交给用户来完成，清晰明了，结果就是自成一套体系，没法很好的利用现有的很多库，还得显示的调用IOLoop，单独使用异常别扭，你可以试试nsq的官方Python库，都是泪。
本文只是对Python中并发编程的一个全局性的介绍，帮助不了解这方面的同学有一个概念，方便去针对学习，若要展开细节，恐怕三天三夜也讲不完，而我的碗还没洗，所以这次就到此为止。其实，作为一门通用胶水语言，我觉得，无论工作是哪个方向，好好学习一下Python是有必要的。知道requests那哥们吗，写完requests后就从路人大胖子变成了文艺摄影小帅哥，而且还抱得美人归，你还等什么。退一步讲，万一安全搞不好，还可以考虑进军目前火热的机器学习领域。
所以，人生苦短，我用Python。
360
我们目前有Python代码约6万行，程序运行在Linux下。
这6万行Python代码被被分成80余个项目进行组织。每个项目提供一个或一组完整的功能集合，每个项目都有自己的 setup.py 文件用来将项目代码打包成 Python 发布包（Distribution），部分项目还有自动文档生成，我们使用的是 Sphinx 和 reST格式的文本。打包好的Python包被发布到我们自己搭建的内网的与 pypi.python.org 兼容的私有 pypi 服务器上，而文档保存在内网的类似于 readthedocs 的服务器上。
后台团队的代码主要运行我们自己的Linux服务器集群上，开发和部署的成本比较低，因此我们使用比较敏捷的开发流程。流程大体上可以分为下面几个步骤：
- 开发：顾名思义，这个步骤当中，开发人员在开发机上面写代码实现功能，不同的开发人员的开发环境使用 扩展过的 virtualenv 脚本进行隔离；
- 单元测试：开发人员负责对代码当中的关键部分进行单元测试，通常使用 unittest，我们使用 nose 将测试用例聚合和进行回归测试，不定期使用 coverage 确定代码测试覆盖率（集成在nose当中）。这一步还会使用 PyLint 对代码进行扫描；
- 构建：使用 python distribute 将 Python代码构建成包，同时将这个包发布到测试版 pypi 服务器（pypi-testing），测试版pypi服务器是我们搭建的若干个私有pypi其中之一，发布工作使用的是我们扩展的 distribute 命令；
- 测试：在测试机器或测试流程当中，从测试版pypi当中获取最新的库并测试，这个部署过程我们使用 distribute 提供的 easy_install 工具进行；
- 发布：将经过测试的包从测试版pypi服务器移到发布版pypi服务器，这个同样通过扩展的 distribute 命令；
- 部署：运维人员从发布版pypi服务器上获取最新的库，并更新到真实的服务器上，并应用新的变更。这个过程当中任何一台单机部署使用的都是 easy_install，在分布式环境下，我们使用 Fabric进行多机部署；
- 监控：新版本上线之后，会持续通过日志和报警系统进行系统监控。我们专门扩展了 logging 模块以便适应我们的监控需求。
熟悉Python的朋友们可能看到这些名词和包都很熟悉，因为我们所使用的都是业界广泛使用的开发、测试和运维的工具。但这些工具很多都适合于开源软件(Open Source Software)而非私有软件(Proprietary Software)，例如 distribute 与 pypi.python.org 的结合是天衣无缝的，Sphinx 和 readthedocs 也是很容易结合，但是作为一个私有软件，我们无法将代码和文档放到 pypi 或 readthedocs 上面。为此我们几乎复制了整套的基础架构，包括 pypi 服务，readthedocs 服务等，后续我会介绍我们如何做到这点的。希望这个系列对于其他正在使用Python开发私有软件的同仁能有些帮助。