学习一下压测和监控

初步学习压测和监控

本文示例代码以及数据库sql文件见：gitee

https://gitee.com/quercus-sp204/new-technology/tree/master/all-component-monitor

1.环境说明

• 首先是开发环境：jdk是21，然后maven是3.9.6，idea是2024
• 然后是数据库MySQL，版本是8.0.44；Redis版本是7.4.6
• 最后是监控方面，Prometheus3.7.2 + grafana12.2.0 + 各个中间件的exporter
• linux是Ubuntu22.04.5 LTS，配置是4c8g【所有中间件mysql，redis，Prometheus，grafana，exporter均是安装在这上面的】

然后说一下监控三件套的关系

• Exporter：数据采集器负责从监控目标（服务器、数据库、应用等）抓取指标数据，将其标准化为 Prometheus 能识别的格式。无需主动推送数据，等待Prometheus 定期拉取即可。
• Prometheus：核心监控引擎定时从 Exporter 拉取数据并存储，支持按时间序列查询、设置告警规则，是整个体系的 “数据中枢”。本身可视化能力较弱，需依赖 Grafana 呈现。
• Grafana：可视化面板工具作为独立的可视化平台，通过连接 Prometheus（或其他数据源），将原始监控数据转换成直观的图表、仪表盘。支持自定义面板样式，满足不同场景的监控展示需求。

此案例中需要监控linux 和 redis，所以就需要在服务器上部署node exporter 和 redis exporter了。

环境部署的话，就由读者自行完成了，网上很多教程，本文就不赘述了。

这个是本文配置的两个面板。

2.测试情况

本文就以RedisSeckillController下面的接口测试为例子，/redisSeckill/submitSeckill

模拟的一个简单的秒杀抢购功能。

首先准备jmeter的测试，【线程准备了4000个】由于秒杀接口需要用户登陆过才能抢购，故会有一个拦截器，所以我们的jmeter需要做一点小改动，

我将用户的token生成在了这个csv文件中，可以访问UserManagerController里面的接口来自动生成。感兴趣的同学可以看一下。然后http信息头管理里面添加一些内容，

这样我们的http请求就可以有token了。到此，准备工作做好了。

现在我们模拟添加一个秒杀活动。【在SeckillManagerController中可以看到】，这里给大家一个示例json

/* by yours.tools - online tools website : yours.tools/zh/calcdata.html */
{
    "activityName": "华子的秒杀大促",
    "startTime": "2025-11-01 00:00:00",
    "endTime": "2025-11-10 00:00:00",
    "status": 1,
    "goods": [
        {
            "id": 1,
            "goodsName": "华为mate80 pro",
            "originalPrice": 8000,
            "seckillPrice": 1000,
            "stock": 100,
            "limitPerUser": 1,
            "status": 1
        }
    ]
}

访问对应的接口，就可以添加秒杀活动了。添加完成之后可以看到如下图所示：

apifox访问接口：

数据库里面：【相应的表数据已经生成好了】

Redis里面数据也生成了：【set里面是弄限购的，如果已经买过了就不能再买了，hash是存库存的】

数据准备好了，接下来就是准备测试了。

然后就可以启动了。数据库生成的数据没有问题，然后redis数据也是完整的。

然后可以看到相关报告：【可以重点关注一下以下指标】

异常 % 为 0.00%，4000 次请求全部成功，系统在高并发下稳定性极佳。

平均值 119ms，中位数 18ms，说明大部分请求响应极快；90% 分位 516ms、95% 分位 520ms、99% 分位 876ms（90%的请求都在516毫秒以下，99%的请求都在876毫秒以下）。

吞吐量1987.1/sec，每秒处理近 2000 次请求，高并发处理能力较强。

接收 / 发送带宽分别为 464.95KB/sec、554.93KB/sec，若服务器带宽充足，网络未成为瓶颈。

---

再查看一下Prometheus + grafana的监控指标呢：

这个是redis的

流入流量在 11:50 左右出现峰值（42.3 KiB/s），流出流量稳定在 4.32 KiB/s 以内。说明这一时刻开始测试的。

每秒命中数峰值 533，未命中数始终为 0，命中率 100%；

连接数稳定在 5 左右，无阻塞（blocked）客户端。连接池配置合理，无连接积压或拒绝问题；

命令执行平均耗时集中在 50–200 μs，命令执行整体高效，无明显慢命令拖垮性能

---

这个是linux的网络情况：

已分配 Socket（Allocated Sockets）：在 11:55 左右从约 50 跃升至 135，增长显著。说明有突发的 TCP 连接创建操作。

3.end

总的来说，还可以继续往上压测，找到服务器的极限，还可以考虑持续压测，看看稳定性如何。

本文仅作简单示例，这个案例代码其实有很多需要完善的，比如一些容错的设计，用户超时取消订单等操作。