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之后，便秘一下就通畅了，再也没有报警过，终于可以不用辞职了。