做了个支持千万级 Keys Redis 桌面客户端，支持 Java 字节码反序列化，求拍

生产环境的 Redis 经常达到千万级 Key 。很多桌面 GUI 一旦连上这类实例，就会出现界面卡顿、内存持续上涨，甚至进程崩溃。打开成员较多的 Hash / ZSet 时，如果客户端试图一次性拉取全部数据，窗口同样容易失去响应。

基于这类问题，我重新设计了另一套加载与渲染路径的软件 RedisViewer——一款面向研发调试的本地 Redis 桌面客户端。它的目标是：采用虚拟滚动应对千万级别数据量，并在超大库场景下增加加载确认，避免误操作拖垮客户端。

把「加载」和「渲染」分开处理

不少 Redis GUI 把两件事绑在一起：Key 如何从 Redis 拉取，以及每一行如何绘制到界面上。数据量上来之后，问题会同时放大。

RedisViewer 的处理方式是：

• 按条件加载目标 Key 。 通过 ScanConfig 配置查询条件（默认 pattern 为 *），使用 Redis SCAN 完成目标 Key 的完整扫描与加载。研发环境里，这样可以直接拿到完整结果集，减少反复点击扫描更多分页带来的麻烦。


• 大库先确认。 当 DBSIZE ≥ 10 万（阈值可配置，对应「 SCAN 免确认」）时，加载前会要求确认，降低误扫生产库的风险。


• 只渲染可见区域。 Key 列表使用虚拟滚动，结果集规模不等于界面节点规模，有助于控制内存并保持滚动流畅。

Hash / Set / ZSet 成员走另一套策略：分页异步加载，避免一次全量返回把界面卡住。集合规模到数万甚至十几万成员时，差异会比较明显。

概括一下：研发场景默认按条件全量加载目标 Key ；库规模较大时先确认；列表始终虚拟渲染。 在千万级实例上兼顾流畅性和内存占用，主要依靠这三点。

Java 场景下的值查看与编辑

Java 服务写入 Redis 的内容经常不是普通字符串：

• 
  

  JDK 序列化：直接查看反序列化后的对象结构
  

  
  


• 
  

  转义 / 控制字符：可视化查看与编辑，减少对着原始十六进制猜测的成本
  

  
  


• 
  

  Jackson / Fastjson 多态 JSON：按结构查看并编辑
  

  
  

当需要核对缓存内容是否与业务对象一致时，仅靠 GET 往往不够。

本地完成常见性能排查

除了 Key 浏览，RedisViewer 也覆盖常见排查入口：

• SlowLog：定位慢命令


• BigKey：内存持续上涨时查找大 Key


• HotKey：短时 MONITOR 采样，识别热点 Key / 高频命令


• MONITOR：短窗口查看实时命令流


• Command stats：观察命令分布，区分业务流量与监控/连接噪声

常见用法是先看 CPU 、内存、命令量、命中率等趋势，再进入 SlowLog / BigKey / HotKey 下钻。数据在本地处理，不会上传到 RedisViewer 服务器。

本地优先，免费，跨平台

连接凭据本地加密保存；可选 WebDAV 仅用于同步连接配置。Redis 的 Key / Value 不会上传。

支持 Windows / macOS / Linux ，免费使用。

下载地址： https://redisviewer.com

欢迎反馈：研发环境里，你更习惯「按条件一次加载完整结果集」，还是「始终分页加载」？你现在用的 GUI ，通常先在 Key 列表、大集合，还是内存占用上出问题？