Daily Study

更新: 6/23/2025 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

关于项目中的QPS

首先要明白问题回答最终的方向，例如：

• 问微服务的QPS有多少，聚焦点并不单纯在QPS数字上，你需要说明你的服务配置，测试或者观测QPS的步骤，是单机模拟测试还是全链路生产测试。
• 问异常情况下的QPS，聚焦点在发现异常、定位异常和原因、解决异常的方法上

缓存击穿的异常

回答的时候，数字并不是关键，需要针对正常/击穿的情况进行对比分析。

• 正常运行状态下：热点数据QPS有4000，其他数据6000QPS，对缓存的QPS接近10000，数据库的QPS只有几十到一百（都被缓存处理）
• 缓存击穿发生时：由于热点数据过期，热点数据的QPS会全部涌向数据库，此时数据库的QPS为：正常情况下的QPS + 击穿的QPS，瞬间飙升到4000

应对顺缓存击穿的方法：

• 对热点数据不断续期
• singleflight（互斥锁）：只允许第一个请求去查询数据并重建缓存，其他请求等待。（最常用的方法）

QPS观测

核心思路：可观测性的三大支柱

• Metrics (度量/指标)：这是最直接、最高效的QPS观测方式。将QPS作为一个随时间变化的数值指标，进行采集、存储和可视化。这是我们讨论的核心。
• Logging (日志)：通过记录每一条请求的访问日志，事后进行聚合分析，从而计算出QPS。它能提供最详细的上下文信息。
• Tracing (追踪)：在微服务架构中，一个外部请求可能会触发内部多个服务调用。分布式追踪可以帮你看到单个请求的完整生命周期，并分析每个环节的QPS和耗时。

分层对象：明确观测目标

一个典型的Web请求会经过多个层次，每一层的QPS都有其独特的意义。你需要从上到下建立观测体系：

1. 接入层 (Ingress / Gateway)

这是整个系统的入口，通常是Nginx、Apache、或者云厂商的API网关。观测这里的QPS可以了解系统的总流入流量。

• 如何观测？
  • 方法一：利用Nginx自带模块（推荐）
    • stub_status_module: Nginx自带的轻量级模块，可以提供总请求数、当前活跃连接数等基本指标。通过计算单位时间内的请求数增量，就能得出QPS。
    • nginx-module-vts (Virtual Host Traffic Status): 一个功能更强大的第三方模块，可以提供非常详细的指标，包括每个server_name或location的QPS、请求速率、流量大小等。
  • 方法二：分析访问日志 (Access Log)
    • 将Nginx的访问日志实时采集到日志分析系统（如ELK、Loki）。
    • 通过聚合分析，可以计算出任意时间段的QPS，并且可以根据URL、状态码等维度进行细分。
    • 实时工具：goaccess 是一个强大的终端日志可视化工具，可以实时分析access log并展示QPS。

2. 应用层 (Application)

这里是你的核心业务逻辑所在（如Go、Java、Python服务）。观测这一层的QPS可以帮你定位具体哪个API接口是性能瓶颈。

• 如何观测？
  • 方法一：APM系统 (Application Performance Monitoring)（最强大）
    • 在你的应用中集成APM的Agent探针，如 SkyWalking, Jaeger, OpenTelemetry 或商业产品 Datadog, New Relic。
    • APM系统会自动采集每个API接口的QPS、延迟（P95/P99）、错误率等关键指标，并生成可视化报表和分布式调用链。这是观测微服务QPS的最佳方式。
  • 方法二：应用框架/代码埋点（最灵活）
    • 利用你所用Web框架的**中间件（Middleware）**机制。
    • 在中间件中，对收到的每个请求进行计数，并通过Metrics库（如 Prometheus Client SDK）将指标暴露出去。
    • 例如，在Go的Gin框架中，可以非常方便地集成一个Prometheus中间件，它会自动为每个API路由暴露一个HTTP请求计数器。

3. 数据及中间件层 (Data & Middleware)

你的应用会依赖数据库、缓存等中间件。观测它们的QPS可以判断后端资源是否健康。

• 数据库 (MySQL / PostgreSQL)
  • MySQL: 通过 SHOW GLOBAL STATUS LIKE 'Queries'; 可以看到自服务启动以来的总查询数。通过监控这个值的变化率，即可得到数据库的QPS。专业的MySQL监控工具（如 Prometheus的mysqld_exporter、Percona的PMM）会帮你完成这一切。
  • PostgreSQL: pg_stat_database 视图提供了每个数据库的事务数等信息。pg_stat_statements 插件则能提供具体SQL的执行频率。
• 缓存 (Redis)
  • 通过 INFO commandstats 命令，可以获取每个命令（get, set等）的调用次数。同样，Prometheus的redis_exporter 可以采集这些信息并计算出QPS。

观测工具

推荐组合：Prometheus + Grafana + (可选的APM和Logging)

• Prometheus (数据采集与存储)

  • 拉取模型 (Pull)：Prometheus会周期性地从你的各个组件（Nginx, Application, DB Exporter）暴露的 /metrics HTTP端点上拉取指标数据。
  • 内置时序数据库 (TSDB)：高效存储这些指标数据。
  • 强大的查询语言 (PromQL)：可以非常灵活地对指标进行查询和计算。例如，用 rate(http_requests_total[1m]) 就可以轻松计算出一分钟内的平均QPS。

• Grafana (数据可视化)

  • 连接到Prometheus数据源。
  • 通过拖拽和配置，创建漂亮、动态的监控仪表盘（Dashboard），将Nginx QPS、API QPS、数据库QPS等图表集中展示。
  • 配置告警：当QPS超过某个阈值或发生异常下跌时，可以通过Grafana向你发送告警（邮件、钉钉、Slack等）。

• Exporter (指标暴露器)

  • 对于Nginx、MySQL、Redis这些无法原生支持Prometheus格式的组件，需要部署一个“Exporter”作为中间代理。
  • Exporter负责从目标组件获取状态信息，然后将其转换为Prometheus可以识别的Metrics格式。

模拟一个完整的流程

假设你要观测一个API的QPS，在生产环境下的标准流程是：

1. 应用代码中：引入prometheus-client库，并添加一个HTTP中间件，为每个API请求进行计数。
2. 部署Exporter：为Nginx、MySQL、Redis部署相应的Exporter。
3. 配置Prometheus：在Prometheus的配置文件中，添加上述应用和Exporter的metrics端点地址，让Prometheus开始采集数据。
4. 配置Grafana：在Grafana中创建一个新的Dashboard，添加图表，数据源选择Prometheus，并使用PromQL查询你想看的QPS指标（例如 rate(api_requests_total{path="/user/profile"}[5m]) 来查看/user/profile接口在5分钟窗口内的QPS）。
5. 配置告警：在Grafana中为该图表设置告警规则，例如当QPS持续5分钟低于10时，发送告警。