1. 为什么先查版本号再动手先讲个真实场景。组里新来一个同事环境里 Redis 报错了一上来就翻文档查配置折腾半天没头绪。我过去看了一眼先问了一句你这里的 Redis 是什么版本他愣了一下说没看过。其实这个习惯很要命——Redis 的版本差异比大多数人想象中要大得多5.0 之前没有 Stream 数据类型6.0 才引入多线程 I/O7.0 的 AOF 重写机制直接换了底子。同样的配置在 5.0 上跑得好好的搬到 7.x 可能启动都起不来。所以每次碰 Redis 环境第一步不是急着改配置而是先搞清楚版本号。这就像你接手一台车不知道它是手动挡还是自动挡也不知道加的是汽油还是柴油上来就踩油门不出问题才怪。查看 Redis 版本号这件事听起来简单但实际在 Windows 和 Linux 两套系统下操作路径完全不一样。因为 Redis 官方其实只把 Linux 当作一等公民Windows 下的 Redis 是社区移植版本安装方式和命令形式都有微妙差异。这篇文章就把两套系统下的查询方法全部捋一遍帮你在任何环境下三秒钟定位版本。2. Linux 系统下查看 Redis 版本号的几种方式2.1 命令行直接查看redis-server 与 redis-cli 的双通道Linux 下最直接的思路就是从两个程序入手服务端程序redis-server和客户端程序redis-cli。它们都内置了版本号参数执行方式如下redis-server --version redis-cli --version执行后你会看到类似这样的输出Redis server v7.2.4 sha00000000:0 mallocjemalloc-5.3.0 bits64 build7f8b7c05d0a0e290redis-cli --version的输出更简洁一些通常直接告诉你redis-cli 7.2.4。这里有个细节值得注意redis-server --version输出的信息量更大包含了内存分配器的类型比如 jemalloc、系统位数64 位、编译构建哈希等。这些信息在你排查性能问题或者编译问题时特别有用。比如你看到mallocjemalloc-5.3.0就知道当前用的是 jemalloc 内存分配器而不是 libc 的 malloc这在分析内存碎片率指标时有参考价值。2.2 登录实例后通过 INFO 命令查询运行态版本命令行的--version参数查的是程序文件本身的版本但有时候你更关心的是“当前正在运行的 Redis 实例”的版本。两者大部分时候一致但如果你机器上装了多个版本的 Redis或者用了 Docker 映射、云厂商提供的托管实例文件版本和运行版本就可能存在偏差。这时候需要用客户端连上实例执行 INFO 命令redis-cli 127.0.0.1:6379 INFO server输出里有一段专门列服务端信息# Server redis_version:7.2.4 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:7f8b7c05d0a0e290 redis_mode:standalone os:Linux 5.15.0-91-generic x86_64 arch_bits:64 multiplexing_api:epoll process_id:12345 run_id:8d4c5a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f tcp_port:6379 uptime_in_seconds:120345 uptime_in_days:1重点是redis_version这一行。这是 Redis 实例真实运行时的版本号也是最权威的判定依据。相比命令行直接--versionINFO 模式还有额外收获你能看到redis_mode是 standalone 单机模式还是 sentinel 哨兵模式或者 cluster 集群模式、multiplexing_apiLinux 下是 epollmacOS 下是 kqueueWindows 下是 win32 线程模型以及进程 ID、运行时长等状态信息。判断运行态版本还有一个办法就是看启动日志。Redis 每次启动时都会在日志头部打印版本信息12345:M 15 Oct 2024 10:23:45.678 * Redis version7.2.4, bits64, commit00000000, modified0, pid12345, just started在一些不方便执行命令的极端场景下比如你没装 redis-cli翻日志反而更快。2.3 通过包管理器查询安装版本如果是用系统包管理器安装的 Redis还可以从包层面确认版本。不同发行版的查询方式不太一样# Debian / Ubuntu apt list --installed | grep redis # CentOS / RHEL / Fedora rpm -qa | grep redis # 通用方式 redis-server --version需要说明的是包管理器显示的版本号是发行版打包时的版本可能会有小版本差异。比如 Ubuntu 的 apt 源里 Redis 版本可能停留在 6.0.16而官方最新已经到 7.2 了。如果你要追求较新的功能就得考虑添加官方源或者源码编译安装。源码编译安装的话还可以在编译目录下直接查询# 在 Redis 源码根目录执行 src/redis-server --version编译安装的 Redis 默认不加入系统 PATH需要你手动指定路径很多人就在这里栽了跟头——执行redis-server --version提示 command not found不是没装是路径没找到。2.4 一键组合查询脚本把多种查询方式组合起来可以做一个脚本一次执行拿到所有关键版本信息。我在排查问题的时候经常用这个#!/bin/bash echo redis-server 版本 redis-server --version 2/dev/null || echo redis-server 不在 PATH 中 echo echo redis-cli 版本 redis-cli --version 2/dev/null || echo redis-cli 不在 PATH 中 echo echo 运行实例版本 redis-cli -h 127.0.0.1 -p 6379 INFO server 2/dev/null | grep redis_version || echo 无法连接 Redis 实例 echo echo 系统包版本 if command -v rpm /dev/null 21; then rpm -qa | grep redis 2/dev/null || echo 未通过 rpm 安装 elif command -v dpkg /dev/null 21; then dpkg -l | grep redis 2/dev/null || echo 未通过 dpkg 安装 fi这段脚本分四步先查程序本身的版本再查客户端版本然后尝试连接实例查运行态版本最后从包管理器层面兜底。四路信息交叉验证基本上不可能误判。3. Windows 系统下的特殊情况和查看方法3.1 先理清 Windows 下 Redis 的来路Windows 下查看 Redis 版本号第一个要搞清楚的问题是你的 Redis 到底是从哪来的Redis 官方并不提供原生 Windows 版本。官网下载页面只提供 Linux 源码包Windows 下的 Redis 都是社区移植的产物。目前常见的几种来源是微软维护的移植版微软曾长期维护一个 Windows 移植分支基于 Redis 3.x / 5.x / 6.x 的版本改造下载包里直接是redis-server.exe和redis-cli.exe。tporadowski / memurai 等第三方移植版这是目前 Windows 下使用较广的 Redis 发行版tporadowski 维护的版本更新到 5.0.14Memurai 则是商业级的 Windows 原生 Redis 兼容实现。WSL / Docker 里跑的 Linux 版 Redis这是目前比较推荐的方式相当于在 Windows 上跑一个 Linux 环境里面运行的实际上是 Linux 版本。绿色免安装版解压即用一个文件夹涵盖所有 exe 文件。搞清楚来源之后再选择对应的查询方式。因为不同来源对应的可执行文件名称可能不一样比如有的叫redis-server.exe有的叫redis.windows.conf里的服务名被注册成了系统服务。3.2 Windows 命令行下查询版本号如果是微软移植版或 tporodowski 版查询方式和 Linux 没有本质区别就是带上.exe后缀# 进入 Redis 解压目录后执行 .\redis-server.exe --version .\redis-cli.exe --version输出内容和 Linux 下大同小异Redis server v5.0.14 sha00000000:0 mallocjemalloc-4.0.0 bits64 build5c8b3a2f9a9f5a77这里有个 Windows 特有的小坑如果 Redis 是注册成了 Windows 服务比如用redis-server --service-install安装的在任务管理器里你能看到redis-server.exe进程正在跑但你在命令行直接执行redis-server --version可能会得到错误的版本号——因为 PATH 环境变量里如果同时存在多个版本的 Redis优先找到的不一定是正在运行的那个。正确的做法是找到正在运行进程的真实路径用完整路径执行版本查询Get-Process redis-server | Select-Object Path # 假设得到 C:\redis\5.0.14\redis-server.exe C:\redis\5.0.14\redis-server.exe --version这就是我前面说的“文件版本”和“运行版本”可能不一致的典型场景。在 Windows 上这种混乱的情况更常见因为大家经常下载多个版本的压缩包到处解压环境变量也设置得比较随性。3.3 用 redis-cli 连接后查看运行实例版本Windows 下同样可以用 INFO 命令查运行态版本.\redis-cli.exe -h 127.0.0.1 -p 6379 127.0.0.1:6379 INFO server注意 Windows 移植版默认配置文件里可能没有设置requirepass所以默认不需要密码就能连接。如果你设置了密码连接时要加上-a参数或者进入交互模式后用 AUTH 命令验证否则 INFO 命令会直接报错(NOAUTH Authentication required.此时执行.\redis-cli.exe -h 127.0.0.1 -p 6379 -a 你的密码 INFO server或者进入交互模式后127.0.0.1:6379 AUTH 你的密码 OK 127.0.0.1:6379 INFO server3.4 用 Redis Desktop Manager 等可视化工查看实例版本如果你习惯用 Redis Desktop Manager现在的正式名称为 Redis Insight这类图形客户端连接 Redis版本信息同样唾手可得。连接上实例之后通常在“服务器信息”或“关于”面板里就能直接看到redis_version字段不用敲命令。这对 Windows 用户特别友好因为 Windows 下敲命令的体验确实不如 Linux 顺畅而且 GUI 工具还能直观展示内存使用、键数量、连接数等运行状态是日常运维的好帮手。不过提醒一句可视化工具显示的版本是“实例版本”也就是服务端运行的 Redis 版本。如果你的客户端连接的是一个远程 Linux 服务器上的 Redis那么你看到的是服务器上的版本和你本机下载了什么版本的 exe 毫无关系。这一点在排查问题时要分清。需要远程连接时我比较推荐用 Redis Insight 或者 redis-cli 直接连别图省事在本机开一个 Redis 然后对着它操作。3.5 WSL 与 Docker 环境下的查询方式越来越多的人开始用 WSLWindows Subsystem for Linux或者 Docker Desktop 在 Windows 上跑 Redis这种情况下查询版本走的是 Linux 那套逻辑。WSL 里安装的 Redis直接在子系统终端里执行wsl redis-server --versionDocker 里的 Redis需要先确认容器名然后进入容器或者在宿主机上用 docker exec 执行# 查看容器列表 docker ps # 进入容器内部查询 docker exec -it 容器名 redis-server --version # 或者在容器内执行 redis-cli docker exec -it 容器名 redis-cli INFO server我个人比较推荐在 Windows 上用 Docker 跑 Redis理由有三点第一Docker 镜像里的 Redis 是官方构建的兼容性和稳定性比 Windows 移植版好。第二版本跟着镜像走想用哪个版本直接切换镜像标签不必反复下载压缩包。第三Redis 6.x / 7.x 的新特性在 Windows 移植版上更新很滞后而 Docker 里的官方镜像基本是发布当天就同步。切换镜像版本的命令也很简单比如docker pull redis:7.2.4 docker run -d --name redis-7 -p 6379:6379 redis:7.2.44. 版本号信息解读与版本选型的门道4.1 版本号格式不只是三段数字Redis 的版本号遵循语义化版本规范基本格式是主版本号.次版本号.修订号比如 7.2.4。偶尔还会看到后缀比如 7.0.15、6.2.16这些是修订版主要修 bug 和安全漏洞不引入新功能。主版本号的变化意味着有较大的架构或功能调整。Redis 5 引入 Stream 数据类型6 引入多线程 I/O 和 ACL访问控制列表7 重构了 AOF 机制并引入函数功能。次版本号更新通常是在主版本框架内增加新功能比如 6.2 在 6.0 基础上增加了更多命令和配置项。修订号就是纯修修补补。还需要注意redis_version和redis_git_sha1、redis_git_dirty这两个字段。如果你拿到的是源码编译的开发版redis_version可能是 7.9.999 这样的占位符版本真正的版本信息要靠 commit 哈希来定位。redis_git_dirty为 1 时表示当前编译的源码有未提交的修改这种情况常见于自己改了源码重新编译的场景。4.2 不同“发行版”的版本差异Redis 官方现在的版本体系比早期复杂了一些除了开源的 Redis 原版还有 Redis Stack 这种集成模块的发行版。Redis Stack 内置了 JSON、Search、TimeSeries、Bloom 等扩展模块它的版本号格式跟 Redis 保持同步比如 Redis Stack 7.2.0 对应 Redis 7.2.0。查询 Redis Stack 版本时如果用的是redis-server --version输出和 Redis 原版没有太大区别但用INFO modules命令能看到已经加载的模块及各自版本# Modules module:namesearch,ver20810,api1,filters0,usedby[] module:namejson,ver20800,api1,filters0,usedby[]这就解释了为什么有的人查版本时发现同一套 Redis 命令行工具却多出一堆命令——因为有模块加载进来。这类问题在排查“为什么我的 Redis 支持 JSON 类型同事的不支持”时尤其常见。4.3 版本号直接决定你能用什么功能不同版本的功能差异非常明显选型时要根据项目需求提前确认。这里整理一份常用功能与版本对应关系功能特性最低版本要求使用场景Stream 数据类型5.0消息队列、事件流处理多线程 I/O6.0高并发读写场景性能提升ACL 访问控制6.0多业务共享实例时的权限隔离慢日志新增命令耗时6.0排查性能瓶颈客户端缓存Client Side Caching6.0缓存性能极致优化Redis Functions7.0替代 Lua 脚本的服务器端函数AOF 增量重写7.0热重启场景下缩短恢复时间多级内存淘汰优化7.0大规模缓存场景内存效率提升版本太老时的尴尬很常见项目组要求用 Redis Stream 做消息队列结果线上环境 Redis 还是 4.x最终要么申请升级环境要么改用其它方案白白浪费了排期。所以环境确认的第一步就要界定“最低可用版本”不要想当然。4.4 用 INFO 输出里的版本信息辅助判断性能特征版本号能帮助你判断一个实例的一些隐藏特性。比如在INFO server输出里uptime_in_days超过几百天说明实例长期没重启过process_id很小则说明系统启动后 Redis 启动得很早。结合版本号可以推断它的系统行为受哪个时代的内存管理和多线程策略影响。再比如INFO memory里有个maxmemory_policy字段不同版本内存淘汰策略的表现差异很大。想深入了解这个实例的运行节奏光看版本号不够要把INFO里的memory、stats、replication这几段都展开来看。方便起见可以只提取关键行redis-cli INFO | grep -E redis_version|os|process_id|uptime_in_days|used_memory_human|total_connections_received这一行命令把版本、操作系统、进程 ID、运行天数、内存占用、历史连接总数全部拉出来排查问题时信息量就足够了。5. 常见问题与排查技巧实录5.1 命令找不到command not found怎么办执行redis-server --version提示command not found这是最常见的问法。先别急着重装按顺序排查确定 Redis 被安装到了什么路径。源码编译默认装在/usr/local/binapt 安装装在/usr/bin如果这两个目录都不在 PATH 里就会提示找不到。用whereis redis-server或find / -name redis-server -type f 2/dev/null全局搜索一下。找到后直接带完整路径执行比如/usr/local/bin/redis-server --version。Windows 下同理用where /R C:\ redis-server.exe或者直接用资源管理器搜。找到了再把所在目录加入 PATH 环境变量免得每次敲全路径。5.2 装了多个版本查到的和实际运行的不一致这个坑我在第 3 节提到过这里展开说一下。在 Linux 上通常是这样造成的你通过 apt 安装了一个版本然后又从源码编译装了一个新版到/usr/local/bin。由于 PATH 中/usr/local/bin通常排在/usr/bin前面所以你敲redis-server --version看到的是新版的版本号但系统服务管理中比如 systemd 服务用的还是/usr/bin/redis-server老版本。验证办法是查看正在运行的进程的真实路径# 找到 Redis 进程 ID pgrep redis-server # 查看该进程的可执行文件真实路径 ls -l /proc/$(pgrep redis-server | head -1)/exe # 或者这样 ps -ef | grep redis-server/proc/pid/exe是 Linux 下查看进程真实可执行文件路径的终极手段任何伪装在它面前都白搭。5.3 连接被拒绝怎么判断是版本不兼容还是网络问题执行redis-cli INFO server报Could not connect to Redis at 127.0.0.1:6379: Connection refused不一定和版本查询有关但确实会阻碍你查版本。排查步骤先确认 Redis 进程是否真的在运行ps -ef | grep redis-server或 Windows 下看任务管理器。确认端口是否在监听Linux 用ss -lntp | grep 6379Windows 用netstat -ano | findstr 6379。确认配置文件里是否把bind设置成了127.0.0.1如果你是远程连接就可能被拒。如果配置了protected-mode yes而你是从非本机 IP 连接且没配置密码也会被拒。连接不上的时候你没法通过实例查到运行版本只能用文件版本先顶一下。一定要在文档里记录清楚“文件版本 vs 运行版本”的差异方便后续排查。5.4 Windows 下 Redis 服务启动但不是预期版本Windows 用户最常见的困境是服务里注册的 Redis 路径是 D 盘某个目录而你在 C 盘新下载了一个版本执行redis-server --version显示新版本但服务实际用的还是 D 盘的老版本。对这种“版本混乱”可以先查端口占用情况netstat -ano | findstr 6379拿到进程 PID。在任务管理器里按 PID 找到对应进程右键打开文件位置直接看真实路径。用那个真实路径执行redis-server.exe --version就能拿到服务真实版本。如果你的系统里有多个 Redis 服务实例跑在不同端口也可以借助端口来区分# Linux 下 redis-cli -p 6380 INFO server | grep redis_version # Windows 下 .\redis-cli.exe -p 6380 INFO server5.5 查版本时的小技巧用 --no-raw 让输出更清爽redis-cli默认在终端里输出时会带一些格式化字符。如果想把版本号单独提取出来用在脚本里可以用--no-raw配合 grep 或 awkredis-cli INFO server | grep redis_version | awk -F: {print $2}在 Windows PowerShell 里对应写法是.\redis-cli.exe INFO server | Select-String redis_version还有一种更快的查询方式redis-cli有专门的信息命令redis-cli --version这条命令直接打印客户端版本不需要连接服务器。写监控脚本时想快速判断环境里有没有 Redis 工具链用这个最顺手。5.6 生产环境排查时的建议顺序最后分享一个生产环境的操作习惯。每次接手一个陌生环境我会按这个顺序检查 Redisredis-cli -h 目标主机 -p 端口 INFO server第一优先先确认运行版本。如果连不上再用redis-server --version确认文件版本。同时redis-cli --version确认客户端工具版本避免因为客户端太老导致部分新命令不可用。把版本号、端口、数据目录、日志路径记录到环境信息文档里。版本号这个东西查出来只是第一步。查完还要能看懂它代表什么能力边界这才是合格的后端或运维的基本功。比如你看到 5.0就该知道它没有 ACL 功能看到 6.0就该知道它支持多线程 I/O可以往这个方向调优看到 7.x就该知道 Stream 已经是成熟功能了放心用。我在实际维护中还发现一个规律很多人排查 Redis 问题花几个小时最后发现是版本太老不支持某个指令或者编译时没启用某个特性。如果在第一步就花三秒钟查版本后面能省掉大量无用功。这个习惯养成了慢慢地你也会成为团队里那个“看一眼版本就知道问题出在哪”的人。