同步 Python 和异步 Python 有什么区别?
关注 “Python猫” ,一个值得加星标的公众号
剧照 | 《唐伯虎点秋香》
你是否听人们说过,异步 Python 代码比“普通(或同步)Python 代码更快?果真是那样吗?
Web 应用程序通常要处理许多请求,这些请求在短时间内来自不同的客户端。为避免处理延迟,必须考虑并行处理多个请求,这通常称为“并发”。
在本文中,我将继续使用 Web 应用程序作为例子,但还有其它类型的应用程序也从并发中获益。因此,这个讨论并不仅仅是针对 Web 应用程序的。
术语“同步”和“异步”指的是编写并发应用程序的两种方式。所谓的“同步”服务器使用底层操作系统支持的线程和进程来实现这种并发性。下面是同步部署的一个示意图:
在这种情况下,我们有 5 台客户端,都向应用程序发送请求。这个应用程序的访问入口是一个 Web 服务器,通过将服务分配给一个服务器 worker 池来充当负载均衡器,这些 worker 可以实现为进程、线程或者两者的结合。这些 worker 执行负载均衡器分配给他们的请求。你使用 Web 应用程序框架(例如 Flask 或 Django)编写的应用程序逻辑运行在这些 worker 中。
这种类型的方案对于有多个 CPU 的服务器比较好,因为你可以将 worker 的数量设置为 CPU 的数量,这样你就能均衡地利用你的处理器核心,而单个 Python 进程由于全局解释器锁(GIL)的限制无法实现这一点。
在缺点上,上面的示意图也清楚展示了这种方案的主要局限。我们有 5 个客户端,却只有 4 个 worker。如果这 5 个客户端在同一时间都发送请求,那么负载均衡器会将某一个客户端之外的所有请求发送到 worker 池,而剩下的请求不得不保留在一个队列中,等待有 worker 变得可用。因此,五分之四的请求会立即响应,而剩下的五分之一需要等一会儿。服务器优化的一个关键就在于选择适当数量的 worker 来防止或最小化给定预期负载的请求阻塞。
一个异步服务器的配置很难画,但是我尽力而为:
这种类型的服务器运行在单个进程中,通过循环控制。这个循环是一个非常有效率的任务管理器和调度器,创建任务来执行由客户端发送的请求。与长期存在的服务器 worker 不同,异步任务是由循环创建,用来处理某个特定的请求,当那个请求完成时,该任务也会被销毁。任何时候,一台异步服务器都会有上百或上千个活跃的任务,它们都在循环的管理下执行自己的工作。
你可能想知道异步任务之间的并行是如何实现的。这就是有趣的部分,因为一个异步应用程序通过唯一的协同多任务处理来实现这点。这意味着什么?当一个任务需要等待一个外部事件(例如,一个数据库服务器的响应)时,不会像一个同步的 worker 那样等待,而是会告诉循环,它需要等待什么,然后将控制权返回给它。循环就能够在这个任务被数据库阻塞的时候发现另外一个准备就绪的任务。最终,数据库将发送一个响应,而那时循环会认为第一个的任务已经准备好再次运行,并将尽快恢复它。
异步任务暂停和恢复执行的这种能力可能在抽象上很难理解。为了帮你应用到你已经知道的东西,可以考虑在 Python 中使用await
或yield
关键字这一方法来实现,但你之后会发现,这并不是唯一实现异步任务的方法。
一个异步应用程序完全运行在单个进程或线程中,这可以说是令人吃惊的。当然,这种类型的并发需要遵循一些规则,因此,你不能让一个任务占用 CPU 太长时间,否则,剩余的任务会被阻塞。为了异步执行,所有的任务需要定时主动暂停并将控制权返还给循环。为了从异步方式获益,一个应用程序需要有经常被 I/O 阻塞的任务,并且没有太多 CPU 工作。Web 应用程序通常非常适合,特别是当它们需要处理大量客户端请求时。
在使用一个异步服务器时,为了最大化多 CPU 的利用率,通常需要创建一个混合方案,增加一个负载均衡器并在每个 CPU 上运行一个异步服务器,如下图所示:
我敢肯定,你知道要在 Python 中写一个异步应用程序,你可以使用 asyncio package,这个包是在协程的基础上实现了所有异步应用程序都需要的暂停和恢复特性。其中yield
关键字,以及更新的async
和await
都是asyncio
构建异步能力的基础。
https://docs.python.org/3/library/asyncio.html
Python 生态系统中还有其它基于协程的异步方案,例如 Trio 和 Curio。还有 Twisted,它是所有协程框架中最古老的,甚至出现得比asyncio
都要早。
如果你对编写异步 Web 应用程序感兴趣,有许多基于协程的异步框架可以选择,包括 aiohttp、sanic、FastAPI 和 Tornado。
很多人不知道的是,协程只是 Python 中编写异步代码的两种方法之一。第二种方法是基于一个叫做 greenlet 的库,你可以用 pip 安装它。Greenlets 和协程类似,它们也允许一个 Python 函数暂停执行并稍后恢复,但是它们实现这点的方式完全不同,这意味着 Python 中的异步生态系统分成两大类。
协程与 greenlets 之间针对异步开发最有意思的区别是,前者需要 Python 语言特定的关键字和特性才能工作,而后者并不需要。我的意思是,基于协程的应用程序需要使用一种特定的语法来书写,而基于 greenlet 的应用程序看起来几乎和普通 Python 代码一样。这非常酷,因为在某些情况下,这让同步代码可以被异步执行,这是诸如asyncio
之类的基于协程的方案做不到的。
那么在 greenlet 方面,跟asyncio
对等的库有哪些?我知道 3 个基于 greenlet 的异步包:Gevent、Eventlet 和 Meinheld,尽管最后一个更像是一个 Web 服务器而不是一个通用的异步库。它们都有自己的异步循环实现,而且它们都提供了一个有趣的“monkey-patching”功能,取代了 Python 标准库中的阻塞函数,例如那些执行网络和线程的函数,并基于 greenlets 实现了等效的非阻塞版本。如果你有一些同步代码想要异步运行,这些包会对你有所帮助。
据我所知,唯一明确支持 greenlet 的 Web 框架只有 Flask。这个框架会自动监测,当你想要运行在一个 greenlet Web 服务器上时,它会自我进行相应调整,而无需进行任何配置。这么做时,你需要注意不要调用阻塞函数,或者,如果你要调用阻塞函数,最好用猴子补丁来“修复”那些阻塞函数。
但是,Flask 并不是唯一受益于 greenlets 的框架。其它 Web 框架,例如 Django 和 Bottle],虽然没有 greenlets,但也可以通过结合一个 greenlet Web 服务器并使用 monkey-patching 修复阻塞函数的方式来异步运行。
对于同步和异步应用程序的性能,存在着一个广泛的误解——异步应用程序比同步应用程序快得多。
对此,我需要澄清一下。无论是用同步方式写,还是用异步方式写,Python 代码运行速度是几乎相同的。除了代码,有两个因素能够影响一个并发应用程序的性能:上下文切换和可扩展性。
在所有运行的任务间公平地共享 CPU 所需的工作,称为上下文切换,能够影响应用程序的性能。对同步应用程序来说,这项工作是由操作系统完成的,而且基本上是一个黑箱,不需要配置或微调选项。对异步应用程序来说,上下文切换是由循环完成的。
默认的循环实现由asyncio
提供,是用 Python 编写的,效率不是很高。而 uvloop 包提供了一个备选的循环方案,其中部分代码是用 C 编写的来实现更好的性能。Gevent 和 Meinheld 所使用的事件循环也是用 C 编写的。Eventlet 用的是 Python 编写的循环。
高度优化的异步循环比操作系统在进行上下文切换方面更有效率,但根据我的经验,要想看到实际的效率提升,你运行的并发量必须非常大。对于大部分应用程序,我不认为同步和异步上下文切换之间的性能差距有多明显。
我认为异步更快这个神话的来源是,异步应用程序通常会更有效地使用 CPU、能更好地进行扩展并且扩展方式比同步更灵活。
如果上面示意图中的同步服务器同时收到 100 个请求,想一下会发生什么。这个服务器同时最多只能处理 4 个请求,因此大部分请求会停留在一个队列中等待,直到它们被分配一个 worker。
与之形成对比的是,异步服务器会立即创建 100 个任务(或者使用混合模式的话,在 4 个异步 worker 上每个创建 25 个任务)。使用异步服务器,所有请求都会立即开始处理而不用等待(尽管公平地说,这种方案也还会有其它瓶颈会减慢速度,例如对活跃的数据库连接的限制)。
如果这 100 个任务主要使用 CPU,那么同步和异步方案会有相似的性能,因为每个 CPU 运行的速度是固定的,Python 执行代码的速度总是相同的,应用程序要完成的工作也是相同的。但是,如果这些任务需要做很多 I/O 操作,那么同步服务器只能处理 4 个并发请求而不能实现 CPU 的高利用率。而另一方面,异步服务器会更好地保持 CPU 繁忙,因为它是并行地运行所有这 100 个请求。
你可能会想,为什么你不能运行 100 个同步 worker,那样,这两个服务器就会有相同的并发能力。要注意,每个 worker 需要自己的 Python 解释器以及与之相关联的所有资源,再加上一份单独的应用程序拷贝及其资源。你的服务器和应用程序的大小将决定你可以运行多少个 worker 实例,但通常这个数字不会很大。另一方面,异步任务非常轻量,都运行在单个 worker 进程的上下文中,因此具有明显优势。
综上所述,只有如下场景时,我们可以说异步可能比同步快:
存在高负载(没有高负载,访问的高并发性就没有优势)
任务是 I/O 绑定的(如果任务是 CPU 绑定的,那么超过 CPU 数目的并发并没有帮助)
你查看单位时间内的平均请求处理数。如果你查看单个请求的处理时间,你不会看到有很大差别,甚至异步可能更慢,因为异步有更多并发的任务在争夺 CPU。
希望本文能解答异步代码的一些困惑和误解。我希望你能记住以下两个关键点:
异步应用程序只有在高负载下才会比同步应用程序做得更好
多亏了 greenlets,即使你用一般方式写代码并使用 Flask 或 Django 之类的传统框架,也能从异步中受益。
如果你想要了解更多关于异步系统如何工作的细节,可以查看 YouTube 上我在 PyCon 的演讲 Asynchronous Python for the Complete Beginner。 https://www.youtube.com/watch?v=iG6fr81xHKA
原文链接:https://blog.miguelgrinberg.com/post/sync-vs-async-python-what-is-the-difference
推荐阅读
-
python 的迭代器和生成器有什么区别?
-
你有在手机上用过能编写Java和Python程序的应用吗?
-
在Python里,sort函数和sorted函数有什么不同?
-
Python | 导入模块时,import 和 from 有什么区别?
-
Python 有 1、2、3 和 4 位数,那么可以组成多少个不同的三位数而不重复?它们都是什么?
-
天气编程|使用 Python 对夏季降水和大西洋同步 SST 进行 SVD 分析
-
什么是 CPython,什么是 PyPy,Python 和 CPython 有什么关系?
-
固定资产折旧代码 python 固定资产折旧代码逻辑-1.1 概述 固定资产折旧方法有多种,基本可分为直线法(包括年平均法和工作量法)和加速折 旧法(包括年数总和法和双倍余额递减法),企业应根据固定资产所含经济利益的预计 实现情况选择不同的折旧方法。我国会计准则规定,固定资产折旧按月计提;当月增加的固定资产,当月不提折旧,从次月起计提折旧;当月减少的固定资产,当月仍应计提折旧,从次月起停止计提折旧;计提折旧后,无论能否使用,均不得提取折旧;提前报废的固定资产,不再计提折旧。折旧计算方法举例如下: 年平均折旧额=(资产购置价值-残值)/预计使用年限 年总折旧额=(资产购置价值-残值)*使用年限/预计使用总年限 例如,价值 1 万元的电脑,残值为零,预计使用 5 年,各年折旧计算公式如下。按以下公式计算各年折旧 第一年:10,000.00 * 5/(5+4+3+2+1) 第二年:10,000.00 * 4/(5+4+3+2+1) 第三年:10,000.00 * 3/(5+4+3+2+1) 第四年:10,000.00 * 2/(5+4+3+2+1) 第五年:10,000.00 * 1/(5+4+3+2+1) 1.2 +2+1) 1.2 相关配置
-
Matlab 和 Python 之间的通信和同步
-
测试事物 (I) - 同步和异步 - 同步:当函数调用启动时,调用不会返回或调用者不会继续执行后续操作,直到获得该调用的结果。异步:异步与同步相反,当发出异步过程调用时,调用者可以继续执行后续操作,直到调用者得到结果。调用完成后,通常会通过状态(轮询)、通知(消息)和回调通知调用者。对于异步调用,调用的返回不受调用者的控制。 从上述定义中我们可以看出,同步和异步可以由调用者或被调用者控制。我们暂且将调用者视为客户端,而被调用者视为服务器。 在客户端调用服务器接口后,如果客户端需要等待服务器返回结果才能进行下一步,那么它就是同步的。如果在进行下一步之前不需要等待服务器返回结果,那么它就是同步的。如果在进行下一步之前不需要等待服务器的结果,那么它就是异步的。 服务器本身既可以控制同步,也可以控制异步。对于需要长时间计算的函数,服务器会将其设置为异步,在客户端发出请求后立即向客户端返回结果,这没有任何实际意义,只是表示服务器收到了请求。对于很快就能得到结果的请求,使用同步就很好,返回的结果包含了得到这个请求所需的数据。 那么,同步测试和异步测试需要注意什么呢? 1. 用户体验 现在很多 APP 都有审核的功能,需要用户提供各种信息来完成相应的认证。这些审核可以是自动的,也可以是手动的等。自动审核一般比较快,因为它需要用户提供各种信息来完成相应的认证。自动审核一般比较快,因为需要比对的数据都存在服务器端,直接进行程序比对即可。人工审核则比较慢,快的几分钟,如果赶上周末,2-3 天都不一定。因此,对于自动审核和人工审核,需要合理利用同步和异步,达到最佳的用户体验。 自动审核速度快,用户提交信息后稍微等待一下就应该能得到审核结果,最多在客户端等待不超过 5 秒,看到加载等待一会儿就可以了。在这种情况下,使用同步就非常合适了,客户端没有得到结果,等到服务器端把审核结果传回来马上显示在客户端上,用户的体验会非常好,毕竟很快就得到了答案。 人工审核时,我们不能寄希望于总有一个人一直在那里审核,即使有,快的话也要几分钟,毕竟核对数据什么的都是人工的。用户在这种情况下不能等,但也不能总在这个页面上等。于是异步就派上用场了,客户端发出审核请求,服务器收到后马上告诉客户端我收到了,但不可能给出结果。客户端不管有没有收到服务器的请求,都会告诉用户等待 XX 时间才能查看结果,用户不需要在这个页面上一直等待。直到服务器端计算完成,然后通过推送消息通知客户端,或者用户再次进入身份验证页面进行身份验证结果请求时,才会得知自己的身份验证结果。 进行测试时,如果遇到长时间无法获取结果的界面,建议客户端使用异步请求,以减少用户体验不佳的情况!