初步学习压测和监控
本文示例代码以及数据库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
{"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
总的来说，还可以继续往上压测，找到服务器的极限，还可以考虑持续压测，看看稳定性如何。
本文仅作简单示例，这个案例代码其实有很多需要完善的，比如一些容错的设计，用户超时取消订单等操作。