在社区里“Windows 和 Linux 系统下如何查看 Redis 的版本号”几乎每周都能翻出来一次。提问的人多半是刚装完 Redis 准备写第一个 demo结果连 redis-cli --version 和 redis-server --version 都分不清也有搞了几年运维的朋友换到 Windows、Docker 或者远程集群环境就卡壳。版本号这件事看着小实际上关联命令兼容性、客户端驱动选型、主从复制要求、CVE 漏洞核查很多线上故障翻来覆去排不完最后都会落回版本号这一条。这篇我结合自己跑过源码编译、包管理、Docker、Windows 移植版、WSL2 的实战经验把 Linux 和 Windows 的各种查法、容器与远程场景、还有几处容易翻车的细节一次说透。先记住一句结论查版本永远以运行中的 Redis 实际返回的信息为准不要靠安装文件名和记忆猜。1. 一条版本号命令背后藏着哪些真正的兼容性差异1.1 版本决定你手上的“武器库”很多人查版本号只是为了填文档其实版本号直接决定你手上能用的命令和数据类型。Redis 3.2 才引入 GEO 系列命令4.0 才支持模块系统、混合持久化和 PSYNC25.0 才有 Stream 类型和 redis-cli --cluster 集群管理工具6.0 加入 ACL 权限控制和 RESP3 协议7.0 推出 Redis Functions 和 sharded Pub/Sub。如果你业务代码里用了 XADD 写入 Stream服务端却停在 4.0.xRedis 当场就会报 ERR unknown command排查半天才发现是版本太老这种情况我遇到过不止一次。大版本标志性能力3.2GEO 地理位置命令4.0模块系统、混合持久化、PSYNC25.0Stream 类型、redis-cli --cluster6.0ACL、RESP3、多线程 IO、SSL/TLS7.0Redis Functions、sharded Pub/Sub等到了 7.2 和后续的 8.x命令和配置项还在持续演进所以“版本号”不是写文档凑数用的是实打实的能力边界。同一个命令在不同大版本返回格式可能都不一样比如 Info 的 section 参数、某些 Stream 命令的选项差一个版本就跑不通。1.2 版本决定安全修复与客户端驱动兼容安全公告里最常见的写法是“Redis x.y.z 之前版本存在某个漏洞”运维拿到公告后第一件事就是核对线上每个节点版本。版本查不准漏洞影响范围判断不了修复计划更是无从谈起。客户端驱动也一样Jedis、Lettuce、Redisson 都会声明自己支持的最低和最高 Redis 版本。比如你在 Redis 6.0 里启用了 ACL老版本客户端可能连认证流程都走不通报出来的错误跟权限八竿子打不着实际就是协议兼容问题。Redis 做中间件时版本基线不统一会让缓存治理变得很被动。1.3 版本是整个 Redis 排查链路的起点我处理过的运维故障案例里Redis command timed out、主从同步中断、内存统计异常这些问题排查到一半几乎都会回到版本号是不是某个节点版本不一致是不是某个命令在当前版本行为不同面试题里“你怎么确认 Redis 版本”也常被当作基本功来问背后考的是你对环境严谨性的理解。分布式锁、限流、缓存治理这些高阶主题全都建立在“版本口径正确”这个前提下。所以版本查看不是一行命令的事是整个 Redis 使用链路的地基。2. Linux 下的五种查法从最省事到最保险2.1 二进制自报版本两条最直接的命令Linux 下最朴素的办法就是找到 Redis 安装目录直接执行redis-cli --version # 输出redis-cli 7.2.4 redis-server --version # 输出Redis server v7.2.4 sha00000000:0 mallocjemalloc-5.3.0 bits64 build...注意这两条命令的区别redis-cli --version 显示的是客户端工具编译时的版本redis-server --version 显示的才是服务端程序版本。它们不需要 Redis 服务运行只要二进制在 PATH 里就能跑。很多新手习惯只敲 redis-cli --version严格来说你只查到了“工具箱”的版本没查到“发动机”的版本。检查环境时我通常两个都跑一遍顺便用 which redis-cli 和 which redis-server 确认命令来自哪个目录。2.2 服务在线时用 INFO server 拿运行版本如果 Redis 正在运行最权威的方式是用客户端连上去问服务端自己redis-cli -p 6379 INFO server | grep redis_version # 输出redis_version:7.2.4有密码记得带 -a 参数并加上 --no-auth-warning 避免告警刷屏远程环境再加 -h 指定主机redis-cli -h 192.168.1.10 -p 6380 -a 你的密码 --no-auth-warning INFO server | grep redis_version为什么说这是最权威的因为服务可能二进制替换过但还没重启也可能启动参数指向了别的目录只有运行中的进程返回的版本才是线上真实行为。INFO server 返回的字段也很丰富redis_version 之外还能看到 redis_mode、os、arch_bits、process_id对排查问题非常有价值。这条命令我建议所有运维同学刻进肌肉记忆。2.3 包管理安装的 Redis跟系统软件源对齐用 apt、yum 这类包管理装的 Redis还可以直接问包管理器# RPM 系 rpm -q redis # Debian 系 dpkg -l redis-server apt-cache policy redis-server这里有个常见坑发行版软件源里的 Redis 版本通常落后官方一大截。例如 Ubuntu 20.04 默认源装出来基本是 6.0.9而官方当时已经到 7.x。你在本地查出来是 6.0.9不代表你“装错了”只是发行版维护策略如此。理解这一点后面做缓存治理、讨论版本特性时才不会大惊小怪。2.4 源码编译安装在编译产物和源码里找版本自己源码编译的话版本信息其实写在源码里。Redis 源码的 src/version.h 文件中定义着版本号#define REDIS_VERSION 7.2.4 #define REDIS_VERSION_NUM 0x00070204编译完之后直接运行编译产物 src/redis-server --version 就能确认。如果是 git clone 的仓库可以用 git describe --tags --abbrev0 看当前代码接近哪个发布标签。还要提醒一句有些二次开发版本会改版本号带 -alpine、-custom 这类后缀看到别觉得奇怪那就是定制版。定制版的兼容性验证要更谨慎不能只看主版本号就下结论。2.5 多实例并存时把版本对应到具体进程一台 Linux 上经常同时跑 6379、6380、7000 多个 Redis 实例而且各自安装目录不同。这时候只查一次版本会以偏概全正确姿势是按端口逐个查for p in 6379 6380 7000; do echo port ${p}: redis-cli -p ${p} INFO server | grep redis_version done如果想确认某个端口对应的进程到底用的是哪个二进制ps -ef | grep redis-server 往往只显示 *:6379 这种监听字符串不显示完整路径。这时候可以用 /proc 下的软链接读出真实可执行文件ls -l /proc/进程PID/exe输出会直接指向 redis-server 的绝对路径。这个技巧在多实例排查时非常救命也是很多人容易忽略的细节。Redis 官方安装包和编译安装可能同时存在不靠这招很容易把不同实例的版本搞混。3. Windows 下查版本先分清你用的是哪一种 Redis3.1 Windows 上的 Redis 版本家族比想象中复杂官方 Redis 至今没有提供 Windows 原生安装包所以 Windows 上能跑起来的 Redis 主要有几条路线微软早期维护的移植版常见版本号像 3.2.100、4.0.14tporadowski 等社区维护的 5.0.14 移植版解压后目录名通常写着 Redis-x64-5.0.14还有 Memurai 这类商业兼容服务再就是通过 WSL2、Docker、虚拟机跑的官方 Linux 版本。不同来源的“版本号”语义并不完全一样所以在 Windows 上查版本之前先问自己一句我装的是哪条路线这个问题直接决定你接下来用哪种查法。3.2 打开 CMD 或 PowerShell 直接问 exeWindows 下最直接的办法和 Linux 一样在安装目录打开 CMD 或 PowerShell执行D:\Redis-x64-5.0.14 redis-server.exe --version # 输出Redis server v5.0.14 sha... bits64 ... D:\Redis-x64-5.0.14 redis-cli.exe --version # 输出redis-cli 5.0.14如果目录没加入 PATH就先用 cd /d D:\Redis-x64-5.0.14 切进去。除了命令行还可以右键 redis-server.exe 文件看“详细信息”里的“产品版本”或者直接看安装包文件名 Redis-x64-5.0.14.zip一般版本号都写在包名里。这些方法都不需要服务真正运行起来Windows 下识别版本最怕的就是“目录里多个版本并存”一定要确认自己执行的是哪个路径下的 exe。3.3 注册成 Windows 服务后的查法很多 Windows 机器把 Redis 注册成了系统服务开机自启。这种场景下可以打开“服务”管理窗口找到对应服务右键属性里能看到“可执行文件的路径”路径里通常就带版本号的目录名。命令行则可以用sc query Redis sc qc Redis Get-Process redis-server | Select-Object Path, ProductVersionsc qc Redis 输出的 BINARY_PATH_NAME 字段会直接给出 redis-server.exe 的完整路径顺着路径去查 exe 属性里的产品版本即可。注意新版 Windows 对 wmic 支持越来越不友好建议直接用 PowerShell 命令。如果你只是解压后双击 redis-server.exe 跑的黑窗口那最稳的还是老老实实用命令查别盯着窗口标题猜。3.4 WSL2 和 DockerWindows 用户最稳的版本口径如果条件允许我强烈建议 Windows 上做开发时用 WSL2 或 Docker 来跑 Redis。版本口径和 Linux 官方一致团队协作时 Linux 同事说“Redis 7.2.4”你这边也能立刻对齐。查看方法# WSL2 里 wsl redis-server --version # Docker 一行查镜像内版本 docker run --rm redis:7.2.4 redis-server --versionWindows 移植版虽然能用但少数命令行为、模块支持、性能特性跟官方版存在差异作为中间件长期跑在生产上风险控制成本比较高。版本查询这件小事恰恰是暴露这些差异的第一个环节。很多 Windows 下的“Redis 变慢了”“某个命令不支持”的问题根源都在版本来源不正规。4. 容器、远程和集群场景版本号不总在你眼前4.1 Docker 容器里的版本小心被宿主机带偏容器环境里最容易犯的错是用宿主机上 redis-cli 的版本去推断容器内服务端版本。正确做法是进容器查docker exec -it redis01 redis-server --version # 输出Redis server v7.2.4 ...也可以不进入容器直接看镜像标签docker inspect redis01 --format {{.Config.Image}} # 输出redis:7.2.4或者干脆拉一个临时容器查镜像内的程序版本docker run --rm redis:7.2.4 redis-server --version特别注意 docker 安装 Redis 主从时主库和从库如果用了不同版本的镜像大版本不一致很容易导致复制异常。我见过主从复制卡在 PARTIAL_RESYNC 阶段很久最后查下来是两个容器版本差了一个大版本升级一致后问题消失。搭建前逐容器确认版本比出问题再排查省太多时间。4.2 远程环境没有 redis-cli 时的土办法有些远程服务器很精简没装 redis-cli但 Redis 端口是开着的。这种情况下可以用 nc 或 telnet 直接跟 Redis 对话printf INFO\r\n | timeout 2 nc 10.0.0.8 6379 | grep redis_version加 timeout 是防止连接不自动断开导致命令卡住。telnet 也一样连上 6379 端口后手动输入 INFO 回车返回的大段文本里就有 redis_version。如果你会 Python用 redis 库更省事import redis r redis.Redis(host10.0.0.8, port6379, password你的密码) print(r.info().get(redis_version))这里有个小知识Redis 不像 MySQL 那样一连接就主动打印版本 banner必须主动发命令才能拿到信息。很多人第一次 nc 上去看到空白就以为连不通其实只要发 INFO 就出来了。4.3 集群、哨兵、主从多节点的版本核对集群环境和哨兵环境节点多版本往往不统一。redis-cli cluster nodes 只能看到节点 ID、IP、端口、slots 这些信息看不到版本号所以想确认集群各节点版本必须逐个节点执行for p in 6379 6380 6381; do echo node ${p}: redis-cli -p ${p} INFO server | grep redis_version done哨兵节点也可以这样查把端口换成哨兵端口即可。主从架构里官方建议主从大版本保持一致升级时一般先升级从库再切换主库这套操作的前提就是你能准确查到每个节点的当前版本。没有版本清单做升级计划迟早翻车。5. 查版本翻车实录与一套稳妥的核查流程5.1 坑一PATH 里的客户端和服务端不是同一个版本我自己踩过一个大跟头服务器上用源码编译装了 6.2 的 Redis 服务但系统里的 redis-cli 还是旧版本软链过来的redis-server --version 显示 6.2redis-cli --version 显示 5.0当时我信了后者排了大半天的问题最后发现是工具版本误导了我。所以查版本时最好两个命令都跑一遍用 which redis-cli 和 which redis-server 确认路径来源再结合 INFO server 的结果综合判断。客户端版本和服务端版本本来就可以不一致别被“看起来合理的数值”骗了。5.2 坑二Windows 移植版的版本号不能和官方版画等号Windows 上看到的 Redis 5.0.14 和 Linux 官方 Release 里的 5.0.14虽然版本号一样但底层实现、可用模块、某些命令的边界行为可能不同。遇到“版本号一样但表现不一样”的情况先确认对方的发行渠道。Memurai 这类兼容服务的版本号编码方式又不一样尽量在文档里明确写“Windows 移植版 Redis 5.0.14”而不是笼统写“Redis 5.0.14”能避免很多跨环境沟通歧义。5.3 坑三启动日志只能做佐证不能当唯一证据Linux 上 Redis 启动日志的第一行通常会打出版本比如 /var/log/redis/redis-server.log 里的 Redis server v6.2.14 sha00000000:0 ...很多人直接看日志头写版本。但这里有个隐性问题如果服务运行了很久、期间升级过 Redis 且没清日志日志头记录的可能是历史版本容器重启后再查看日志也可能已经被轮转覆盖。所以启动日志适合做辅助判断最终确认还是要靠 INFO server 返回的实时信息。5.4 一套稳妥的日常核查流程也是面试能说的版本基础我把日常环境版本核查整理成一个固定流程你直接照着做就行场景首选方法Linux 本机服务在线redis-cli INFO server 过滤 redis_versionLinux 本机服务未启动redis-server --versionWindows 解压版进入目录执行 redis-server.exe --versionWindows 服务方式Get-Process redis-server 查路径与产品版本Docker 容器docker exec -it 容器 redis-server --version远程环境无客户端用 nc/telnet 发送 INFO 命令集群/哨兵多节点循环端口执行 INFO server整个流程就五步先明确你想查的是客户端还是服务端服务在线时一律以 INFO server 为准多实例用端口或 PID 隔离确认容器环境进容器或看镜像 tag拿到版本号后对照官方 Release Notes 补一句“这个版本支持哪些命令、有没有已知 CVE”。这套动作熟练之后Redis 面试里关于版本、数据类型、分布式锁、缓存治理的连环问你手里就已经攥着最扎实的一环了。我个人的体会是版本号这件事难的不是敲那几条命令而是对“我到底在查什么”保持清醒。每次接手新的 Redis 环境我都会先跑一遍 INFO server把 redis_version、redis_mode、os 这几个字段存档再决定要不要继续排查别的。版本号不要靠猜也不要靠记忆让运行中的 Redis 自己告诉你答案这比什么都稳。