python aiohttp

### 聊聊 Python 的 aiohttp一个写异步 HTTP 的家伙作为 Python 开发者平常写网络请求最头疼的是啥等 响应 的时候程序卡在那儿啥也干不了。十年前大部分人会甩一句“用 gevent 啊”或者“开线程池”。但现在回头看看aiohttp 成了很多人方案里的主角。它不是新鲜玩意儿2014 年左右就有了但直到 Python 3.5 正式支持 async/await 语法后它才真正变得顺手。1它到底是什么aiohttp 就是一组用来处理 HTTP 的异步工具库。说简单点它同时保留了两个身份一个是可以写异步客户端的库另一个是能跑异步服务端的框架。比如你用 requests 写过爬虫那 aiohttp 的客户端版就是它的异步替代品。如果你用过 Flask 或者 FastAPIaiohttp 的服务端能力相当于一个轻量级的替代品。有个细节值得注意——很多人以为它只能发请求其实它能同时做服务端。比如你平时写的一个小工具需要对外提供一个 RESTful 接口同时又需要不间断拉取别的服务的数据这时候 aiohttp 就特别合适因为一个事件循环里就能跑两套逻辑不用开两个进程来回传数据。2它能做什么简单列举几个典型场景写高并发爬虫。一个简单的例子就是爬取几百个网页。用 requests 写开几十个线程内存容易爆管理也麻烦。用 aiohttp一个协程搞定线程数基本不变但请求并发数能调到上千。很多数据采集工具底层的 HTTP 请求就是封装了 aiohttp。写异步 API 网关或代理。比如需要将外部 API 的数据透传给前端同时做缓存、限流、合并请求aiohttp 的服务端模式就特别顺手。国内不少大厂的中台化网关一些核心路由层用的就是 aiohttp。写 WebSocket 推送服务。aiohttp 原生支持 WebSocket长链接管理非常简单。像一些即时聊天组件、实时数据看板、交易推送轻量级的场景用它就够了撑个几千链接问题不大。做微服务内部通信。尤其是基于 HTTP/2 的跨服务调用aiohttp 也算顺手。虽然现在很多人转投 gRPC但 aiohttp 的侵入性更小搭个小服务几十行代码搞定非常适合尝试新想法。3怎么使用大多数人刚接触 aiohttp 时会先看到一长串的异步代码感觉和 requests 差别很大。实际上核心只有一个所有涉及 I/O 的操作发送、接收、连接建立都需要用 await。客户端用法以拉取一个典型的 JSON API 为例importaiohttpimportasyncioasyncdeffetch_data(url):asyncwithaiohttp.ClientSession()assession:asyncwithsession.get(url)asresp:returnawaitresp.json()asyncdefmain():urlhttps://api.github.com/users/octocatdataawaitfetch_data(url)print(data[login])asyncio.run(main())这段代码看起来简单其实藏了一个细节aiohttp.ClientSession 是需要复用的。每次请求都创建一个新 session会导致每次都要重新建立 SSL 握手和连接池效率就没了。服务端用法比如写一个小接口处理 JSONfromaiohttpimportwebasyncdefhandle_user(request):user_idrequest.match_info.get(id)# 假设这里去数据库查returnweb.json_response({user_id:user_id})appweb.Application()app.router.add_get(/user/{id},handle_user)web.run_app(app,host127.0.0.1,port8080)这里的 app 对象和 Flask 和 FastAPI 的 app 类似但底层基于 asyncio路由匹配、请求解析、响应序列化都跑在同一个事件循环里。4最佳实践说了这么多我踩过的坑帮各位整理几处。连接池大小要主动设。aiohttp 的 ClientSession 默认连接池上限是 100并发多的话很容易耗尽。经验值是单机高并发时开到 300-500但别无限量增大否则本机连接数和内存会扛不住。合理做法在创建 session 时传入connector aiohttp.TCPConnector(limit500)。给 session 加超时控制。aiohttp 默认不设总请求超时。遇到个别响应慢的 API 会把整个爬虫拖垮。建议给ClientTimeout(total30)统一设一个软超时出现超时了平滑重试。小心异常处理。aiohttp 的异常体系比 requests 复杂点。客户端模式常见的异常有aiohttp.ClientConnectorError连不上服务器、asyncio.TimeoutError超时、aiohttp.ClientResponseError状态码异常。建议在每个重要请求外层加try/except捕获。避免在循环中重复创建 session。很多人第一次写 aiohttp 代码时会把async with ClientSession()放在每一个请求里面。但这会导致每个请求都重新创建连接池严重降低效率。正确做法是全局一个 session或者一个 session 对象复用一段时间后销毁重开。服务端模式下尽量用中间件解耦。比如日志打印、请求验证、限流都可以通过web.middleware装饰器加在 app 上而不是在每个处理函数里重复写。5和同类技术对比在实际选型时经常有人会拿 aiohttp 和几个东西对比。对比 requests concurrent.futures。后者属于传统阻塞式 I/O 加线程池。优点是理解和迁移成本低适合只处理几十个并发的小脚本。一旦并发超过上千线程切换开销明显而且 Python 的 GIL 在线程池场景下依然会带来一定限制。相反 aiohttp 本身就是单线程非阻塞大量长连接场景下内存和调度开销都更低。对比 httpx。httpx 是最近几年兴起的库既支持同步也支持异步而且 API 设计更接近 requests学习曲线平滑。不过它的异步底层底层依赖 httpcore而 aiohttp 完全基于 asyncio 和 C 扩展底层由 uvloop/cython 加速。实测下来httpx 在高并发场景下性能和 aiohttp 差距不大但资源占用上 httpx 比 aiohttp 高一点尤其连接数一上去内存增长更快。所以超大规模爬虫、网关这类场景aiohttp 仍有一席之地。对比 FastAPI。FastAPI 作为服务端框架它的底层是 Starlette也是基于 asyncio而 Starlette 又依赖uvicorn等 ASGI 服务器。aiohttp 则直接自带 web 服务器基于asyncio的底层 I/O。如果只是想写一个小型代理或工具类服务aiohttp 的起步更快不用折腾 uvicorn/gunicorn。但 FastAPI 的优势在于自动生成 API 文档和数据校验Pydantic适合写复杂的企业级应用。对比 gRPC。如果谈的是跨语言、跨服务的高性能 RPC 通信gRPC 在序列化效率和协议定义方面都比 aiohttp 更专业。但 aiohttp 胜在 HTTP 生态兼容和后端接起来不需要定义 proto 文件参数用 JSON 传递对前端和测试更友好。大部分内部工具选 aiohttp 比 gRPC 快得多代价小。最后说句心里话aiohttp 是一种“学一点就能干很多”的库。但千万别试图用它做所有事比如跑大流量文件上传、长连接消息队列还是得配合其他组件。关键是在 I/O 密集型场景下它能给你省下不少服务器和开发成本。希望这些内容能帮各位在写下一个异步项目时心里更有数。