Spring Data Redis Reactive中使用Lettuce时，返回Flux的keys命令是否仍有性能问题

首先给出明确结论：哪怕返回值是 Flux 类型，KEYS 命令的高开销属性也不会因为响应式封装就消失，生产环境依然属于需要严格规避的操作。

为什么会产生“响应式下KEYS是不是变安全了”的错觉 #

• 很多响应式初学者会看到keys()方法返回Flux，就误以为这是流式拉取的模式，觉得Redis会每扫到几个key就推给客户端，不会长时间占住服务端资源，但实际底层实现完全不是这样。
• Lettuce的响应式实现、Spring Data Redis Reactive 封装的keys()方法，只是把Redis返回的完整key列表在客户端侧拆分成流元素发射给订阅者，Redis服务端执行KEYS的逻辑和你用redis-cli、阻塞式Jedis客户端调用时完全一致：单线程全量遍历整个keyspace，直到把所有匹配规则的key全部找出来，才会把完整结果一次性通过网络返回给客户端。这个过程中Redis的核心事件循环会被全程占住，阻塞时长和非响应式场景没有任何差别。
• 打个通俗的比方：这个过程就像你点外卖，KEYS命令是餐厅把整桌菜全部做完打包好才一次性给骑手，骑手拿到餐之后再分给每一个取餐的顾客；而不是餐厅做一道菜就给骑手送一道。客户端的Flux只是骑手的分发动作，完全没有加快餐厅出餐、减少餐厅厨房占用时间的作用。
• 响应式封装唯一改变的是客户端侧的阻塞状态：你的应用服务端的NIO工作线程不会因为等待Redis返回结果就被挂起卡住，不会因为这个操作耗尽应用侧的线程资源，但这完全没有降低Redis服务端本身的执行开销。

响应式场景下的风险传导逻辑 #

很多初学者会默认“我用了响应式，整个链路就都是非阻塞的”，但实际风险只是从应用侧转移到了Redis侧：

• 如果你的实例上存储了数十万甚至上百万个key，执行一次全量匹配的KEYS *操作，依然会把Redis单线程堵到完全没法响应其他读写请求，严重时甚至会触发主从复制超时、集群节点心跳中断、主从切换等线上故障。
• 这种故障和你用哪种客户端、哪种编程模型没有关系，只要触发了KEYS命令的全量扫描，Redis侧的阻塞效果是完全一样的。

正确的实践原则 #

• 仅在开发、测试等隔离环境，数据量极小（百级以内key规模）的临时调试场景，可以短期使用KEYS命令降低调试成本。
• 生产环境哪怕是全响应式技术栈，也必须用SCAN系列命令替代KEYS——Spring Data Redis Reactive 提供的scan()方法本身就返回Flux类型，匹配响应式的流式编程模型，Redis侧是分批迭代扫描的，不会长时间阻塞事件循环，完全可以覆盖绝大多数需要遍历key的业务场景。

内容的提问来源于stack exchange，提问作者bruno.zambiazi