您不必在乎当前命令的执行，而在乎对其他所有命令的影响，因为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之类的命令的不利影响，这些命令在被调用时可能会长时间（甚至几秒钟）阻塞服务器大量的键或元素集合
。
