這篇文章主要給大家介紹了關於node上redis調用優化的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨着小編來一起學習學習吧
前言
如果一個 Node 應用有多臺服務器或多個進程在跑，每個進程都擁有自己的內存空間，各個進程之間的數據共享就顯得非常重要。
使用數據庫是一個解決數據共享的方案，但一些臨時性、高併發的數據並不太適合直接寫入數據庫，比如 session。
引入 Redis 可以解決數據共享的問題，也因爲 Redis 是基於內存存儲的特點，有着非常高的性能，可以大大降低數據庫讀寫的壓力，提升應用的整體性能。
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機制大家可以看這篇文章。在使用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，不能再輕視它導致犯錯。
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對神馬文庫的支持。