🧭 前言:你写功能,他们在聊"系统扛不住了"
身为一名前端,你也许每天写的最多的词是 onClick
,提 PR 最多的改动是"按钮颜色和边距"。
可就在你写按钮时,身后的后端小哥和运维师傅经常蹙眉低语:
- "这波流量吞吐量顶不住了......"
- "CDN 命中率太低,回源爆炸了。"
- "线程池全满了,Redis 都抗不住了。"
你只想说:哥,我是前端,你说这些干嘛?
但今天起你就明白了:写前端的你,知道后端在扛啥,才能写出真正"系统友好"的代码。
📦 一、吞吐量:服务器吃饭的速度(Throughput)
✳️ 什么是吞吐量?
吞吐量就像饭店的"出菜速度"。后端服务器就像后厨,前端发一个请求,相当于顾客点了一道菜------后厨开始炒、做、端。
如果服务器每秒能处理 100 个请求,我们说吞吐量是 100 RPS(Requests Per Second) 或 TPS(Transactions Per Second) 。
💬 举个栗子:
京东秒杀开始时每秒来了 5 万个下单请求,后端吞吐量只能抗住 2 万?对不起,剩下的请求只能掉单或排队,甚至直接炸服务。
🧠 你作为前端能感知什么?
- 接口突然超时、返回慢;
- 页面加载卡顿、转圈圈;
- 明明前端逻辑没改,但线上"异常率"暴涨。
可能就是服务吞吐顶不住了。
🚚 二、带宽:服务器搬快递的速度(Bandwidth)
✳️ 什么是带宽?
带宽就像搬货的"车道宽度"。数据从服务器运到用户设备,就是一趟物流。
- 带宽大 = 数据通道多、每秒传得多;
- 带宽小 = 一堆数据塞车,堵死。
举个常见例子:你点开一个图文详情页,接口返回 JSON + 图片资源共 5MB,用户用的还是移动 5Mbps 网络,那加载时间就别想快。
🧠 前端要注意什么?
- 图片压缩 、懒加载 、接口字段裁剪,都是帮服务器减负;
- 合理配置 CDN、Gzip 压缩,带宽利用率翻倍提升;
- 前端请求一次拉回 10 万条数据,这不是带宽炸,是你自己在炸。
🧑🍳 三、CPU 核数:能开几锅炒菜同时做(Server Cores)
✳️ 多核有什么用?
每一个 CPU 核心就像一个厨师。用户请求越多,后端线程数也就越多,这时候要分得出够多的"锅"。
假如服务器是 4 核,而服务框架默认开了 100 个线程,那就成了 4 个厨师要轮流炒 100 个菜,调度频繁,性能下降。
🧠 前端该关心吗?
当然:
- 用户量猛增,接口开始变慢,别只说"接口卡",可以问一句:"是不是核不够线程卡死了?"
- 前端请求频率太高?容易耗尽线程池,引发线程争抢。
- 异步队列、并发上传、WebSocket 心跳,都可能加大服务线程压力。
🏬 四、并发连接数:服务器"服务窗口"的上限
✳️ 并发连接数是啥?
服务器支持的"同时在线"数量是有限的。每一个活跃连接都占用一定内存、线程或 socket 资源。
比如:
- Nginx 的连接数默认上限是 1024;
- Tomcat 默认最大线程数 200。
如果你写了个"实时弹幕系统",一上万人并发接入,服务撑不住不是 bug,而是连接数爆了。
🧠 你能优化什么?
- 前端请求节流,避免一秒发十次;
- 尽量复用连接、启用长连接;
- WebSocket 做好心跳频率、断线重连限制;
- 用户在线列表分页获取,而非一次全量同步。
🧯 五、内存:后厨的冰箱容量够不够装?
✳️ 为什么内存这么重要?
服务要处理请求,临时缓存数据、会话上下文、对象引用、图片缓存......全都存在内存里。
- 内存够大 → 可以一次处理更多数据;
- 内存太小 → GC 频繁 or 直接 OOM 崩溃。
有的接口返回超大数组,或者 Redis 加载的数据一大堆,内存直接炸裂。你写的那个"无限滚动加载",就是这场灾难的导火索😅
💥 六、限流、熔断、降级:系统压力大时的"自保手段"
名词 | 类比 | 技术意义 |
---|---|---|
限流 🚦 | 地铁限流口 | 控制高峰流量,避免系统雪崩 |
熔断 💣 | 跳闸保护器 | 某个接口失败率高时主动断开,不拖累全局 |
降级 ⛳ | 白开水应急 | 功能暂时不可用,返回默认值 or 占位提示 |
🧠 你该做什么?
- 用户操作频繁触发接口?前端做节流;
- 接口失败后别反复 retry,加入指数退避;
- 配合降级显示兜底 UI,用户体验不会炸锅。
📈 七、性能指标总览表:让你会议时也能插上嘴
指标 | 含义说明 |
---|---|
QPS / TPS | 每秒请求处理数(吞吐量) |
RT | 请求响应耗时 |
P99/P95 | 99%/95% 请求耗时区间 |
错误率 | 请求失败比例,重要预警信号 |
带宽使用率 | 是否接近上限,是否"快递堵车" |
CPU占用率 | 超过80%基本等于报警了 |
内存使用率 | 看有没有泄漏或爆内存的风险 |
Redis命中率 | 缓存是否在帮你挡流量 |
🔧 八、你作为前端可以优化的点
场景 | 优化建议 |
---|---|
接口多 | 合并请求、懒加载、延迟请求 |
接口大 | 字段裁剪、分页返回 |
静态资源慢 | 启用 CDN、Gzip、缓存控制 |
接口频繁触发 | 加入防抖、节流控制 |
用户多页面在线 | 限制心跳频率、共享缓存、懒初始化 |
🧠 结语:别做只会点按钮的前端,做个懂锅气的技术人
你不需要部署服务,但你需要知道服务崩在哪。
你不一定要写线程池,但你得知道你发的每个请求,是一个线程要"炒菜"。
你不懂限流熔断的实现没关系,但你知道它存在、什么时候触发、前端该配合什么,就是职业素养的体现。
😎 懂业务的前端是合格的,懂架构的前端是稀缺的。