1. 从单线程到协程池为什么需要 gevent 版静态服务器做 Web 静态服务器这个练手项目很多人写到第六版就停了——用socket加多线程或者select把文件发出去本地测几个请求没问题一上并发就露馅。我最早那版也是这么写的用threading每来一个连接开一个线程测试工具一压线程数直接飙到几百CPU 全耗在线程切换上响应时间从几毫秒涨到几百毫秒。后来换成select做 IO 多路复用单线程能扛住更多连接了但代码里全是状态机读一半的文件、写一半的响应维护起来头大。gevent版要解决的就是这个矛盾既要像多线程那样用同步的写法写代码又要像事件循环那样用单线程扛高并发。它的核心是greenlet提供的协程切换能力加上libev/libuv事件循环做 IO 调度再通过monkey patch把标准库里的阻塞调用替换成协程友好的版本。这样你写recv()、send()、open().read()的时候代码看起来是阻塞的实际上遇到 IO 等待时 gevent 会自动把控制权交给其他 greenlet等 IO 就绪再切回来。这个版本适合谁如果你已经用socket手写过静态服务器理解 HTTP 请求响应的基本流程但被并发问题卡住了那这篇就是给你准备的。我会从 gevent 的调度原理讲起然后一步步改造原来的服务器重点讲清楚 monkey patch 的时机、协程池的容量控制、以及静态文件读取时怎么避免阻塞事件循环。最后会给出完整的可运行代码和压测对比数据。注意gevent 的 monkey patch 必须在导入任何可能被 patch 的模块之前执行否则 patch 不生效。这是新手最容易踩的坑后面会详细说。2. gevent 的调度机制greenlet、hub 与 monkey patch 的三角关系2.1 greenlet 不是线程切换靠代码主动让出greenlet 是 gevent 的协程载体你可以把它理解成一个可以暂停和恢复的函数执行栈。和线程不同greenlet 的切换不是操作系统强制的而是由代码在特定点主动触发。在 gevent 里这个触发点就是遇到 IO 操作的时候。举个例子当你的服务器调用client_socket.recv(1024)时如果这个 socket 被 gevent patch 过它不会真的阻塞整个进程而是向 gevent 的 hub 注册一个读事件然后当前 greenlet 挂起hub 去跑其他就绪的 greenlet。等数据到了hub 再把当前 greenlet 唤醒继续执行。整个过程对上层代码透明你看到的还是同步的recv调用。这里有个关键点greenlet 的切换是协作式的。如果一个 greenlet 里写了死循环且没有 IO 操作它会一直占着 CPU其他 greenlet 永远得不到执行。所以静态服务器里读大文件时不能一次性read()整个文件再发那样会长时间占用事件循环。正确做法是分块读取每读一块就让出一次控制权。2.2 hub 是调度中心所有 greenlet 都挂在它下面hub 是 gevent 的事件循环核心每个线程有一个 hub。它维护着事件循环、就绪队列和等待队列。当你spawn一个 greenlet 时它被加入到 hub 的调度体系中。hub 的工作就是不断检查哪些 IO 事件就绪了把对应的 greenlet 放到就绪队列然后按顺序执行。在静态服务器场景里主 greenlet 负责accept新连接每接受一个连接就spawn一个新的 greenlet 去处理这个连接的请求。这些处理 greenlet 在读写 socket 时会挂起hub 就去处理其他连接。这样单线程就能同时处理成百上千个连接因为大部分时间都花在等待网络 IO 上CPU 只是在事件就绪时做数据搬运。2.3 monkey patch 的时机决定成败monkey.patch_all()做的事情是把标准库里的socket、ssl、select、threading、time.sleep等模块替换成 gevent 的协程版本。这样你代码里原有的阻塞调用就自动变成非阻塞的了。但这里有个严格的顺序要求patch 必须在导入这些模块之前执行。因为 Python 的模块导入是单例的如果socket已经被导入了你再 patch原来导入的引用还是指向旧模块。正确的做法是在文件最开头写from gevent import monkey monkey.patch_all() import socket import gevent from gevent import Greenlet我见过有人把monkey.patch_all()写在import socket后面结果服务器跑起来还是阻塞的排查半天才发现是顺序问题。另外如果你用了logging模块建议在 patch 之后再导入否则日志的锁可能还是线程锁在高并发下会有性能问题。提示如果某些第三方库不兼容 gevent可以用monkey.patch_all(moduleFalse)只 patch 指定模块或者用monkey.patch_module(socket)单独 patch。3. 改造静态服务器从多线程到 gevent 协程池3.1 原有服务器的瓶颈在哪里假设你之前的多线程版长这样import socket import threading def handle_client(client_socket): request client_socket.recv(1024) # 解析请求读取文件发送响应 client_socket.close() server socket.socket() server.bind((0.0.0.0, 8080)) server.listen(128) while True: client, addr server.accept() t threading.Thread(targethandle_client, args(client,)) t.start()这个版本的问题很明显每个连接一个线程线程创建和销毁有开销线程切换有开销而且线程数受系统限制。当并发连接数超过几百时性能急剧下降。另外recv和send是阻塞的线程在等待 IO 时虽然会让出 GIL但线程本身的调度成本还在。3.2 用 gevent.spawn 替换 threading.Thread最直接的改造是把threading.Thread换成gevent.spawnimport gevent from gevent import monkey monkey.patch_all() import socket def handle_client(client_socket): try: request client_socket.recv(1024) # 解析请求读取文件发送响应 finally: client_socket.close() server socket.socket() server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 8080)) server.listen(128) while True: client, addr server.accept() gevent.spawn(handle_client, client)这样每个连接对应一个 greenlet创建和切换成本远低于线程。但这里有个隐患如果瞬间涌入大量连接greenlet 数量会无限增长内存和调度压力都会上来。所以需要引入协程池来控制并发上限。3.3 协程池的容量控制与超时处理gevent 提供了Pool类来做协程池from gevent.pool import Pool pool Pool(1000) # 最多同时处理 1000 个连接 while True: client, addr server.accept() pool.spawn(handle_client, client)Pool的容量设置需要根据实际场景权衡。设太小并发上不去设太大内存占用高而且调度开销也会增加。对于静态文件服务器每个 greenlet 主要消耗的是栈空间和缓冲区1000 到 5000 是比较合理的范围。我实测下来在 4GB 内存的机器上2000 个 greenlet 处理小文件请求内存占用大概在 200MB 左右。另外handle_client里最好加超时控制防止某个连接一直不发送数据导致 greenlet 挂死def handle_client(client_socket): client_socket.settimeout(30) try: request client_socket.recv(1024) if not request: return # 处理请求 except socket.timeout: pass finally: client_socket.close()注意settimeout在 gevent patch 之后会变成协程友好的超时不会阻塞事件循环。4. 静态文件读取的坑别让一次 read 卡住整个事件循环4.1 大文件读取为什么要分块静态服务器最核心的操作是读文件然后发出去。如果你写data f.read()一次性读整个文件对于几 KB 的小文件没问题但如果是几百 MB 的视频文件这一行会阻塞整个 greenlet 很长时间。虽然 gevent 会在文件 IO 时尝试让出控制权但标准文件对象的read并不总是能被 patch 成非阻塞的具体取决于操作系统和 gevent 版本。稳妥的做法是分块读取每块 64KB 左右def send_file(client_socket, filepath): with open(filepath, rb) as f: while True: chunk f.read(65536) if not chunk: break client_socket.sendall(chunk) gevent.sleep(0) # 主动让出控制权gevent.sleep(0)的作用是显式让出控制权让 hub 有机会调度其他 greenlet。虽然sendall本身在 patch 后会挂起但加上这个让出更保险尤其是在文件读取很快但网络发送较慢的场景下。4.2 sendall 与 send 的选择sendall会循环调用send直到所有数据发完在 gevent 环境下它会自动在每次send阻塞时让出。但如果你自己用send循环需要处理返回值因为send可能只发出去一部分def send_all(client_socket, data): total 0 while total len(data): sent client_socket.send(data[total:]) if sent 0: raise RuntimeError(connection broken) total sent用sendall更省心但要注意它在某些 gevent 版本里对超大数据的处理可能不够平滑。我的经验是对于静态文件用sendall配合分块读取就足够了。4.3 文件描述符泄漏与连接关闭每个连接处理完必须关闭 socket否则文件描述符会耗尽。用try/finally保证def handle_client(client_socket): try: # 处理请求 finally: client_socket.close()另外如果用了with open()读文件文件句柄会自动关闭。但 socket 的关闭不能依赖垃圾回收必须显式调用close()。我踩过一次坑在异常分支里忘了关 socket跑了几千个请求后报Too many open files排查了半天才发现是异常路径没走finally。5. 压测对比gevent 版到底比多线程版快多少5.1 测试环境与工具为了给出有参考价值的数据我在一台 4 核 8GB 的虚拟机上做了对比测试。服务器分别用多线程版和 gevent 版测试工具用wrk请求一个 10KB 的静态 HTML 文件。测试命令wrk -t4 -c1000 -d30s http://127.0.0.1:8080/index.html-t4表示 4 个线程-c1000表示 1000 个并发连接-d30s表示持续 30 秒。5.2 结果对比版本QPS平均延迟99% 延迟内存占用多线程版3200310ms890ms450MBgevent 版9800102ms280ms180MBgevent 版的 QPS 是多线程版的 3 倍左右延迟降低到三分之一内存占用也少了一半多。这个差距在并发数越高时越明显因为线程的调度成本随线程数增长而增加而 greenlet 的切换成本基本恒定。5.3 瓶颈分析与调优建议gevent 版在 1000 并发下 CPU 还没跑满瓶颈主要在磁盘 IO 和网络带宽。如果想进一步提升可以考虑用sendfile系统调用零拷贝发送文件减少用户态和内核态的数据拷贝加一层内存缓存把热点小文件缓存在内存里调整Pool大小和listen的 backlog 参数不过对于练手项目来说gevent 版的性能已经足够说明协程模型的优势了。6. 实际部署中遇到的三个坑与解决思路6.1 monkey patch 与第三方库的冲突有一次我在服务器里加了一个日志库结果启动就报错说socket已经被 patch 过了。原因是那个日志库在导入时自己 patch 了socket和我的 patch 冲突。解决办法是确保monkey.patch_all()在所有导入之前执行并且检查第三方库是否有自己的 patch 逻辑。如果冲突无法避免可以用monkey.patch_all(moduleFalse)然后手动 patch 需要的模块。6.2 协程池满后的请求丢弃当Pool满了之后pool.spawn会阻塞等待直到有 greenlet 结束。这会导致accept循环被卡住新连接堆积在 backlog 里。如果 backlog 也满了客户端会收到连接拒绝。对于静态服务器这其实是合理的背压机制但需要把 backlog 设大一些server.listen(1024)另外可以加一个监控当池满时打日志方便判断是否需要扩容。6.3 信号处理与优雅退出gevent 版的服务器在收到CtrlC时如果正在处理请求可能会直接退出导致连接中断。可以注册信号处理函数先停止接受新连接等现有 greenlet 处理完再退出import signal import gevent def graceful_shutdown(): server.close() pool.join(timeout10) gevent.signal_handler(signal.SIGINT, graceful_shutdown)这样在退出时会给正在处理的请求 10 秒时间完成超过则强制结束。7. 完整代码与关键注释把上面的要点整合起来完整的 gevent 版静态服务器如下from gevent import monkey monkey.patch_all() import os import socket import gevent from gevent.pool import Pool from gevent import signal_handler import signal HOST 0.0.0.0 PORT 8080 DOCUMENT_ROOT ./static POOL_SIZE 2000 CHUNK_SIZE 65536 def parse_request(request_data): 解析 HTTP 请求行返回方法和路径 try: lines request_data.split(b\r\n) method, path, version lines[0].split(b ) return method.decode(), path.decode() except Exception: return None, None def build_response(status_code, content_type, body): 构建 HTTP 响应 status_text {200: OK, 404: Not Found, 405: Method Not Allowed} header fHTTP/1.1 {status_code} {status_text.get(status_code, OK)}\r\n header fContent-Type: {content_type}\r\n header fContent-Length: {len(body)}\r\n header Connection: close\r\n\r\n return header.encode() body def handle_client(client_socket): 处理单个客户端连接 client_socket.settimeout(30) try: request_data client_socket.recv(4096) if not request_data: return method, path parse_request(request_data) if method ! GET: response build_response(405, text/plain, bMethod Not Allowed) client_socket.sendall(response) return if path /: path /index.html filepath os.path.join(DOCUMENT_ROOT, path.lstrip(/)) if not os.path.isfile(filepath): response build_response(404, text/plain, bNot Found) client_socket.sendall(response) return # 根据扩展名判断 Content-Type ext os.path.splitext(filepath)[1].lower() content_type { .html: text/html, .css: text/css, .js: application/javascript, .png: image/png, .jpg: image/jpeg, }.get(ext, application/octet-stream) # 先发送头部再分块发送文件内容 file_size os.path.getsize(filepath) header fHTTP/1.1 200 OK\r\n header fContent-Type: {content_type}\r\n header fContent-Length: {file_size}\r\n header Connection: close\r\n\r\n client_socket.sendall(header.encode()) with open(filepath, rb) as f: while True: chunk f.read(CHUNK_SIZE) if not chunk: break client_socket.sendall(chunk) gevent.sleep(0) except socket.timeout: pass except Exception as e: print(fError handling client: {e}) finally: client_socket.close() def main(): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((HOST, PORT)) server.listen(1024) print(fServing on {HOST}:{PORT}, document root: {DOCUMENT_ROOT}) pool Pool(POOL_SIZE) def shutdown(): print(Shutting down...) server.close() pool.join(timeout10) exit(0) signal_handler(signal.SIGINT, shutdown) while True: try: client, addr server.accept() pool.spawn(handle_client, client) except OSError: break if __name__ __main__: main()几个关键点再强调一下monkey.patch_all()必须在最前面pool.spawn替代threading.Thread文件分块读取并gevent.sleep(0)让出finally里关闭 socket信号处理做优雅退出。8. 从 gevent 版延伸出去还能怎么优化gevent 版静态服务器跑通之后其实还有很多可以深挖的方向。比如用sendfile系统调用实现零拷贝在 Linux 下可以用os.sendfile减少数据在用户态和内核态之间的拷贝次数。再比如加一层 LRU 缓存把频繁访问的小文件缓存在内存里避免每次都读磁盘。还可以把gevent和gunicorn结合用gunicorn的geventworker 模式部署利用多核 CPU。另外如果你对协程调度感兴趣可以读一读 gevent 的源码看看 hub 是怎么用 libev 做事件循环的greenlet 的切换在 C 层面是怎么实现的。这些底层知识对于理解异步编程模型很有帮助。我个人在实际操作中的体会是gevent 最大的价值在于它让异步代码写起来像同步代码降低了心智负担。但代价是 monkey patch 的隐式行为可能带来调试困难所以生产环境里一定要充分测试确保所有 IO 操作都被正确 patch。静态服务器这个项目虽然简单但把 gevent 的调度、协程池、文件 IO、信号处理都串起来了是一个很好的练手切入点。
