前言

如果一個(gè) Node 應(yīng)用有多臺(tái)服務(wù)器或多個(gè)進(jìn)程在跑，每個(gè)進(jìn)程都擁有自己的內(nèi)存空間，各個(gè)進(jìn)程之間的數(shù)據(jù)共享就顯得非常重要。

使用數(shù)據(jù)庫(kù)是一個(gè)解決數(shù)據(jù)共享的方案，但一些臨時(shí)性、高并發(fā)的數(shù)據(jù)并不太適合直接寫入數(shù)據(jù)庫(kù)，比如 session。

引入 Redis 可以解決數(shù)據(jù)共享的問(wèn)題，也因?yàn)?Redis 是基于內(nèi)存存儲(chǔ)的特點(diǎn)，有著非常高的性能，可以大大降低數(shù)據(jù)庫(kù)讀寫的壓力，提升應(yīng)用的整體性能。

Redis 還可以用來(lái)：緩存復(fù)雜的數(shù)據(jù)庫(kù)查詢結(jié)果，做自增長(zhǎng)統(tǒng)計(jì)，暫存用戶操作狀態(tài)等功能。

最近負(fù)責(zé)的node項(xiàng)目在高并發(fā)的情況下性能表現(xiàn)非常的差，rt基本會(huì)在7 80ms甚至100ms以上，由于對(duì)外提供了dubbo接口，所以經(jīng)常導(dǎo)致上游應(yīng)用和自己的dubbo線程池耗盡，所以花了一點(diǎn)時(shí)間排查了一番，才發(fā)現(xiàn)原來(lái)自己的node功力還有很長(zhǎng)的路要走啊~之后node的文章可能會(huì)越來(lái)越多~

最蠢的方式

先來(lái)看看我最早是怎么用的呢：

for(let i = 0; i < params.length; i++) {
 redisKey = getKey(params.id);
 let value = await redis.exec('get', redisKey);
}

這就是我最原始的調(diào)用方法，就是在for循環(huán)里不斷的去await結(jié)果的請(qǐng)求，這樣的結(jié)果就是每一個(gè)請(qǐng)求都需要等待上一個(gè)請(qǐng)求完成再去執(zhí)行，只要在高流量的時(shí)候有一部分請(qǐng)求rt很高，就會(huì)引起雪崩的反應(yīng)。

使用Promise.all優(yōu)化請(qǐng)求

經(jīng)過(guò)了一陣谷歌之后，我發(fā)現(xiàn)可以通過(guò)Promise.all的形式來(lái)進(jìn)行請(qǐng)求鏈路的優(yōu)化：

for(let i = 0; i < params.length; i++) {
redisKey = getKey(params.id);
 arr.push(redis.exec('get', redisKey))
}
await Promise.all(arr);

上面的第一種方式被我司的node大神嚴(yán)重吐槽了10分鐘，然后告訴我，使用Promise.all的方式可以很有效的優(yōu)化這種連續(xù)的網(wǎng)絡(luò)請(qǐng)求，我趕緊將代碼改完并上線。

自信滿滿的上線之后，迎來(lái)的確實(shí)現(xiàn)實(shí)無(wú)情的打擊，在高流量的時(shí)刻，報(bào)警依然不斷，我一邊和領(lǐng)導(dǎo)說(shuō)“沒事，我再看看”，心里一邊想著辭職報(bào)告該怎么寫。

redis的正確使用姿勢(shì)

在繼續(xù)經(jīng)過(guò)了一系列的谷歌之后，我才發(fā)現(xiàn)原來(lái)的是對(duì)redis的理解太淺了，針對(duì)于業(yè)務(wù)上的需求，我不假思索的只知道使用最簡(jiǎn)單的set和get，而redis對(duì)于set和get這樣的命令是一條命令一個(gè)tcp請(qǐng)求，在業(yè)務(wù)場(chǎng)景上確實(shí)不太合理，于是我使用谷歌告訴我的pipeline機(jī)制去改造現(xiàn)有的get請(qǐng)求：

let batch = await RedisClient.getClient().batch();
for(let i = 0; i < params.length; i++) {
 batch.get(redisKey);
}
batch.exec();

對(duì)于pipeline機(jī)制大家可以看這篇文章。在使用pipeline之后，便秘一下就通暢了，再也沒有報(bào)警過(guò)，終于可以不用辭職了。

再后面的日子里，我覺得認(rèn)真的研究一下redis這個(gè)東西，保證讓上面的問(wèn)題不再發(fā)生，于是我發(fā)現(xiàn)其實(shí)還是有一種更加簡(jiǎn)單的方案的，那就是使用mget：

for(let i = 0; i < params.length; i++) {
 redisKey = getKey(params.id);
 arr.push(redisKey);
}
let value = await redis.exec('mget', arr);

使用mget進(jìn)行批量的查詢，這是redis里比較常見的一種方式了~

總結(jié)一下

在對(duì)以上四種方式進(jìn)行了對(duì)比之后得出了數(shù)據(jù)上的結(jié)論：

在一個(gè)200次的循環(huán)中調(diào)用redis請(qǐng)求，第一種最蠢的方案大概是8000ms左右，第二種Promise.all的方案大概在2000ms左右，而第三和第四種方案，大概只需要幾十ms就能完成，這真的是質(zhì)的飛躍啊。

這個(gè)線上血淋淋的案例讓我決定真的要好好的研究一下redis，不能再輕視它導(dǎo)致犯錯(cuò)。

好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論