一个被"高并发"吓到的程序员
小张最近很焦虑。
公司产品要做推广，预计会带来 10 倍的流量增长。他开始疯狂刷技术博客，看到的全是：
- "如何设计能抗住亿级并发"
- "分布式缓存实战"
- "一致性哈希在负载均衡中的应用"
越看越慌。"我现在的系统连 1000 QPS 都跑不满，真的能扛住吗？要不要现在就重构？"
他的老板知道了，说了一句话： "先别慌，我们先看看现在能扛多少。"
压测结果出来了：现有系统能抗住 5000 QPS。而他们预估的最高峰值，是 2000 QPS。
小张长舒一口气。
01 为什么新手会被"高并发"吓到？
三个主要原因：
原因一：信息过载
打开技术博客，10 篇里有 8 篇在讲高并发优化。好像不提"亿级并发"，就不是正经技术文章。
原因二：混淆场景
大厂分享的架构，是为日活千万级设计的。你一个小系统，非要照搬这套，不是杀鸡用牛刀，是杀鸡用屠龙刀。
原因三：不知道"够用"是什么标准
没有量化目标，就不知道什么算"扛住了"。于是倾向于过度准备。
02 先搞清楚：你真的需要处理高并发吗？
在谈高并发之前，先回答这几个问题：
你的流量是多少？
| 日活用户 | 预估峰值 QPS | 典型场景 |
|---|---|---|
| < 1000 | < 100 | 内部工具、小众产品 |
| 1000-10000 | 100-1000 | 成长型产品 |
| 10000-100000 | 1000-5000 | 成熟产品 |
| 100000+ | 5000+ | 大流量产品 |
你的请求特征是什么？
- 读多写少：社交 feed、信息流 → 优先考虑缓存
- 写多读少：日志系统、传感器数据 → 优先考虑写入吞吐量
- 读写均衡：电商、交易系统 → 需要综合优化
你的 SLA 要求是什么？
- 99% 可用 = 每天最多 14 分钟不可用
- 99.9% 可用 = 每天最多 1.5 分钟不可用
结论：如果你的日活不过万，峰值 QPS 不过千，先别急着搞高并发。先确保系统稳定、数据不丢，比什么都强。
03 简单实用的系统设计思路
思路一：先让单机能扛住
❌ 错误做法
"分布式才是趋势，我直接上微服务集群。"
✅ 正确做法
先压测单机性能，找到瓶颈点，优化到单机扛不住为止。
实操步骤：
- 1.用 wrk 或 ab 压测当前系统
- 2.观察 CPU、内存、IO 使用率
- 3.定位瓶颈：数据库？代码逻辑？网络？
- 4.针对瓶颈优化
一个经验法则：90% 的性能问题，优化 1-2 个瓶颈就能解决。常见的瓶颈：
- 数据库慢查询（加索引、优化 SQL）
- 串行逻辑（改并行）
- 同步阻塞（改异步）
思路二：用好缓存这张牌
缓存是最简单、最有效的性能优化手段。
什么时候用缓存？
- 数据读多写少
- 一致性要求不高（允许短暂不一致）
- 数据量不会无限增长
怎么用？
三级缓存策略：
- 1.本地缓存（进程内）：热点数据、防抖
- 2.分布式缓存（Redis/Memcache）：跨进程共享
- 3.CDN 缓存：静态资源、页面缓存
一个常见问题：缓存雪崩
大量缓存同时失效，导致大量请求打到数据库。
解决方案：
- 缓存过期时间加随机值
- 保证数据库能扛住缓存失效的情况
- 用分布式锁保护数据库
思路三：异步处理非核心流程
❌ 错误做法
"所有流程都同步处理，这样才能保证一致性。"
✅ 正确做法
识别核心流程和非核心流程，非核心流程异步化。
实操例子：用户下单
同步部分（必须成功）：
- 1.库存扣减
- 2.订单创建
- 3.支付扣款
异步部分（可以延迟）：
- 1.发送通知
- 2.更新推荐系统
- 3.数据分析报表
- 4.积分计算
异步化的好处：
- 降低接口响应时间
- 削峰填谷
- 提高系统吞吐量
异步化工具选择：
- 消息队列：Kafka、RabbitMQ、RocketMQ
- 轻量级：Redis 队列、Delayed Job
思路四：数据库才是大多数系统的瓶颈
很多团队花大量时间优化代码，却忽视了数据库。
优化数据库的优先级：
| 优先级 | 优化项 | 投入产出比 |
|---|---|---|
| P0 | 加索引 | ⭐⭐⭐⭐⭐ |
| P1 | 慢查询优化 | ⭐⭐⭐⭐ |
| P2 | 连接池配置 | ⭐⭐⭐ |
| P3 | 分库分表 | ⭐⭐ |
加索引的正确姿势：
sql
sql
-- 看执行计划
EXPLAIN SELECT * FROM orders WHERE user_id = 123;
-- 加索引
CREATE INDEX idx_user_id ON orders(user_id);不要做的事：
- 上来就分库分表（99% 的系统不需要）
- 在索引列上做函数运算
- 用 LIKE '%xxx%' 查询
04 性能优化优先级对比
| 优先级 | 优化方向 | 适用场景 | 投入产出比 |
|---|---|---|---|
| 1 | 单机优化 | 所有场景 | ⭐⭐⭐⭐⭐ |
| 2 | 缓存 | 读多写少 | ⭐⭐⭐⭐ |
| 3 | 异步化 | 非核心流程 | ⭐⭐⭐⭐ |
| 4 | 数据库优化 | 有慢查询 | ⭐⭐⭐⭐ |
| 5 | 水平扩展 | 单机已达上限 | ⭐⭐⭐ |
| 6 | 架构重构 | 业务复杂度上升 | ⭐⭐ |
核心原则：按优先级来，别跳级。
05 给新手的行动指南
第一步：量化当前系统能力
用压测工具测出：
- 单机 QPS 上限
- 平均响应时间
- 错误率
推荐工具：
- wrk / ab：HTTP 压测
- mysqlslap：数据库压测
- redis-benchmark：缓存压测
第二步：设置容量目标
基于业务预估，设置目标：
- 目标 QPS 是多少？
- 响应时间 SLA 是什么？
- 可用性要求是多少？
第三步：识别瓶颈，逐步优化
从优先级高的开始：
- 1.优化数据库慢查询
- 2.增加缓存
- 3.异步化非核心流程
- 4.水平扩展
第四步：建立监控和告警
优化后要能观测效果：
- 关键指标：QPS、RT、错误率
- 资源指标：CPU、内存、IO
- 业务指标：订单量、转化率
06 总结
高并发不是洪水猛兽。大多数系统的问题，不是扛不住高并发，而是没做好基本功。
记住三句话：
1. 先测再优化，别拍脑袋。
2. 缓存是银弹，用对地方才是。
3. 数据库是根本，优化索引最有效。
下次再听到"高并发"三个字，先别慌。问自己：
- 我现在的系统能扛多少？
- 我的目标是多少？
- 差距有多大？
差距大，再考虑复杂方案。差距小，单机优化 + 缓存 + 异步 就够了。
简单实用，永远优于过度设计。
如果你觉得这篇文章有用，欢迎转发给需要的朋友。