研究一下在Node.js中使用的redis客户端哪个更好

2 年 ago

雅, 悟

1 minute

首先

这是zenn文章的转载。

为了以后转向在PaaS上进行开发，我们决定开始使用Node.js。在此期间，我们正在调查将要使用的Redis客户端库。突然想到，我之前从未总结过这类事物的调查方法和思考方式，所以我打算稍微总结一下，以便与后辈们进行共享。

候补 → ioredis 或 node-redis

首先，我們會尋找候選人。
由於 Redis 官方給出了推薦，我們會直接參考它。
星號表示推薦，尼可小姐標誌表示開發活躍（過去六個月有動作的項目）。

以下的三个仓库都被推荐了呢。

tedis

由于tedis是最后一个星数较少的，而且在redislabs的文档参考中也没有提及tedis，所以我们暂时忽略它。

node-redisのdoc

以下是一种选项的原生中文释义：

对比

由于候选人已经缩小到两个，所以我们将进行比较。基本上，我们需要查看它们各自的背景，然后进行当前趋势和性能的比较。如果两者都有好的方面，我们将列出它们的优点和缺点进行比较，但最终结果会是怎样呢？

对于機能来说，ioredis比node-redis更好。

最初是由Node Redis团队创建的node-redis，在2010年开始至今一直活跃。

然而，看起来ioredis不支持Promise、Redis的管道等一些功能。因此，Alibaba的一位工程师Zihua Li开发了ioredis。

从功能角度来看，我们可以认为ioredis是可向上兼容的。

node-redisのpromiseはv4で正式サポートされるそうです

性能 → ioredis <= node-redis
性能方面，ioredis 不逊于 node-redis。

请参考以下内容。

poppinlp/node_redis-vs-ioredis的比较

两者几乎相同，但是使用multi进行操作时，在批处理和管道比较中，node-redis稍微领先一点点。

当提到”batch”时，它是使用node-redis提供的multi命令执行并将结果汇总在一个回调中的功能，对于用户来说类似于pipeline的功能。

人气 → ioredis >> node-redis

我参考了以下内容。(npm趋势，好网站呢)

ioredis和node-redis的比较

截至2021年7月23日的过去6个月的记录显示，ioredis的下载次数和星标数都遥遥领先。

其他

在大型云服务提供商中，示例中的许多选项使用了node-redis库。

AWS -> ioredis

请参考使用Amazon ElastiCache for Redis开发的Chat应用的示例代码。

我们之前使用的是ioredis。

GCP -> node-redis

请参考从Cloud Functions到Redis实例的连接示例代码。
您正在使用node-redis库。

Azure -> node-redis, ioredis

快速入门：在 Node.js 中使用 Azure Cache for Redis 的示例代码中，看到了使用 node-redis 的示例。虽然我失去了链接，但也有 ioredis 的示例。

从轻轻谷歌的感觉来看，node-redis似乎有更多的示例。这可能是因为它的历史更长。然而，并不意味着ioredis的示例很少，所以在这方面它们并没有明显的优越性。

基本上ioredis是个不错的选择。

我要重新整理调查结果。

性能: ioredis <= node-redis 人気: ioredis >> node-redis

从性能角度来看，ioredis似乎更占优势。就我个人而言，我也持有以下的观点。

機能や互換性とかはどうでもいい、とにかく少しでも速いものが欲しいんじゃ！って人はnode-redis

我們將進一步深入探討以下的原因。

为什么得出这个结论？

以下是理由。

以下是原因。

以下是解释。

以下是说明。

node-redisでは次バージョンまでpromiseがないこと

redis機能の充実度合い

性能向上に貢献しているpipelineがnode-redisは非サポート
redisで提供している機能を使った性能を考えると、ioredisの方が性能がいいとも言える

没有承诺

这是显而易见的。如果没有promise，JavaScript代码将变得非常复杂，因此没有promise真是令人痛苦。
但考虑到它将在版本4中得到支持，未来可能会消失的优势。

Redis功能的完善程度

关于没有使用 Pipeline 的问题。这里，在 node-redis 的官方讨论中也提到了引入 Pipeline 的问题。然而，由于 Redis 提供的 Pipeline 机制存在缺点，所以决定不采用。可能会有批处理作为替代方案。

但是，实现Redis的客户端的标准协议的库，却没有实现官方提供的功能，而是通过自己的方式提供相同的功能，这真的让人感到非常不舒服。如果在使用Redis功能的基础上再加上额外的功能，我可以理解。但是如果官方针对Pipeline的缺点对Redis进行更新，没有使用Pipeline的Node Redis就无法获得好处。
感觉ioredis对标准协议的处理方式更符合应有的形式。

当然，在性能严苛的世界中，速度才是正义！定制化至上！这是我的观点。
但是我只需要达到一定的性能水平，就足够满足在这个世界中的需求，基本上我想要通过使用redis的功能来改善性能。
因此，作为redis的功能之一，我已经实现了pipeline，并且在此基础上，性能出色的ioredis成为了首选。

真的需要pipeline吗？这是个问题。

有些人可能不需要使用pipeline，所以我认为这个优势并不适用于所有人。

就像在Sharing: Redis get pipeline vs mget的实测中看到的那样，可以更接近的是mget比pipeline更快。如果速度是正义的话，那么就没有必要使用pipeline，mget就足够了！

然而，正如文章中所述的优缺点一样，pipeline在使用上非常方便，因此redis中可以使用的功能更多仍然具有优势。个人而言，我目前也在使用redis，并且在其中利用了pipeline来提高使用便捷性，所以我认为提供pipeline功能是一个优势。

当然我对上述感到并不优势→ 还有node-redis可以选择

我已经详细列举了一些理由，但是关于promise的问题将在后面消失，对于不使用redis功能的人来说，这个问题也不重要。

所以，我认为可以决定使用性能稍有优势的node-redis，而不用担心这些问题！具体的判断应该基于什么呢？

最後

我已经写完了从调查到得出结论的图书馆选择过程，但最后结果仍然受到团队和个人的情况和喜好的影响。情况和观点稍有不同，评价就会变得不同，所以一旦集齐了令人满意的要素，就只剩下做出决策了，感觉就是这样。

为了对这个决定感到满意，可能需要每天学习事物的最佳实践和设计理念，以扩大基础。

参考:
请用中文来改写以下句子，只需提供一个版本：

如果你在Node.js中使用Redis，推荐使用ioredis。

除了文章中附带的链接之外，其他内容可原生中文重述。

首先