QPS 基本概念：从定义到日志系统的实战意义

QPS 到底在说什么？

QPS，全称 Queries Per Second，每秒查询数。说白了，就是服务器一秒钟能处理多少个请求。

但在这个定义上，我踩过一个小坑。记得刚带团队做日志平台时，架构师指着 5000 QPS 的数字说「够了」。结果上线第一周，峰值流量直接干到 8000，系统直接雪崩。为什么？因为 QPS 不是静态的，它是性能指标的瞬时快照，更像车速表——告诉你当前车速，不代表全程都能这么开。

QPS 的真正含义包含三个维度：

• 瞬时值：某一秒内实际处理的请求数
• 均值：一段时间内的平均处理能力
• 峰值：系统能支撑的最大瞬时吞吐

QPS vs TPS，别再傻傻分不清

很多人把 QPS 和 TPS 混为一谈。我早期也犯过这毛病，直到一次压测汇报被总监当场追问：「你测的到底是查询还是事务？」

为什么 QPS 在日志系统里这么关键？

相信我，审计日志的 QPS 场景跟普通业务系统完全不一样。你想想看，一个支付系统的下单接口，高峰期也就几千 TPS。但一个中等规模的审计日志系统，动辄几万 QPS 起步。

我总结过三点原因：

1. 写多读少：审计日志 90% 的操作是写入，查询是事后复盘用的。
2. 峰值压力极大：全量业务操作都要记录日志，业务高峰等于日志写入高峰。
3. 数据完整性要求高：日志丢了就是合规问题，不能随便降级。

为什么不能随便降级？我曾经有个教训。有次线上日志系统扛不住写入压力，团队决定丢日志 30 秒。结果合规审计时，那 30 秒的操作时序无法证明完整性，差点被罚。从那以后，我对 QPS 评估再也不敢马虎。

核心逻辑：QPS 评估三板斧

我个人做 QPS 评估，就三件事：

• 摸底：搞清楚当前系统的硬件和软件栈能扛多少 QPS
• 预测：结合历史流量和业务增速，推算峰值 QPS
• 测试：压测验证，看真实数据和理论数据的差距

这背后其实是一个闭环。我画了张图帮你理解：

审计日志 QPS 的特殊性

别说我没提醒你，审计日志的 QPS 跟普通接口的 QPS 有三个本质区别：

• 写密集：普通业务接口多是大读小写，日志系统反着来
• 不可削峰：日志必须实时记录，难以通过队列削峰填谷
• 单体瓶颈：往往一个日志库集群要扛所有业务的写入

我举个例子你就懂了。假设你们公司有 100 个微服务，每个服务每秒产生 50 条审计日志。那么日志系统的写入 QPS 就是 5000。但这还没完——如果某个服务出现异常，日志量瞬间翻倍，那 QPS 直接飙升到 10000。这就是所谓的不确定的峰值。

实际场景：QPS 评估到底评估什么？

很多人以为 QPS 评估就是测一下极限值。其实没那么简单。我列了个清单：

• 单机 QPS 上限：一台机器能扛多少
• 集群 QPS 上限：水平扩展后的整体能力
• 写入延迟：QPS 上来了，单条写入延迟会不会暴涨
• 资源消耗：CPU、内存、磁盘 IO 是否成为瓶颈
• 数据持久化：磁盘写入速度能否匹配内存 QPS

你看，QPS 不只是一个数字，它背后绑定了整个系统的健康指标。我刚开始做日志系统时，只盯着 QPS 数字看，结果 CPU 快撑爆了都不知道。

说到这，你应该明白了吧？QPS 在日志系统里不仅仅是性能指标，它直接决定了你的系统能不能在合规要求下稳定运行。

—— 本章完 ——