QPS和TPS 的区别是什么？QPS 大了会有什么问题，怎么解决？

QPS与TPS的核心区别

指标	定义	核心差异
QPS	每秒查询数（Queries Per Second），衡量服务器每秒响应的请求数	侧重单次请求处理，如页面加载可能触发多个QPS（如JS/CSS/API请求）
TPS	每秒事务数（Transactions Per Second），衡量系统每秒完成的完整事务数量	侧重业务完整性，如一次支付涉及订单、库存、支付接口等多个步骤，整体记为1 TPS

示例说明：
用户访问电商首页加载10个商品（触发10次API查询） → 产生10 QPS，但仅算作1次页面访问（对应0.1 TPS，假设1秒内处理10个用户访问）。

---

QPS过高的典型问题与解决方案

1. 资源瓶颈问题

• 问题表现：
  • CPU/内存耗尽 → 响应时间飙升（如RT从50ms升至2秒）
  • 数据库连接池占满 → 出现“Too many connections”错误
• 解决方案：
  • 垂直扩展：升级单机配置（如CPU核数、内存容量）
  • 水平扩展：通过负载均衡（如Nginx、Kubernetes）横向增加服务器实例
  • 连接池优化：限制最大连接数，启用连接复用（如HikariCP配置maximumPoolSize）

2. 服务雪崩风险

• 问题表现：
  • 某服务高QPS导致下游依赖（如支付接口）过载 → 级联故障扩散
• 解决方案：
  • 熔断降级：使用Hystrix或Sentinel在QPS阈值触发时快速失败（如返回兜底数据）
  • 限流控制：通过令牌桶（Guava RateLimiter）或漏桶算法限制每秒最大请求量

3. 数据库压力激增

• 问题表现：
  • 高频查询导致数据库CPU使用率超90%，慢查询堆积
  • 锁竞争加剧（如行锁等待超时）
• 解决方案：
  • 读写分离：主库处理写操作，从库分担读请求（如MySQL Group Replication）
  • 缓存加速：热点数据预加载至Redis（如商品详情页缓存TTL=5分钟）
  • 分库分表：按用户ID哈希分片，分散单表压力（如ShardingSphere分片策略）

4. 监控与弹性调度缺失

• 问题表现：
  • 突发流量无法及时扩容 → 服务不可用（如502错误）
• 解决方案：
  • 动态扩缩容：基于QPS指标触发Kubernetes自动伸缩（如HPA设置targetQPS=5000）
  • 智能调度：参考阿里TPP平台，根据CPU利用率、LOAD值实时调配资源（如双11错峰扩容）

---

实际案例参考

• 阿里TPP平台：
  • 日常：通过CPU利用率最大化提升资源使用率（如闲置时段缩容至50%节点）
  • 大促：QPS激增时自动从低优先级服务（如评论模块）回收资源，优先保障交易核心链路
• MySQL优化：
  • 计算QPS时优先采用Questions/Uptime（而非单纯SELECT计数），避免低估真实负载
  • TPS需结合InnoDB事务提交数（Com_commit/Com_rollback）监控，反映实际业务吞吐

---

总结应对策略

1. 预防性设计：容量预估（压测得出单机QPS/TPS极限） + 冗余部署（预留30%资源缓冲）
2. 实时监控：Prometheus监控QPS/TPS曲线，Grafana配置阈值告警（如QPS超80%即触发扩容）
3. 弹性架构：无状态服务设计 + 自动扩缩容（云原生场景优先采用Serverless或FaaS）
4. 代码级优化：减少非必要IO、异步处理耗时操作（如日志异步写入）、压缩传输数据量