现实世界的Gevent和Asyncio用例

Question

在网上发布了很多文章之后，这是我对并发程序的理解-

在python中，如果我们有CPU绑定任务，那么我们可以利用多处理模块（原因GIL）。如果我们正在做网络I / O或磁盘I / O那么我们就可以利用多线程了。

[在此之前，我试图了解所有这些内容的基础知识，这是我对它们的想法-

在多线程环境中同步：任务在以下位置执行不同的线程，但是要等待其他任何正在执行的任务线程。

异步：单线程：任务开始执行而无需等待完成另一项任务。在给定的时间完成一项任务被执行。多线程：任务在不同的线程中执行无需等待任何任务即可独立完成任务处决。

异步编程模型可帮助我们实现并发。多线程环境中的异步编程模型是一种实现并行性的方法。

所以我的理解可以归结为使用异步库中的事件循环运行线程，greenlet和协程。

我们可以使用线程来实现异步行为（如果我们不安排线程os调度，上下文切换和内存开销），那么我们可以从这三种范式中受益。

[请提供一些实际和生产级别的示例，并说明使用它们的原因。

谢谢

Answer 1

IMO，每个方面的最大考虑因素是缩放比例。线程和多处理相对于程序可用的线程/进程数量进行缩放，而异步可以相对于可用进程的数量对基于IO的工作负载进行线性扩展。

多线程

由于GIL，我没有看到线程使用太多。 Uwsgi，celery和其他框架提供了基于线程的工作程序。线程的一些优点是：

本地支持
• 如果您知道您的工作量是受IO约束的，那么使用线程模型可以使您共享一个地址空间就可以变得不那么复杂。
• 相对于可用进程数的吞吐量标度
• 我不推荐线程的原因：

种族条件/线程安全
• 许多应用程序（第三方模块）不考虑这一点，它们可能具有共享内存，并会在竞争条件下打开应用程序。这是要提防的，我经常看到。

多进程

Uwsgi / Celery :)在我的经验中，这是默认的并发原语，因为可能进行并行处理，竞争条件，标准库支持和非GIL的可能性较小。

优点：

标准库原语
• 缺点：

流程管理（即，需要跟踪流程运行状况）
• 相对于可用进程数的吞吐量标度

• Asyncio

扭曲，龙卷风和异步。

这对于Web或网络框架极为普遍，因为它们的大部分工作通常是基于IO的工作负载。异步IO使单个线程可以一次处理成百上千，成千上万甚至一百万个:)连接。将此与基于前叉或基于流程的模型进行比较，该模型将需要一个可用于每个并发请求的流程。

其主要缺点是，由于异步IO框架通常是单线程的，因此任何与CPU绑定的工作负载都将阻止事件循环的前进，这对于像node / v8这样的运行时是一个非常常见的操作问题。