gunicorn启动命令

高并发不是选修课，是婚礼前夜的必修题

上周五晚上十一点半，我一边在Mac上调试一个异步任务队列，一边在手机上跟婚庆公司扯皮“主舞台灯光能不能再暖一点”。电脑里跑着压测脚本，屏幕上QPS卡在8000死活上不去，心里却在想：这系统要是像我的婚纱照P图一样糊弄一下就能过就好了。

但现实很骨感。我们组负责的电商活动系统，要在下个月大促期间扛住预估50万QPS的流量洪峰。而我现在，一个即将步入婚姻殿堂、每天在需求评审和试妆之间来回横跳的程序媛，不得不硬着头皮啃高并发这块硬骨头。

说来惭愧，在这个组干了快两年，之前一直用Python写些CRUD接口，觉得asyncio就是高并发的全部。直到去年双11复盘会上，运维甩出一张火焰图：“你们那个下单服务，线程池打满，数据库连接耗尽，用户卡在‘支付中’界面十分钟——人家以为钱扣了，结果没下单成功。” 那一刻，我真想钻进Mac的Touch ID孔里躲起来。

痛定思痛，我决定系统性补课。翻遍了组里老大的书架，借了三本经典：《Designing Data-Intensive Applications》（DDIA）、《高性能MySQL》，还有那本被翻得卷边的《Python高性能编程》。别笑，虽然我是Python出身，但在高并发场景下，光靠GIL和requests可撑不起百万级流量。

从理论到落地：我的综合优化路径

高并发系统设计，不是堆服务器就完事了。它是一套综合工程，涉及架构、缓存、数据库、消息队列、限流熔断……每一环都可能成为瓶颈。下面是我这段时间摸爬滚打总结的几个关键点。

1. 架构分层：别让所有请求都砸到数据库

最开始我们的下单接口是这样的：

def place_order(user_id, items):
    # 检查库存
    for item in items:
        stock = Stock.objects.get(product_id=item.id)
        if stock.quantity < item.qty:
            raise InsufficientStock()
    # 扣减库存
    for item in items:
        Stock.objects.filter(product_id=item.id).update(quantity=F('quantity') - item.qty)
    # 创建订单
    Order.objects.create(user_id=user_id, items=items)

看着没问题？但高并发下，成千上万个请求同时读写同一商品库存，数据库直接锁表。有一次压测，PostgreSQL的CPU飙到98%，连接池爆满，整个服务雪崩。

后来我们做了三层拆解：

• 前置校验：用Redis做库存预占（INCRBY + 过期时间），快速拒绝超卖请求；
• 异步落单：通过Kafka将订单创建请求丢进队列，由消费者异步处理；
• 最终一致性：对账服务定时比对Redis与DB数据，修复不一致。

改完之后，核心接口响应时间从1200ms降到180ms，数据库压力骤降70%。

2. 缓存策略：别让热点key把你烧穿

高并发下，缓存击穿、穿透、雪崩是三大噩梦。我们曾因为一个爆款商品ID被疯狂查询，导致Redis集群某个节点被打垮。

解决方案？多管齐下：

• 布隆过滤器防穿透：非法ID直接拦截；
• 互斥锁+本地缓存防击穿：比如用aiocache加一层内存缓存，配合Redis锁；
• 随机过期时间防雪崩：原设300秒过期，改成300 + random(0,60)；

代码片段参考：

from aiocache import cached, Cache

@cached(ttl=300, cache=Cache.MEMORY)
async def get_product_info(product_id):
    # 先查本地缓存，再查Redis，最后回源DB
    return await ProductDAO.fetch(product_id)

实测后，Redis QPS从25万降到9万，而且波动平滑多了。

3. 数据库优化：索引不是万能的，但没有索引是万万不能的

我们一度迷信“加索引就能提速”，结果有一次给一个高频更新的字段加了复合索引，导致写性能暴跌。DBA找上门来：“你这索引比表还大，知道InnoDB的change buffer都快溢出了吗？”

血泪教训告诉我：

• 读多写少：大胆加索引；
• 写多读少：慎用索引，考虑归档或冷热分离；
• 大表分页：别用OFFSET 100000，改用游标或时间戳分页；
• 连接池配置：max_connections不是越大越好，要结合CPU核数和I/O模型。

我们用pg_stat_statements分析慢查询，砍掉了三个冗余索引，把两个全表扫描改成了覆盖索引查询，TPS提升了40%。

4. Python也能扛高并发？关键看你怎么用

很多人说Python不适合高并发，其实要看场景。我们用FastAPI + Uvicorn + Gunicorn组合，配合async/await，在合理设计下完全能扛住数万QPS。

关键配置如下：

gunicorn -k uvicorn.workers.UvicornWorker \
         --workers 4 \
         --worker-connections 1000 \
         --timeout 30 \
         app:app

注意：

• workers数量 ≈ CPU核心数；
• worker-connections 控制每个worker的并发连接；
• 所有I/O操作必须异步（用httpx代替requests，asyncpg代替psycopg2）；

压测数据显示，单机（8C16G）稳定输出2.3万QPS，P99延迟<200ms。够用！

踩过的坑，都是未来的路

当然，过程不是一帆风顺。有次上线新缓存策略，忘了设置空值缓存，结果一个恶意请求刷了几百万次无效ID，Redis内存瞬间打满。运维半夜打电话：“你是不是又在试婚纱的时候写了bug？”

还有一次，异步任务消费者没做幂等，重复创建了订单。财务小姐姐拿着Excel来找我：“亲，这个用户付了一次钱，下了三次单，退谁的？” 我当场社死。

这些事故让我明白：高并发系统不是炫技，而是稳字当头。限流（Sentinel）、熔断（Hystrix模式）、降级（返回兜底数据）、监控（Prometheus + Grafana）一个都不能少。

总结：高并发是一场系统性的修行

回头看看，从只会写Flask视图函数，到现在能设计分层削峰架构，我靠的不是天赋，而是被线上事故逼出来的求生欲。那些深夜加班、被产品经理催、被运维diss的日子，反而成了最好的老师。

如果你也在备婚（或者备考、备离职），别慌。技术这东西，只要肯啃，总能拿下。就像我老公说的：“你连婚纱都能挑出300个细节，还搞不定一个高并发系统？”

最后推荐几本对我帮助巨大的书籍：

• 《Designing Data-Intensive Applications》：高并发圣经，值得反复读；
• 《高性能MySQL》：DB优化必备；
• 《Python高性能编程》：破除“Python慢”的迷思，教你用Cython、Numba、asyncio榨干性能。

现在，我的系统已经通过了全链路压测，QPS稳定在52000+。而我的婚纱，也终于定下来了——象牙白，带珍珠，不闪但耐看。

就像好的系统，不一定炫酷，但一定要稳、准、狠。

对了，下周婚礼，欢迎来喝喜酒。前提是你保证不在敬酒时问我：“你们系统怎么做的限流？” —— 那天我真的只想做个幸福的新娘，而不是一个debug中的程序媛。