Mysql寫入頻繁,怎麼破?

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,此時應該須要消息隊列流量削峯,限流,也能夠事務寫入,可是事務寫入若是失敗,就默認所有失敗...

數據庫何時會出現鎖庫?

  • 讀寫同時進行,高頻耗時....
  • 這個數據庫我也不是理解很透徹

..更多請期待下一章node

歡迎關注個人微信公衆號:前端巔峯、大前端之巔

相關文章
相關標籤/搜索