附录 指标与组件对照表
附录 指标与组件对照表
本附录汇总全教程出现的核心指标定义和高并发组件对照，便于查阅与 SEO。
核心指标
| 指标（English） | 释义 |
|---|---|
| QPS（每秒请求数） | 单位时间内系统处理的请求数量，衡量处理能力 |
| TPS（每秒事务数） | 单位时间内处理的事务数，一个事务可能含多个请求 |
| RT（响应时间） | 请求从发出到收到响应的耗时，衡量用户体验 |
| P50/P95/P99（分位数） | 延迟的分位统计，P99 反映长尾用户体验 |
| 吞吐量（Throughput） | 单位时间处理的数据量或工作量 |
| 错误率（Error Rate） | 失败请求占总请求的比例 |
| 可用性（Availability） | 系统正常运行时间占比，用几个 9 衡量 |
| SLO（服务等级目标） | 对延迟、错误率等指标的明确承诺值 |
| RTO（恢复时间目标） | 故障后允许的最长恢复时间 |
| RPO（恢复点目标） | 故障后允许的数据丢失量 |
流量治理
| 术语（English） | 释义 |
|---|---|
| 负载均衡（Load Balancing） | 把请求按策略分发到多台后端服务器 |
| 四层负载均衡（L4） | 基于IP和端口的传输层分发，速度快 |
| 七层负载均衡（L7） | 基于HTTP等应用层信息的分发，更灵活 |
| 一致性哈希（Consistent Hashing） | 按请求标识哈希分发，保证会话粘性 |
| CDN（内容分发网络） | 静态资源缓存在边缘节点加速访问 |
| WAF（Web应用防火墙） | 在接入层拦截恶意请求 |
| 限流（Rate Limiting） | 控制请求速率，超限拒绝或排队 |
| 令牌桶（Token Bucket） | 固定速率发令牌的限流算法，允许突发 |
| 漏桶（Leaky Bucket） | 固定速率漏出的限流算法，严格平滑 |
| 熔断（Circuit Breaking） | 下游故障时主动切断调用，快速失败 |
| 降级（Degradation） | 压力时牺牲非核心功能保核心 |
应用与数据层
| 术语（English） | 释义 |
|---|---|
| 无状态化（Stateless） | 实例不存业务状态，状态全部外置 |
| 弹性伸缩（Auto Scaling） | 根据负载自动增减实例 |
| HPA（水平Pod自动伸缩） | Kubernetes根据指标自动扩缩容 |
| 消息队列（Message Queue） | 异步解耦生产者和消费者的中间件 |
| 削峰填谷（Peak Shaving） | 用队列缓冲尖峰流量，按能力消费 |
| 幂等性（Idempotency） | 重复执行不产生副作用的性质 |
| 多级缓存（Multi-level Cache） | 本地缓存加分布式缓存的分层缓存 |
| 缓存击穿（Cache Breakdown） | 热点key过期瞬间并发打到数据库 |
| 缓存穿透（Cache Penetration） | 查不存在的数据绕过缓存打到库 |
| 缓存雪崩（Cache Avalanche） | 大量key同时过期或缓存宕机 |
| 读写分离（Read-Write Split） | 主库写从库读，分散读压力 |
| 分库分表（Sharding） | 把数据水平拆分到多个库表 |
可靠性与运维
| 术语（English） | 释义 |
|---|---|
| 故障域（Failure Domain） | 一组会一起故障的资源 |
| 同城双活（Active-Active） | 同城两机房同时服务互备 |
| 异地多活（Multi-site Active） | 异地多机房同时服务防城市级灾难 |
| 混沌工程（Chaos Engineering） | 主动注入故障验证系统韧性 |
| 爆炸半径（Blast Radius） | 故障注入实验的影响范围 |
| 可观测性（Observability） | 从外部行为推断内部状态的能力 |
| Metrics（指标） | 聚合的时序数值数据 |
| Logs（日志） | 离散的事件记录 |
| Traces（链路） | 请求在分布式系统的完整路径 |
| Trace ID（追踪标识） | 贯穿请求所有服务的唯一标识 |
| 容量规划（Capacity Planning） | 预测资源需求并提前准备 |
| 压测（Stress Testing） | 主动加压确定系统极限 |
| MTTR（平均恢复时间） | 故障从发生到恢复的平均耗时 |
核心组件对照
| 组件类型 | 作用 | 常见实现 |
|---|---|---|
| 负载均衡（四层） | 高效流量分发 | LVS |
| 负载均衡（七层） | 灵活应用路由 | Nginx |
| 分布式缓存 | 共享状态与缓存 | Redis、Memcached |
| 消息队列 | 异步解耦削峰 | Kafka、RocketMQ、RabbitMQ |
| 容器编排 | 弹性伸缩与调度 | Kubernetes |
| 服务网格 | 统一流量治理 | Istio、Linkerd |
| 时序监控 | 指标采集存储 | Prometheus |
| 日志系统 | 日志采集检索 | ELK、Loki |
| 链路追踪 | 分布式请求追踪 | Jaeger、Zipkin |
| 对象存储 | 文件与静态资源 | 腾讯云COS、AWS S3 |
组件选型不是选最新最热的，而是选最适合团队技术栈和业务规模的。成熟稳定的组件往往比新潮的更适合生产环境。
使用说明与维护建议
这份对照表不是用来背的，而是排障和评审时放在手边的速查工具，用好它有三个建议。第一，评审会前先抽五行：拿候选方案的组件对照表过一遍，每个组件问一句"它的上限我们当前量级用到几成"，超过七成的方案直接毙掉，留余量是容量规划的第一原则。第二，排障时反向查：从异常指标列出发，找到关联组件和常见诱因，能显著缩短定位时间——指标和组件的对应关系是排障经验的结晶，比记忆靠谱。第三，每季度更新一次：线上组件版本升级、指标口径调整，都要同步进来，过期的对照表比没有更危险，因为它制造确定性的错觉。
表格之外再补一组容易被忽略的数字经验。连接池的经验值是数据库单实例总连接数不超过一千，应用侧单实例池子五十到两百起步观察；缓存的 key 平均大小超过十KB就该考虑拆分或压缩；消息队列的单分区吞吐到瓶颈前会有消费延迟的趋势性上升，提前扩分区比事后迁移从容。这些数字不是定律，是大量实践的众数区间，作为初值的参考比从零拍脑袋强。数字会被突破，但"给参数找依据"的习惯不会——附录的最大价值，是让你养成每个参数都有出处的工作方式。
指标间的换算关系速查
排障时经常需要在指标之间快速换算，这里给一组常用的换算关系。吞吐与并发：并发数约等于吞吐乘以平均响应时间，这个利特尔法则在容量估算里无处不在——每秒一万请求、平均五十毫秒响应，稳态并发就是五百，据此可以反推线程池和连接池的规格。分位数与均值：P99 大约是均值的五到十倍（长尾分布时更高），看到两者比值突然变化，说明长尾结构变了，通常是某类慢查询或慢依赖新增。可用性与停机时间：四个九对应全年约五十二分钟，三个九约八点八小时，从三个九到四个九的跨越，靠人肉值班基本不可能，必须依赖自动切换——这也是第 5 章容灾存在的意义。缓存相关：命中率的提升对响应时间的影响是非线性的，从九成到九成五的收益，往往超过从八成到九成，因为未命中的请求走的是慢一个量级的路径。掌握这组换算，看板上的数字就从孤立点位变成了可以互相推导的网络，这是容量规划的思维基础。
常见反模式速查
把实战里反复出现的反模式也整理成表，比正面清单更有警示价值。容量类：压测峰值当生产上限（缺七折余量）、按峰值均值比为一配置资源（突刺无保护）、缓存未命中率不监控（雪崩前夜）。数据类：先分库后缓存（用贵方案解便宜问题）、分片键选了自增 ID（写入热点无解）、跨片查询走数据库（应该异构索引兜住）。异步类：消费端不幂等（至少一次投递下必炸）、积压无分级水位（凌晨三点让值班工程师做产品决策）、消息无追踪标识（跨队列排障靠猜）。韧性类：容灾只练正向切换（回切时踩坑）、降级清单不与产品对齐（砍错核心功能）、熔断恢复无爬坡（二次故障）。观测类：日 P99 不注明聚合方式（跨团队对不齐数）、告警不回答"谁该做什么"（疲劳后全关）、看板无人下钻（数据在流动、决策没人做）。
这张反模式表的使用方式和正面表一样：方案评审时过一遍，命中的当场辩论清楚理由。每一个反模式背后都是至少一次真实事故，绕开它们，等于免费继承了几十个团队的学费——这可能是整个附录里性价比最高的一页。
版本演进的观察
最后记录几个组件层面的趋势观察，帮助读表时理解"为什么是这些组件"。网关层正从自建走向托管与网格并存，纯流量网关的价值在收敛，治理能力下沉到边车是中期方向。缓存层的变化是持久化内存技术退潮、分层存储兴起，热数据在内存、温数据在 SSD 的混合方案成为大容量场景的主流。消息队列在向云原生的多协议收敛，同一集群支持多种消费模型的产品在减少运维面的同时保留灵活性。数据库的分化最有意思：分析场景列存一统，交易场景回到"分布式中间件加单机库"的组合为主流，真正的分布式数据库在金融核心场景缓慢渗透。这些趋势的共性是"把复杂度从用户侧挪到平台侧"，读组件对照表时带着这个视角，选型时就能少一分纠结：今天纠结的很多能力差异，三年后平台都会替你抹平，真正要押注的是团队的长期演进口径。
三张速查表的联合用法
最后交代指标对照、换算关系、反模式三张表的联合用法：方案评审时先用反模式表排雷，再用指标对照表核对容量余量；排障时用换算关系表做心算推导，三个场景各取所需。建议把三张表打印成一页速查纸贴在工位，电子版放在团队知识库置顶，每季度随版本评审一起更新。工具的价值在使用密度，这页纸被翻旧的团队，容量和排障的功课大概率不会太差——毕竟所有的高并发能力，最后都沉淀在工程师对数字的熟悉程度上。附录用一句话收束全书：高并发没有终点，只有下一道流量曲线，但有了取舍的框架和数字的习惯，任何一道曲线来了，你都有办法。
关于维护责任再交代一句：对照表应指定唯一维护人，变更走轻量评审——任何人发现表格与实际不符都可以发起修订，维护人负责核对合并。没有主人的表格会在两次更新之间悄悄失真，而失真的速查表比没有更危险。人名写在表格页脚，出问题知道找谁，这份表格才算真正属于这个团队。
再补最后一组冷门但救命的指标：文件描述符数（进程默认上线就不够，大流量前手动调高）、线程池拒绝数（一旦非零说明排队已满，是过载的前兆信号）、时间同步偏移（跨机房的时钟漂移会让日志排序失效，分布式追踪直接失真）。这三个指标平时无人问津，出事时每一个都能让排障绕大弯，建议纳入基础监控的默认集合。
表格之外最后送一句经验之谈：高并发系统的护城河不是用了多新的组件，而是每个参数都有出处、每个阈值都有复盘、每张速查表都活着。组件会过时，这套纪律不会。