Django 高并发通俗讲解用生活中的例子把 Django 高并发这件事说清楚。先搞懂一个问题什么是高并发想象一家餐厅低并发中午来了 3 个客人1 个服务员完全忙得过来高并发突然涌进来 300 个客人还是 1 个服务员——场面失控高并发就是在极短时间内大量用户同时访问你的网站你的系统还能扛住、不崩、响应够快。Django 就像是这家餐厅的厨房问题是Django 这个厨房默认只有一个灶台一次只能炒一道菜。那怎么扛住 300 个客人同时点单答案就是不在一个灶台上死磕而是搞一整套流水线。第 1 层CDN 负载均衡 —— 门口先分流通俗解释你开了一家奶茶店300 人排队。你不可能让 300 人同时挤到柜台前而是门口放个菜单牌CDN很多客人看一眼菜单就走了根本不需要进店安排 3 个点单窗口负载均衡把 300 人分流到 3 个窗口排队而不是挤 1 个窗口技术对应生活例子技术手段作用门口菜单牌CDN内容分发网络图片、CSS、JS 这些静态资源缓存在全球各地的节点用户直接从最近的节点拿根本不打扰 Django3 个点单窗口Nginx / HAProxy负载均衡器把用户请求均匀分配到多个 Django 实例上而不是全压到一个举个例子用户想看一张商品图片 ❌ 没有 CDN请求 → Django → 数据库 → 返回图片慢Django 被拖累 ✅ 有 CDN 请求 → 最近的 CDN 节点直接返回Django 完全不知道这事一句话总结大部分请求在到达 Django 之前就被 CDN 挡掉了Django 只需要处理真正需要动脑子的请求。第 2 层应用服务器 —— 厨房多开几个灶通俗解释这是最关键的一层。Django 默认的运行方式就像一个厨师一次只炒一道菜炒完才炒下一道。客人多了后面的人就得干等。怎么办三个方案方案 A多雇几个厨师多进程厨师1炒宫保鸡丁 厨师2炒鱼香肉丝 厨师3炒麻婆豆腐3 个厨师同时炒效率直接翻 3 倍。方案 B一个厨师用多个灶台协程/异步厨师宫保鸡丁下锅了等收汁的时候…… → 我先去切鱼香肉丝的葱花 → 回头翻一下宫保鸡丁 → 鱼香肉丝下锅一个厨师但利用等待时间同时处理多道菜。这就是gevent 协程的思路——I/O 等待时不闲着。方案 C换成异步厨房ASGI整个厨房重新设计从设计之初就支持多任务并行不只是一道菜还能同时处理客人聊天WebSocket、推送消息等。技术对应生活例子技术手段代码示例多雇厨师Gunicorn 多进程gunicorn -w 44 个进程一个厨师多灶台Gunicorn gevent 协程--worker-class gevent --worker-connections 1000异步厨房Uvicorn ASGIuvicorn myproject.asgi:application举个例子# 方案 A4 个厨师进程每个一次炒一道菜gunicorn myproject.wsgi-w4# → 能同时处理 4 个请求# 方案 B4 个厨师每个能同时照看 1000 个灶台gunicorn myproject.wsgi-w4--worker-class gevent --worker-connections1000# → 理论上能同时处理 4000 个请求I/O 密集场景# 方案 C异步厨房uvicorn myproject.asgi:application--workers4# → 支持 async/await还能搞 WebSocket怎么选你的场景推荐方案打个比方普通网站查数据库为主Gunicorn gevent厨师等菜熟的时候去切菜需要聊天/推送WebSocketUvicorn ASGI厨师一边炒菜一边跟客人聊天大量 CPU 计算图片处理等多进程 sync worker计算密集切菜也得专心别分心一句话总结Django 自己一次只能处理一个请求但我们可以通过多进程或协程让它同时处理成百上千个。第 3 层缓存 —— 做好的菜别重炒通俗解释客人点了 100 杯珍珠奶茶你总不能每杯都从头开始煮茶、加珍珠吧聪明的做法煮一大桶茶放那儿谁来点直接倒一杯。这就是缓存——把重复计算的结果存起来下次直接用不用再算一遍。技术对应生活例子技术手段效果提前煮好的大桶茶Redis 缓存查询结果存好下次直接取菜单上写好的价格全页缓存整个页面存好连渲染都省了冰箱里的预制菜查询缓存复杂查询的结果缓存起来举个例子# 没有缓存每次都有人问今天有什么菜厨师每次都要重新列一遍defmenu(request):dishesDish.objects.filter(availableTrue)# 每次都查数据库returnrender(request,menu.html,{dishes:dishes})# 有缓存第一次列好菜单贴墙上后面的人自己看fromdjango.views.decorators.cacheimportcache_pagecache_page(60*15)# 缓存 15 分钟defmenu(request):dishesDish.objects.filter(availableTrue)# 15 分钟内只查一次returnrender(request,menu.html,{dishes:dishes})效果对比没有缓存 第 1 个客人 → 查数据库50ms→ 渲染页面30ms→ 返回80ms 第 2 个客人 → 查数据库50ms→ 渲染页面30ms→ 返回80ms 第 3 个客人 → 查数据库50ms→ 渲染页面30ms→ 返回80ms ...100 个客人 100 次数据库查询 有缓存 第 1 个客人 → 查数据库50ms→ 渲染30ms→ 缓存结果 → 返回80ms 第 2 个客人 → 直接从 Redis 取1ms→ 返回1ms ⚡ 第 3 个客人 → 直接从 Redis 取1ms→ 返回1ms ⚡ ...100 个客人 只有 1 次数据库查询一句话总结缓存是性价比最高的优化手段让 99% 的请求根本不用碰数据库。第 4 层Celery 异步任务 —— 费时间的活儿后台干通俗解释你正在前台点单突然有个客人说我要一份佛跳墙——这道菜要炖 3 个小时。你总不能让后面 299 个客人等 3 个小时吧聪明做法跟客人说好的做好了通知您然后让后台厨师慢慢炖你继续接待下一个客人。这就是 Celery——把耗时的任务丢到后台去跑不阻塞当前请求。举几个真实的例子场景同步阻塞异步Celery用户注册后发邮件用户等 5 秒邮件发完才能看到注册成功立即返回注册成功邮件后台发生成报表用户盯着转圈圈 30 秒立即返回报表生成中完成后通知您调用第三方 API第三方慢用户一直等丢给 Celery用户先去干别的批量发推送1000 条推送用户等几分钟后台慢慢发用户无感知代码示例# tasks.py — 定义后台任务fromceleryimportshared_taskshared_taskdefsend_welcome_email(user_id):这个函数会在后台 worker 里执行不影响 Web 请求userUser.objects.get(pkuser_id)send_mail(欢迎注册,f你好{user.username}欢迎加入,noreplyexample.com,[user.email],)# views.py — 用户注册defregister(request):userUser.objects.create(username张三,emailzhangsanexample.com)# ❌ 同步用户要等邮件发完才能看到响应# send_welcome_email(user.id)# ✅ 异步立即返回邮件后台慢慢发send_welcome_email.delay(user.id)# .delay() 丢给 Celery 队列returnJsonResponse({status:注册成功邮件稍后送达})流程对比同步方式 用户点注册 → 创建用户 → 发邮件(5秒) → 返回成功 用户感受等了 5 秒 异步方式 用户点注册 → 创建用户 → 丢任务到队列 → 立即返回成功 ↓ Celery worker 后台慢慢发邮件 用户感受瞬间完成 一句话总结凡是超过 200ms 的操作都丢给 Celery 后台跑用户不用等。第 5 层数据库优化 —— 别让仓库成瓶颈通俗解释数据库就像餐厅的仓库。厨师每炒一道菜都要去仓库取食材如果仓库管理混乱厨师就全在排队等取货。两个关键优化优化 1读写分离 —— 拿货和存货分开没有读写分离 所有厨师都去同一个仓库 → 挤爆了 有读写分离 写操作存食材→ 主仓库Primary 读操作取食材→ 副仓库Replica有 3 个 → 读压力分散到 3 个仓库主仓库只管写入# settings.pyDATABASES{default:{# 主库写入HOST:primary-db,},replica:{# 从库读取HOST:replica-db,},}# 自动路由读走从库写走主库classReplicaRouter:defdb_for_read(self,model,**hints):returnreplicadefdb_for_write(self,model,**hints):returndefault优化 2连接池 —— 别每次都重新开门没有连接池 厨师取货 → 开仓门 → 取货 → 关仓门 → 开仓门 → 取货 → 关仓门 ... 光开关门就浪费大量时间 有连接池 仓门一直开着连接复用厨师直接进去取货 → 省掉了反复建立连接的开销# settings.pyDATABASES{default:{CONN_MAX_AGE:60,# 连接保持 60 秒复用}}优化 3ORM 查询优化 —— 别一个一个拿# ❌ N1 问题查 100 本书和作者要查 101 次数据库booksBook.objects.all()# 第 1 次查询forbookinbooks:print(book.author.name)# 每本书都查一次作者 → 100 次查询# ✅ select_relatedJOIN 查询1 次搞定booksBook.objects.select_related(author)# 1 次查询JOIN 出作者信息forbookinbooks:print(book.author.name)# 不再查数据库打个比方N1 问题就像你炒 100 道菜每道菜都跑一趟仓库取一种调料。select_related就是一次性把 100 道菜的调料全拿齐。一句话总结数据库是整个系统最容易成为瓶颈的地方读写分离 连接池 查询优化三管齐下。第 6 层水平扩展 —— 开分店通俗解释一家店生意太好厨师加到极限了还是忙不过来怎么办开分店。┌─ Django 店 14 个厨师 Nginx 门卫 ────┤─ Django 店 24 个厨师 ├─ Django 店 34 个厨师 └─ Django 店 N4 个厨师 │ 共享一个大仓库数据库 Redis关键前提Django 是无状态的——它不记住某个特定用户的状态Session 存在 Redis 里所以任何一个 Django 实例都能处理任何一个用户的请求。这就像连锁餐厅不管你去哪家分店刷会员卡都能查到你的信息因为会员信息存在总部服务器而不是各家分店。一句话总结Django 无状态 可以无限加机器 想要多少并发就加多少台。终极对比一台 runserver vs 生产级架构维度python manage.py runserver生产级架构服务器Django 自带的开发服务器Gunicorn(gevent) / Uvicorn进程数1 个多进程 × 多协程缓存无Redis 全页缓存 查询缓存异步任务无全同步Celery 消息队列数据库单库每次新建连接读写分离 连接池静态资源Django 自己处理CDN 全球分发负载均衡无Nginx 多实例分流大致并发~10 个请求10,000 请求一句话总结全文Django 本身就像一个能力很强但一次只能做一件事的厨师。它的高并发能力不靠自己而是靠一套组合拳门口分流CDN→ 多灶台Gunicorn/gevent→ 做好的菜不重炒缓存→ 费时间的活后台干Celery→ 仓库管理优化读写分离→ 开分店水平扩展每一层都在帮 Django 分担压力最终扛住高并发。
