Redis中SCAN与KEYS的性能
包括官方Redis文档在内的许多资料都指出，KEYS由于可能会阻塞，在生产环境中使用该命令是一个坏主意。如果已知数据集的大致大小，相对于而言，是否SCAN有任何优势KEYS？
例如，考虑一个数据库，该数据库最多具有100个以下形式的键：data:number:X其中，X是整数。如果要检索所有这些，可以使用命令KEYS data:number:*。这会比使用慢得多SCAN 0 MATCH data:number:* COUNT 100吗？还是在这种情况下这两个命令基本相同？可以说这SCAN是更好的选择，KEYS因为它可以防止出现意外的大集合返回的情况，这是否更可取？
问题答案：
您不必在乎当前命令的执行，而在乎对其他所有命令的影响，因为Redis使用单个线程来处理命令（即，在执行命令时，所有其他命令都需要等待直到执行一个结束）。
虽然keys还是scan可能会提供你的情况，单独执行你相似或相同的性能，几毫秒阻挡的Redis会显著降低整体I / O。
这是keys用于开发目的和scan生产环境的主要原因。
OP说：
“虽然键或扫描可能会为您提供单独执行的相似或相同的性能，但阻塞Redis的几毫秒会大大降低总体I / O。”
-这句话似乎表明一个命令阻止了Redis，而另一个则没有，这不是事实。如果可以保证我从KEYS呼叫中获得100条结果，那么哪种方式比SCAN糟糕？为什么您觉得一个命令更容易阻塞？
可以分页搜索时，应该会有很大的不同。被迫一次获得100个按键与能够实现分页并以10乘10（或50和50）的方式获得100个键并不相同。
这种很小的中断会使Redis处理应用程序层发送的其他命令 。查看Redis官方文档对此有何评论：
由于这些命令允许增量迭代，每个调用仅返回少量元素，因此可以在生产中使用它们，而不会受到诸如KEYS或SMEMBERS之类的命令的不利影响，这些命令在被调用时可能会长时间（甚至几秒钟）阻塞服务器大量的键或元素集合
。
-
本文向大家介绍redis 用scan指令 代替keys指令(详解)，包括了redis 用scan指令 代替keys指令(详解)的使用技巧和注意事项，需要的朋友参考一下 众所周知，当redis中key数量越大，keys 命令执行越慢，而且最重要的会阻塞服务器，对单线程的redis来说，简直是灾难，终于找到了替代命令scan。 SCAN cursor [MATCH pattern] [COUNT
-
我正在使用带有npm包的node.js脚本来检索匹配模式的所有Redis键。匹配的一个示例是关键字。 使用Redis 4.0.11、Node.js 8.11.3、Redis 2.8.0 npm包 重新启动Redis。仍有不完整的扫描结果 删除了与模式匹配的所有键，并将一些键添加回来。现在所有的东西都在扫描时返回。在一个小时的播放后，它再次开始返回不完整的结果。重复此操作将无法修复此问题。
-
我对这个项目很感兴趣，想了解更多关于RedisGgraph内部的信息，并寻找Redis-Streams和Redis-Ggraph模块之间互操作性的可行性。 因此，我想知道您在Redis的哪些本地数据结构中构建了您自己的“图形数据”数据结构，当我们运行TYPE myGgraph命令时，该数据结构会显示出来。 是RedisGgraph模块（或其子组件、节点、边、路径）内部的图，是建立在Redis的已知
-
scan 持续的将 Observable 的每一个元素应用一个函数，然后发出每一次函数返回的结果 scan 操作符将对第一个元素应用一个函数，将结果作为第一个元素发出。然后，将结果作为参数填入到第二个元素的应用函数中，创建第二个元素。以此类推，直到遍历完全部的元素。 这种操作符在其他地方有时候被称作是 accumulator。 演示 let disposeBag = DisposeBag() O
-
scan 函数签名: scan(accumulator: function, seed: any): Observable 随着时间的推移进行归并。 此操作符是许多基于 Redux 实现的 RxJS 的核心！ 示例 示例 1: 随着时间的推移计算总数 ( StackBlitz ) // RxJS v6+ import { of } from 'rxjs'; import { scan } from