是否有用于 node.js 的阻塞 redis 库？答案

【问题标题】：Is there a blocking redis library for node.js?是否有用于 node.js 的阻塞 redis 库？
【发布时间】：2011-05-23 15:06:27
【问题描述】：

Redis 非常快。大多数情况下，在我的机器上，它与 node.js 中的原生 Javascript 语句或函数调用一样快。在 node.js 中编写常规 Javascript 代码很容易/无痛，因为不需要回调。我不明白为什么使用 node.js 在 Redis 中获取/设置键/值数据不应该那么容易。

假设 node.js 和 Redis 在同一台机器上，是否有任何 npm 库允许使用阻塞调用与 node.js 上的 Redis 交互？我知道这必须是一个与 V8 接口的 C/C++ 库。

【问题讨论】：

你不想阻塞节点中的库。
你能解释一下为什么你想以一种引人注目且有用的方式对 nodejs 进行阻塞调用吗？
我知道阻塞调用会造成巨大的瓶颈。我可以使用原生 Javascript 函数（例如：正则表达式等）并以阻塞方式循环，在 V8 中执行得非常快。如果获取/设置 Redis 数据几乎可以一样快，为什么我不能使用一些具有 getSync、hsetSync 等功能的阻塞 Redis 库？这使得编写代码更容易（val = client.getSync(key); #1 行）而不是使用回调（3 行以上）。
你高估了“几乎”。 redis 的速度至少是 for 循环和正则表达式的 1000 倍。
如果要处理阻塞调用，为什么选择使用 node.js？

标签： node.js redis npm

【解决方案1】：

我想您想确保您的所有 redis 插入操作都已执行。为此，您可以使用 MULTI 命令插入键或执行其他操作。 https://github.com/mranney/node_redis 模块将多对象推送的命令排队，并相应地执行。

这样你只需要一个回调，在 exec 调用结束时。

【讨论】：

很好的权衡！一个回调，一个运行多个命令的单个多块，一起帮助我避免了长回调意大利面。
很好，它对你有用 :)。我遇到了同样的问题，这就是我克服它的方法：D。更不用说性能提升了，再也没有瓶颈了。
不，你不需要 MULTI，你只需要流水线，这就解决了这个问题。
并使用Q 来避免长回调意大利面。 github.com/kriskowal/q
我只想指出，nodejs 可能被用作单用户桌面应用程序的平台。它不必用于服务器。

【解决方案2】：

对于试图习惯 Node 事件编程模型的开发人员来说，这似乎是一个常见的陷阱。

发生的情况是这样的：您遇到了异步/回调模式不适合的情况，您认为您需要的是某种执行阻塞代码的方法，您向 Google/StackExchange 询问 Node 中的阻塞问题，然后你得到的只是关于阻塞有多糟糕的警告。

他们是对的——阻塞，（“在做其他事情之前等待这个结果”），不是你应该在 Node.js 中尝试做的事情。但我认为更有帮助的是认识到 99.9% 的时间，你并不是真的在寻找一种方法来做阻塞，你只是在寻找一种方法来制作你的应用程序，“等待结果在继续这样做之前，”这并不完全相同。

尝试在 Node 中研究“流控制”的概念，而不是“阻塞”某些可能更适合您尝试做的设计模式的设计模式。以下是要查看的库列表：

https://github.com/joyent/node/wiki/modules#wiki-async-flow

我也是 Node 新手，但我真的很喜欢 Async：https://github.com/caolan/async

【讨论】：

+1 用于指出一个好的、可用的工具。我想补充一点，yield / 生成器指日可待（已经在不稳定的 0.11.x 中）；在github.com/loveencounterflow/coffy-script 上，我试图展示它对于缓解一些异步担忧是多么有用。
您可以破解开源 google v8 引擎，并可能添加多线程和条件变量。

【解决方案3】：

阻塞代码会造成MASSIVE瓶颈。

如果您使用阻塞代码，您的服务器将变得难以置信缓慢。

记住，节点是单线程的。所以任何阻塞代码，都会为每个连接的客户端阻塞节点。

您自己的基准测试表明它对于一个客户端来说已经足够快了。您是否对 1000 个客户进行了基准测试？如果你试试这个，你就会明白为什么阻塞代码是不好的

【讨论】：

这显然会否定 node.js 的好处。 +1
我不相信同步访问运行在与 node.js 相同的服务器上的 Redis，会产生巨大的瓶颈。我在 Redis key/val DB 上的大多数 get/set 操作都快如闪电。
@pm8 对于一个客户来说，它们的速度快如闪电。但是如果你同时为 1000 做这件事呢？巨大的瓶颈。
信任事件堆栈。如果 1000 个客户端每个阻塞甚至 10 毫秒，那将是您最后一个响应发出之前的 10 秒。在这 10 秒内，其他客户端将等待，您的站点将无响应。史诗级服务器减速。

【解决方案4】：

虽然 Redis 很快，但它不是即时的……这就是为什么如果您想继续执行以确保您的值在那里，您必须使用回调。

我认为您可以（并不建议您这样做）实现此目的的唯一方法是使用带有变量的回调，该变量是离开计时器的谓词。

【讨论】：