提高node.js中使用redis的性能

問題初現

某基於node.js開發的業務系統向外提供了一個dubbo服務，提供向第三方緩存查詢、設置多項業務數據並聚合操做結果。在QPS達到800時（兩臺虛擬機，每臺機器4Core8G4node進程），在監控平臺上出現了很是多的slow rt警告，平均接口響應達到60+ms，請求報警率達到80%+。

爲找到形成該服務吞吐量太低的罪魁禍首，業務人員在請求日誌中打點了全部查詢緩存的操做，結果顯示每一個請求查詢緩存耗時在50-100ms之間跳動。查詢了redis-server的監控數據發現，不存在server端的慢查詢，在整個監控區間內服務端處理時間在40us徘徊，所以排除了redis-server的處理能力不足緣由；

經過登陸內網機器進行不斷測試到對應redis server機器的端到端時延發現內部局域網的帶寬、時延與抖動足夠正常，都不是形成該問題的緣由。

所以，錯誤緣由定位到了調用redis client的業務代碼以及redis client的I/O性能。

本文中提到的node redis client採用的基於node-redis封裝的二方包，所以問題排查也基於node-redis這個模塊。

瓶頸在哪

爲了在本地模擬線上環境的併發，能夠作一個不是很嚴謹的測試：

async  ()=>{
    let  dd  =  Date.now()
    let  arr  = []
    for(let  i=0;i<200;i++){
        arr.push(new Promise((res,rej)=>{
            let  hrtime  = process.hrtime();
            client.send_command('get',['key'], function(e,r) {
            let  diff  = process.hrtime(hrtime);
            let  cost  = (diff[0] *  NS_PER_SEC  +  diff[1])/1000000;
            console.log(`final: ${cost} ms`)
            res();
            });
        }));
    }
    await  Promise.all(arr)
    console.log('ops/sec:',200*1000/(Date.now() -  dd),Date.now() -  dd);
}

會發現每一個請求的rt都會比前一個請求來的大

最後一個請求的rt居然達到了257 ms！雖然在node單進程像示例代碼那樣併發執行200次get請求是很是少見並且愚蠢的（關於示例代碼的優化在在下節講述），可是針對這個示例必須找到請求delay增長的緣由。
爲此繼續分析，redis client採用的是單鏈接模式，底層採用的非阻塞網絡I/O，socket.recv()在node層面是經過監聽socket的data事件完成的，所以先分析redis-client讀性能如何：

上圖每段日誌的含義分別表示：
- data events trigger times: socket data事件觸發的次數
- data event start from prevent event: data事件距離上次觸發的時間間隔
- data events exec time(ms): 本次事件處理函數執行時間
上圖只是截取了最初的請求日誌，發現當第6次觸發data事件時，居然距離上次觸發事件隔了35ms，在隨後的請求中會復現這種現象，所以這也就致使了在併發200次查詢請求時，每一個請求的rt都會隨之增大，而且有些響應之間間隔了30ms。

從表象看形成問題在於redis-server發送的響應不是一個數據塊，而是多個數據塊致使觸發socket的data事件過多，並且data事件抖動過大致使響應之間存在30ms的突變（data事件是沒法同時觸發兩次的，每次data事件處理函數執行完後才能繼續觸發下一個data事件）；固然也有可能和socket寫入（即發送req）有關，如緩存請求等。爲了繼續探查，監控與socket寫入相關的接口 **_write()**,記錄每次寫入socket的數據時距離上一次寫入的間隔：

可見，在使用redis-client發送請求時，write方法也不是瓶頸。

採用一樣方法，對socket的push()（該方法觸發socket的data事件）進行監控，發現socket的數據到達間隔抖動很是大：

所以，形成redis-client併發請求下響應rt抖動較大的狀況與單鏈接下響應數據到達本地的時刻有關，具體可能與底層libuv的緩存策略有關（筆者並未再往下探查）。

在一個node實例中經過一個單鏈接與redis server通訊，在高併發下會出現排隊等待響應的狀況，而且有可能會出現響應rt雪崩效應（如上文demo所示），所以須要儘量減小或緩存客戶端的請求數量，進行批量發送。

調優

1. pipeline(涉及到寫模式及時序)
2. script

對於pipeline方式，redis server是默認支持的。通俗點說，pipeline能夠合併一系列請求一次發送，並將這些請求對應的結果一次性拿到。所以這種方式能夠有效減小響應次數，從而減小socket觸發data事件的次數，儘量快的拿到響應體。

須要強調的是，在node中，是經過底層socket的**_writev**實現一次發送多條redis命令的，_writev又叫作聚合寫，它支持將不一樣緩衝區的多條數據經過一次系統調用寫入目標流，所以性能上比每次寫單個緩衝區的單個數據來的好得多。在node的Writeable對象中，有cork和uncork方法，經過這兩個方法能夠在node write stream中緩存多條數據，經過_writev一次性發送。

關於 _writev的數據結構

redis在拿到數據後，根據resp協議解析出命令集合緩存在隊列中，直到收到exec命令，開始批量執行命令集，並將全部命令執行的結果轉換爲數組返回給redis client。這樣就能夠經過一次寫、一次讀實現高性能I/O。

async  ()=>{
    let  dd  =  Date.now()
    let  batch  =  await client.batch();
    for(let  i=0;i<200;i++){
        batch.get('vdWeex_com.koudai.weidian.buyer_1');
    }
    let rt = await batch.exec();
    process.exit();
}

而對於script方法，則是由redis client傳入script命令，在server端執行script邏輯，批量執行命令，並返回結果。一樣是一次寫、一次讀。

收穫

1. node socket默認採用writev 集合寫
2. 無依賴批量請求採用pipeline
3. eval script解決有依賴批量請求 
4. redis高性能體如今服務端處理能力，但瓶頸每每出如今客戶端，所以加強客戶端I/O能力與併發並行多客戶端纔是高併發解決方案