學習一下壓測和監(jiān)控
初步學習壓測和監(jiān)控
本文示例代碼以及數(shù)據(jù)庫sql文件見:gitee
https://gitee.com/quercus-sp204/new-technology/tree/master/all-component-monitor
1.環(huán)境說明
- 首先是開發(fā)環(huán)境:jdk是21,然后maven是3.9.6,idea是2024
- 然后是數(shù)據(jù)庫MySQL,版本是8.0.44;Redis版本是7.4.6
- 最后是監(jiān)控方面,Prometheus3.7.2 + grafana12.2.0 + 各個中間件的exporter
- linux是Ubuntu22.04.5 LTS,配置是4c8g【所有中間件mysql,redis,Prometheus,grafana,exporter均是安裝在這上面的】
然后說一下監(jiān)控三件套的關系
- Exporter:數(shù)據(jù)采集器負責從監(jiān)控目標(服務器、數(shù)據(jù)庫、應用等)抓取指標數(shù)據(jù),將其標準化為 Prometheus 能識別的格式。無需主動推送數(shù)據(jù),等待Prometheus 定期拉取即可。
- Prometheus:核心監(jiān)控引擎定時從 Exporter 拉取數(shù)據(jù)并存儲,支持按時間序列查詢、設置告警規(guī)則,是整個體系的 “數(shù)據(jù)中樞”。本身可視化能力較弱,需依賴 Grafana 呈現(xiàn)。
- Grafana:可視化面板工具作為獨立的可視化平臺,通過連接 Prometheus(或其他數(shù)據(jù)源),將原始監(jiān)控數(shù)據(jù)轉(zhuǎn)換成直觀的圖表、儀表盤。支持自定義面板樣式,滿足不同場景的監(jiān)控展示需求。
此案例中需要監(jiān)控linux 和 redis,所以就需要在服務器上部署node exporter 和 redis exporter了。
環(huán)境部署的話,就由讀者自行完成了,網(wǎng)上很多教程,本文就不贅述了。

這個是本文配置的兩個面板。
2.測試情況
本文就以RedisSeckillController下面的接口測試為例子,/redisSeckill/submitSeckill
模擬的一個簡單的秒殺搶購功能。
首先準備jmeter的測試,【線程準備了4000個】由于秒殺接口需要用戶登陸過才能搶購,故會有一個攔截器,所以我們的jmeter需要做一點小改動,

我將用戶的token生成在了這個csv文件中,可以訪問UserManagerController里面的接口來自動生成。感興趣的同學可以看一下。然后http信息頭管理里面添加一些內(nèi)容,

這樣我們的http請求就可以有token了。到此,準備工作做好了。
現(xiàn)在我們模擬添加一個秒殺活動。【在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訪問接口:
數(shù)據(jù)庫里面:【相應的表數(shù)據(jù)已經(jīng)生成好了】
Redis里面數(shù)據(jù)也生成了:【set里面是弄限購的,如果已經(jīng)買過了就不能再買了,hash是存庫存的】
數(shù)據(jù)準備好了,接下來就是準備測試了。

然后就可以啟動了。數(shù)據(jù)庫生成的數(shù)據(jù)沒有問題,然后redis數(shù)據(jù)也是完整的。
然后可以看到相關報告:【可以重點關注一下以下指標】

異常 % 為 0.00%,4000 次請求全部成功,系統(tǒng)在高并發(fā)下穩(wěn)定性極佳。
平均值 119ms,中位數(shù) 18ms,說明大部分請求響應極快;90% 分位 516ms、95% 分位 520ms、99% 分位 876ms(90%的請求都在516毫秒以下,99%的請求都在876毫秒以下)。
吞吐量1987.1/sec,每秒處理近 2000 次請求,高并發(fā)處理能力較強。
接收 / 發(fā)送帶寬分別為 464.95KB/sec、554.93KB/sec,若服務器帶寬充足,網(wǎng)絡未成為瓶頸。
再查看一下Prometheus + grafana的監(jiān)控指標呢:
這個是redis的
流入流量在 11:50 左右出現(xiàn)峰值(42.3 KiB/s),流出流量穩(wěn)定在 4.32 KiB/s 以內(nèi)。說明這一時刻開始測試的。
每秒命中數(shù)峰值 533,未命中數(shù)始終為 0,命中率 100%;
連接數(shù)穩(wěn)定在 5 左右,無阻塞(blocked)客戶端。連接池配置合理,無連接積壓或拒絕問題;
命令執(zhí)行平均耗時集中在 50–200 μs,命令執(zhí)行整體高效,無明顯慢命令拖垮性能
這個是linux的網(wǎng)絡情況:

已分配 Socket(Allocated Sockets):在 11:55 左右從約 50 躍升至 135,增長顯著。說明有突發(fā)的 TCP 連接創(chuàng)建操作。
3.end
總的來說,還可以繼續(xù)往上壓測,找到服務器的極限,還可以考慮持續(xù)壓測,看看穩(wěn)定性如何。
本文僅作簡單示例,這個案例代碼其實有很多需要完善的,比如一些容錯的設計,用戶超時取消訂單等操作。

浙公網(wǎng)安備 33010602011771號