記一次node上的redis呼叫優化
最近負責的node專案在高併發的情況下效能表現非常的差,rt基本會在7 80ms甚至100ms以上,由於對外提供了dubbo介面,所以經常導致上游應用和自己的dubbo執行緒池耗盡,所以花了一點時間排查了一番,才發現原來自己的node功力還有很長的路要走啊~之後node的文章可能會越來越多~
最蠢的方式
先來看看我最早是怎麼用的呢:
for(let i = 0; i < params.length; i++) { redisKey = getKey(params.id); let value = await redis.exec('get', redisKey); }
這就是我最原始的呼叫方法,就是在for迴圈裡不斷的去await結果的請求,這樣的結果就是每一個請求都需要等待上一個請求完成再去執行,只要在高流量的時候有一部分請求rt很高,就會引起雪崩的反應。
使用Promise.all優化請求
經過了一陣谷歌之後,我發現可以通過Promise.all的形式來進行請求鏈路的優化:
for(let i = 0; i < params.length; i++) { redisKey = getKey(params.id); arr.push(redis.exec('get', redisKey)) } await Promise.all(arr);
上面的第一種方式被我司的node大神嚴重吐槽了10分鐘,然後告訴我,使用Promise.all的方式可以很有效的優化這種連續的網路請求,我趕緊將程式碼改完並上線。
自信滿滿的上線之後,迎來的確實現實無情的打擊,在高流量的時刻,報警依然不斷,我一邊和領導說“沒事,我再看看”,心裡一邊想著辭職報告該怎麼寫。
redis的正確使用姿勢
在繼續經過了一系列的谷歌之後,我才發現原來的是對redis的理解太淺了,針對於業務上的需求,我不假思索的只知道使用最簡單的set和get,而redis對於set和get這樣的命令是一條命令一個tcp請求,在業務場景上確實不太合理,於是我使用谷歌告訴我的pipeline機制去改造現有的get請求:
let batch = await RedisClient.getClient().batch(); for(let i = 0; i < params.length; i++) { batch.get(redisKey); } batch.exec();
對於pipeline機制大家可以看ofollow,noindex">這篇文章 。在使用pipeline之後,便祕一下就通暢了,再也沒有報警過,終於可以不用辭職了。
再後面的日子裡,我覺得認真的研究一下redis這個東西,保證讓上面的問題不再發生,於是我發現其實還是有一種更加簡單的方案的,那就是使用mget:
for(let i = 0; i < params.length; i++) { redisKey = getKey(params.id); arr.push(redisKey); } let value = await redis.exec('mget', arr);
使用mget進行批量的查詢,這是redis裡比較常見的一種方式了~
總結一下
在對以上四種方式進行了對比之後得出了資料上的結論:
在一個200次的迴圈中呼叫redis請求,第一種最蠢的方案大概是8000ms左右,第二種Promise.all的方案大概在2000ms左右,而第三和第四種方案,大概只需要幾十ms就能完成,這真的是質的飛躍啊。
這個線上血淋淋的案例讓我決定真的要好好的研究一下redis,不能再輕視它導致犯錯。