MySQL在寫入壓力很大,怎么辦?
- 高并發下的性能最大的問題,大都在數據庫,以前我們做二十萬超級群,mongodb每個月都會出事故.
- 我們聊聊,高并發下如何緩解mysql的壓力
- ??:mysql是鎖鎖表不鎖庫,sqlite是鎖庫不鎖表
環境準備
- mac
- mysql
- navicat
- wrk壓測工具
- node.js環境
下載wrk
brew install wrk
- 如果這里卡住,可以調整
`替換brew.git:
cd "$(brew --repo)"
git remote set-url origin https://mirrors.ustc.edu.cn/brew.git
替換homebrew-core.git:
cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"
git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git`
- 再執行一次brew install wrk即可
使用Node.js連接mysql
- 先準備一個執行sql語句函數
`const mysql = require('mysql');
const { MYSQL_CONF } = require('./config');
const con = mysql.createConnection(MYSQL_CONF);
//建立連接
con.connect();
//統一執行sql的方法
function exec(sql) {
const promise = new Promise((resolve, reject) => {
con.query(sql, (error, result) => {
if (error) {
reject(error);
}
resolve(result);
});
});
return promise;
}
//關閉連接
function kill() {
con.end();
}
module.exports = { exec, kill };`
- 再準備一個配置文件 config.js(可以根據環境變量區分配置)
`//獲取環境變量
const env = process.env.NODE_ENV;
let MYSQL_CONF;
//開發環境的配置
MYSQL_CONF = {
host: 'localhost',
user: 'root',
password: '123456',
port: '3306',
database: 'blog',
socketPath: '/tmp/mysql.sock',
};
module.exports = { MYSQL_CONF };`
- 如上所示,跑起來
- 首先創建測試表
`exec('CREATE TABLE IF NOT EXISTS TEST_WRITE(first_column INT , second_column VARCHAR(100));')`
![](https://imgkr.cn-bj.ufileos.com/89f03976-a79d-4242-bdf0-090a53f6438c.png)
- 通過可視化工具Navicat可以看到表已經創建成功
開始模擬寫入
- 先寫一個接口,用來模擬用戶請求,寫入數據庫
`App.get('/test', (req, res) => {
exec("INSERT INTO first_table(first_column, second_column) VALUES(1, 'aaa');");
res.json(success({ errcode: 0, data: {} }));
});`
介紹下wrk
- wrk是一個用來做HTTP benchmark測試的工具。可以產生顯著的壓力。相比于Apache ab功能更為強大,可以使用lua腳本來支持更為復雜的測試場景,例如PUT請求等。在對于Restful架構的API接口來說,測試起來更加便捷。
- 使用方法
`使用方法: wrk <選項> <被測HTTP服務的URL>
Options:
-c, --connections <N> 跟服務器建立并保持的TCP連接數量
-d, --duration <T> 壓測時間
-t, --threads <N> 使用多少個線程進行壓測
-s, --script <S> 指定Lua腳本路徑
-H, --header <H> 為每一個HTTP請求添加HTTP頭
--latency 在壓測結束后,打印延遲統計信息
--timeout <T> 超時時間
-v, --version 打印正在使用的wrk的詳細版本信息
<N>代表數字參數,支持國際單位 (1k, 1M, 1G)
<T>代表時間參數,支持時間單位 (2s, 2m, 2h)`
- 目前我們服務跑在本地http://localhost://8080
- 測試下
`wrk -t8 -c500 -d2s --latency "http://localhost:8080/test"`
- 采用8個線程,500個長鏈接,壓測2秒
- 結果:
`Running 2s test @ http://localhost:8080/test
8 threads and 500 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 40.70ms 9.60ms 83.48ms 66.26%
Req/Sec 640.89 328.89 1.43k 64.29%
Latency Distribution
50% 39.26ms
75% 46.33ms
90% 54.32ms
99% 65.23ms
8980 requests in 2.08s, 3.13MB read
Socket errors: connect 253, read 201, write 0, timeout 0
Requests/sec: 4321.60
Transfer/sec: 1.50MB`
- 2s內完成了8980個請求,3.13mb的數據讀取
- 當然你也可以用lua腳本個性化測試,這里不做過度的講解,有興趣可以去學習下
- 數據庫結果,寫入成功
加大壓力測試
- 加大壓力測試
`wrk -t15 -c1000 -d30s --latency "http://localhost:8080/test"`
- 此時cpu打到了25%,當然我這是一臺Mac pro,如果是普通的機器估計此時已經...
- 壓測結果:
`Running 30s test @ http://localhost:8080/test
15 threads and 1000 connections
(平均值) (標準差)(最大值)(正負一個標準差所占比例)
Thread Stats Avg Stdev Max +/- Stdev
(延遲)
Latency 35.32ms 17.38ms 345.78ms 96.45%
Req/Sec 0.95k 661.40 2.38k 54.50%
Latency Distribution
50% 33.36ms
75% 37.61ms
90% 42.49ms
99% 76.00ms
197231 requests in 30.09s, 68.65MB read
Socket errors: connect 754, read 188, write 0, timeout 0
Requests/sec: 6554.26
Transfer/sec: 2.28MB`
- wrk使用方便,結果清晰。并且因為非阻塞IO的使用,可以在普通的測試機上創建出大量的連接,從而達到較好的壓測效果。
- 當我繼續調大壓測的值時,出現了OOM的情況,而且我的Node.js版本還是12.x版本.
- 此時我的表字段很少,而且都是非常簡單的數據,讀寫也沒有同時進行,壓力也不大,但是卻先出現OOM了。
這里說明,我們的這種直接寫入是有問題的,這樣長時間的高頻直接寫入,即使數據庫還能扛住,但是會很容易出現OOM,此時應該需要消息隊列流量削峰,限流,也可以事務寫入,但是事務寫入如果失敗,就默認全部失敗...
數據庫什么時候會出現鎖庫?
- 讀寫同時進行,高頻耗時....
- 這個數據庫我也不是理解很透徹