做技术的朋友都知道，分布式系统是解决高并发、大数据难题的“终极武器”。但很多人一聊到分布式，满嘴都是“微服务”“集群”，却连最底层的设计指标都说不清楚。今天我们就用最干的干货，拆解分布式系统的四大核心指标：性能、资源、可用性、可扩展性。看完这篇文章，你至少能避开80%的架构设计坑！
一、性能：不是“快”就完事了
性能是用户最直接的体验，但很多人只知道“响应快”，却忽略三个关键维度：
吞吐量（TPS/QPS/BPS）
- TPS
（每秒事务数）：电商秒杀场景下，TPS直接决定能卖出多少单。 - QPS
（每秒查询数）：搜索引擎每秒能处理多少用户搜索请求。 - BPS
（每秒比特数）：视频网站每秒能传输多少数据，决定卡不卡顿。
实战建议：TPS和QPS往往矛盾。比如数据库事务（TPS）高了，查询（QPS）可能下降，需要根据业务优先级做取舍。 响应时间（RT）
用户从点击到看到结果的时间。超过200ms用户会觉得“慢”，超过2s可能直接流失。
案例：某电商大促时，RT从500ms优化到150ms，转化率提升30%。完成时间
系统真正处理完一个任务的总耗时。比如：-
大数据任务：10TB日志分析，单机跑3天，分布式集群30分钟搞定。 -
视频转码：一部4K电影，单机转码2小时，分布式拆分到10台机器，12分钟完成。
核心逻辑：用“空间换时间”，堆机器解决长尾耗时任务。
二、资源占用：省下的每一分钱都是利润
资源利用率直接决定成本。很多团队只关注CPU、内存，却忽略两个隐藏指标：
空载资源消耗
系统啥也不干时占用的资源。比如：-
一个空跑的程序占用20% CPU？多半代码有BUG。 -
某国产数据库空载内存占用是MySQL的3倍？技术选型时要慎重。
黄金标准：空载资源越低，系统设计越优雅。 满载资源消耗
系统全力运行时需要多少“弹药”。比如：-
处理1万QPS需要多少台服务器？ -
同等硬件下，A系统能扛1万并发，B系统只能扛5千，高下立判。
省钱技巧：用满负载测试倒推机器采购数量，避免资源浪费。
三、可用性：99%和99.99%的差距有多大？
系统挂了就是灾难，但“高可用”不能只靠喊口号，得算清楚账：
可用性公式
- 时间维度
： 可用性 = (总运行时间 - 故障时间) / 总运行时间
比如全年故障4小时，可用性≈99.95%（俗称3个9）。 - 请求维度
： 可用性 = 成功请求数 / 总请求数
比如1000次支付请求失败10次，可用性99%。 容灾等级对照表
可用性 年故障时间 适用场景 99% 87.6小时 内部管理系统 99.9% 8.76小时 普通电商 99.99% 52分钟 支付系统 99.999% 5分钟 航空调度/核电站 血泪教训：某P2P平台因可用性不达标，故障1小时损失5000万用户。
四、可扩展性：加机器就能解决问题？太天真！
分布式系统的灵魂在于“扩展性”，但盲目堆机器可能适得其反：
垂直扩展 vs 水平扩展
- 垂直扩展（升级单机）
：CPU从8核升到32核，内存从32G升到128G。
优点：简单粗暴；缺点：成本指数级增长，且存在物理极限。 - 水平扩展（加机器）
：从10台服务器扩展到100台。
优点：理论上无限扩展；缺点：架构复杂度飙升。 线性扩展才是王道
理想情况：10台机器扛1万QPS，100台扛10万QPS。但现实中，由于网络延迟、数据一致性等问题，实际可能只能达到80%线性度。
避坑指南：-
无状态服务（如Web服务器）更容易水平扩展。 -
有状态服务（如数据库）需借助分库分表、一致性哈希等方案。 扩展性公式
- 吞吐量提升
： 扩展后TPS / 扩展前TPS - 完成时间缩短
： 扩展前耗时 / 扩展后耗时
案例：某社交平台用户量暴增10倍，通过分片存储+读写分离，用50台机器实现吞吐量线性增长。
结语：指标是死的，业务是活的
分布式系统的四大指标（性能、资源、可用性、可扩展性）就像汽车的四个轮子，缺一不可。但现实中，没有完美的方案，只有适合当前业务的权衡：
-
金融系统优先保可用性（宁可慢也不能错）； -
实时通信优先保性能（延迟必须压到毫秒级）； -
初创公司优先保资源成本（先用最少的机器扛住）； -
大厂核心系统必须兼顾扩展性（随时应对流量暴增）。
下次设计架构时，不妨先问自己：我的业务现阶段最需要牺牲哪个指标？ 想清楚这个问题，你已经赢了大多数人。
