企业官网建设流程全解析

经常有朋友问我：在Windows上装了个Redis，怎么查版本号？到了Linux上，命令好像又不一样。其实查看Redis版本号这件事本身不复杂，但Windows和Linux的环境差异、安装方式差异，会让一个本来三秒钟能解决的问题变得像踩迷宫。这篇文章就把我在Windows和Linux两种系统下查看Redis版本号的完整思路和实操命令都摊开讲，包括为什么有时候命令一样，有时候又不一样，以及查版本号时容易踩的坑该怎么避开。不管你是刚接触Redis的开发新手，还是需要维护服务器的运维同学，都可以照着操作。

1. 为什么需要关心 Redis 版本号

1.1 版本号就是一张“能力清单”

Redis的版本号通常由主版本号、次版本号、补丁版本号三段组成，例如7.2.4。主版本号决定大的功能迭代，次版本号带来新的命令和特性，补丁版本号则主要修复已知问题。这一点看起来像是常识，但实际工作中，很多人把某个命令在网上搜到后就往生产环境里敲，结果发现当前版本不支持，就会收到ERR unknown command的错误。所以先查看版本号，不动手就知道当前Redis支持哪些功能。

比如Redis 6.0开始支持ACL（访问控制列表）和RESP3协议，Redis 7.0引入了自动AOF重写等功能。如果公司还在用5.x版本，那么这些新特性一概没有。反过来说，有些旧版本的配置项在新版本中可能被移除或改名，升级前确认版本也同样重要。我见过因为Redis版本不一致导致主从复制无法同步的案例，最后排查下来是主库和从库的版本差别太大，某些RDB文件结构不兼容。先确认版本号，能在排查时省下几个小时。

1.2 运维和开发都要先看版本

对开发同学来说，版本号决定了你写的代码里能不能放心使用某个命令和客户端库配置。比如Redis 7.0里部分命令的行为有变化，处理超时或键空间通知时，不同版本的表现可能不同。对运维同学来说，版本号是判断是否需要紧急升级的关键依据，Redis官方安全公告会明确影响版本范围，你手上实例的版本是否在受影响区间，只有实际查过才算数。

我还遇到过这样的场景：服务器上有两个Redis实例，一个是6.2，一个是7.0，早期排查时只看了本机默认的redis-server -v，确认是7.0后就以为所有实例都安全。后来连接业务实际使用的端口才发现，另一个实例还在6.2，并且命中了已知的严重问题。这就是只依赖一种查看方式、没有去确认运行实例版本带来的教训。所以下面我不会只给你一条命令，而是结合环境把不同场景下的查看方式都整理出来。像这种“多个实例版本不一致”的问题，我在日常运维里碰到过好几次，每次都靠重新确认端口和版本这个动作避免更大的事故。

2. Windows 系统下查看 Redis 版本号的几种方法

2.1 最简单直接：redis-server --version

Windows下Redis的安装方式和Linux不太一样。通常你会下载一个zip压缩包，解压后得到redis-server.exe、redis-cli.exe等文件，一般不提供系统服务安装向导。在这个常见情况下，查看版本号最直接的方法是打开cmd或PowerShell，进入解压目录，然后执行：

redis-server.exe --version

或者使用短参数：

redis-server.exe -v

实际输出类似：

Redis server v=6.2.7 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=9a4d5e4b

注意我这里用的是redis-server.exe，不是redis-server。Windows下的可执行文件如果没加.exe前缀，在PATH环境变量未配置时可能会提示找不到命令。如果你已经把解压目录加入系统PATH，那么命令可以去掉.exe后缀。但为了稳妥，我建议还是把后缀带上，这样别人看到你执行的内容，也能知道你用的是Windows原生的Redis版本。

还有一个很常见的问题：很多人拿到zip后直接双击redis-server.exe，结果弹出一个黑色窗口然后一闪而过，或者窗口一直停在那里，以为是卡住了。其实那是因为Redis默认在前台运行，意味着这个窗口就是服务进程，不能随便关，关掉服务就停了。你如果要查看版本号，不应该靠双击后的界面，应该在命令行里执行上面的命令。等命令输出完，进程会直接退出，不会占用终端。

2.2 实例运行中：用 redis-cli 查看 INFO server

如果Redis已经启动，并且你需要确认的是正在运行中的实例版本，上面redis-server --version 的方式虽然能看出二进制文件的版本，但如果你启动了多个实例，或者你拿到的exe版本和实际运行中的版本不一致，它就不够准确。这时候更靠谱的方式是用客户端连接进去，查看服务端上报的版本信息。

在Windows命令行下，执行：

redis-cli.exe -h 127.0.0.1 -p 6379 info server

返回信息里面有一行：

redis_version:6.2.7

如果你只想快速看到版本行，可以在cmd里用：

redis-cli.exe -h 127.0.0.1 -p 6379 info server | findstr "redis_version"

PowerShell用户则需要用Select-String：

redis-cli.exe -h 127.0.0.1 -p 6379 info server | Select-String "redis_version"

区别只在于管道命令不同。我平时更推荐直接执行完整info server，因为除了redis_version，还能看到redis_mode、os、uptime_in_days等字段，对判断实例状态也有帮助。多看一行信息，不亏。

2.3 服务化安装后的版本定位

部分团队在Windows服务器上会把Redis注册成Windows服务，让它在后台自动启动。这时你想查版本，可以先看服务的属性。在管理员权限的cmd里执行：

sc qc redis

或者打开服务管理器，找到Redis服务，查看其“可执行文件的路径”。拿到路径后，在命令行对那个具体的exe执行--version即可。比如路径是C:\tools\redis\redis-server.exe，就执行：

C:\tools\redis\redis-server.exe --version

这里有个细节：注册服务时，有些工具会把redis-server.exe复制到另一个目录，或者使用一个包装程序来启动，比如WinSW或NSSM。这时候查看服务路径比搜索整个C盘更快。不要凭记忆觉得“我装在D盘就一定是那个目录”，服务实际调用的可执行文件必须从服务配置里确认。这也是我在帮别人排查问题时遇到过的情况：明明环境变量指向A目录，服务却用的是B目录里的老版本，这会导致你看到的版本号和实际服务运行的版本号完全对不上。

2.4 WSL 和 Docker Desktop 的版本查看

现在很多Windows开发者已经不用原生Redis了，而是用WSL（Windows Subsystem for Linux）或Docker Desktop。如果你在Windows 10/11上装了WSL，并在WSL里通过apt安装了redis-server，那么查看方式就和Linux基本一致。启动WSL终端后执行：

redis-server --version

如果通过Docker来跑Redis镜像，假设容器名称是redis，那么执行：

docker exec redis redis-server --version

或者进入容器后用redis-cli查询：

docker exec -it redis redis-cli info server

这里需要提醒的是，在Windows上用原生Redis和用WSL/Docker里Redis，版本可能完全不同。你甚至可能同时装了三种Redis，如果不能确定业务使用的是哪一个，最后查出来的版本号就不能代表业务模块的实际Redis版本。动手之前先想清楚Redis跑在哪里，这个优先级比命令本身更高。

3. Linux 系统下查看 Redis 版本号的常见姿势

3.1 命令带路径时直接查

Linux下Redis的安装来源很多，最常见的三种：通过系统包管理器安装（比如apt install redis-server）、通过官方源码编译安装、直接使用发行版仓库里的redis包。第一种安装完成后，redis-server和redis-cli一般会被放进/usr/bin或/usr/local/bin，所以直接在终端执行：

redis-server --version

就能看到类似下面的输出：

Redis server v=7.0.12 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=4c9a3a2d

如果你只想快速拿到版本号，也可以配合grep或awk，但实际没必要，因为--version输出很短，一眼就能看清。相比之下，redis-cli的版本输出可能略有不同，比如：

redis-cli --version

输出可能是：

redis-cli 6.2.7

注意，redis-server --version显示的是服务端程序的版本，redis-cli --version显示的是客户端工具的版本。两者可能不一样，尤其在只用包管理器单独安装过redis-tools的情况下。这个坑值得记住，因为很多人会下意识认为两个输出应该完全一致。

3.2 命令不在 PATH 时怎么定位

源码编译安装的Redis，默认会被安装到/usr/local/redis，bin目录下的可执行文件未必被加入PATH。你执行redis-server -v时可能得到bash: redis-server: command not found。这时候有两种定位方式：通过进程找路径和通过文件系统搜索。

找到正在运行的进程路径最直接：

ps -ef | grep redis-server

输出中往往能看到类似 /usr/local/redis/bin/redis-server 0.0.0.0:6379 这样的信息，然后你直接用这个绝对路径执行--version：

/usr/local/redis/bin/redis-server --version

如果进程没在运行，再用find搜索：

find / -name redis-server -type f 2>/dev/null

Linux系统里find全盘搜索可能会提示权限不足，不过2>/dev/null把错误消息丢弃掉，依然能找出大多数情况。搜索到的路径可能不止一个，比如系统里同时存在/usr/bin/redis-server和/usr/local/redis/bin/redis-server。这时要看哪个才是你业务里用到的那个，不要随便挑一个就认为所有实例都是这个版本。

3.3 远程实例没有 redis-cli 也能查

需要查看的Redis如果不在本机，可能是局域网内另一台服务器，而你的机器上又没有redis-cli，怎么办？有两个思路：一是用nc或telnet直接和Redis端口通信，二是用任何一门语言的Redis客户端执行info server。我个人更倾向于用nc，因为不需要装额外工具。

Redis协议是文本协议，在命令行下可以这样模拟：

printf 'INFO server\r\n' | nc 192.168.1.10 6379

返回的头几行就是Redis响应，里面有redis_version字段。如果系统里没有nc，可以试试telnet：

telnet 192.168.1.10 6379

连接上之后输入INFO server回车，同样能看到版本信息。这种方式不依赖redis-cli，在排查问题时特别好用，前提是Redis没有开启保护模式，或者你发送的请求来源IP在白名单内。远程连接时建议用带认证的实例，输入AUTH认证后再执行INFO，避免被拒绝访问。其实这就是最原始的“协议级探测”，理解了这个原理，后面你再去看各种可视化客户端工具时，就会发现它们底层做的事一模一样。

3.4 Docker 容器里的 Redis 版本

现在生产环境用容器部署Redis越来越普遍。如果你只知道宿主机上有Redis，但不确定容器名称，可以先用：

docker ps | grep redis

找到容器名或容器ID，然后执行：

docker exec <container_name> redis-server --version

也可以进入容器后执行：

docker exec -it <container_name> sh

进入后运行：

redis-cli info server | grep redis_version

如果你是使用docker-compose启动的，容器名通常在docker-compose.yml里定义，用docker ps确认后执行即可。还有一点很多人忽略：宿主机上安装的redis和容器里的redis是完全不同的两套程序，如果搞混了，版本信息自然也不对。所以我强烈建议，凡是容器化部署的实例，一律用docker exec进入容器查询，不要用宿主机上的redis-server -v结果冒充。

3.5 源码安装包的版本信息

如果你是从Redis官网或GitHub下载的源码包，在编译安装前，其实也可以不用等到编译完再查看版本。解压tar.gz后，进入源码目录，就能从多个文件里看到版本号。比如执行：

cd redis-7.2.4

更准确的方法是看源码目录名称，一般就是redis-7.2.4这种格式。另外，Redis源码根目录下的README.md开头通常会注明当前版本，src/redis-server.c中也写有版本常量。如果你已经把源码编译到一半，可以直接运行编译好的二进制：

src/redis-server --version

这个输出最准确，也最不容易出偏差。源码包方式适合那些“我只是从网上抄了一段安装命令，但不确定能不能用”的场景。先看版本，再决定要不要直接搭主从或做高可用配置，能少走很多弯路。

4. 版本输出里那些字段到底是什么意思

4.1 典型输出逐段拆解

不少同学第一次看到redis-server --version的输出会觉得每个字母都很眼熟，但拼在一起就不知道什么意思了。我们拿一个典型的输出：

Redis server v=7.0.12 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=4c9a3a2d

逐段看：

• v=7.0.12：Redis实际版本号。
• sha=00000000:0：构建时对应的Git提交哈希。从官方发布包编译时，如果没保留Git元信息，通常会显示全零。如果是自己用Git clone的源码编译，这里会有具体提交ID，方便你追溯到某次代码变更。
• malloc=jemalloc-5.1.0：Redis使用的内存分配器，生产环境大部分是jemalloc，也有libc或tcmalloc。这个字段在你分析内存碎片率时有点参考价值。
• bits=64：编译架构，64位版本。32位版本对内存上限有天然限制，所以看到这个字段可以顺手确认一下跑的是不是64位程序。
• build=...：构建ID，每次源码的编译唯一生成，可以用来精确指认一个二进制文件。

理解这些字段以后，你就不只是看到一串数字，而是能通过输出判断这个Redis是不是官方发布、是不是64位、用什么分配器，这些信息在做故障排查时都有用。

4.2 客户端的版本和服务端的版本要分清

redis-cli --version和redis-server --version返回的内容并不总是完全对应。如果你是在一台机器上单独安装了redis-tools这种客户端工具，而服务端是从别的机器拉起来，那么这两个版本很可能是脱节的。我遇到过最夸张的情况是客户端是6.x，服务端是7.x，大部分常用命令正常工作，但当我用客户端发送某些新命令时，Redis会报ERR unknown command，因此我花了不少时间才定位到是客户端和服务端版本差异。

其实大部分人日常不会直接用redis-cli去发命令，更多是程序里的客户端库和服务端Redis交互。如果底层库的版本太老、不认识服务端新引入的协议特性，也可能握手失败或出现奇怪行为。查看服务端版本时，我建议统一以INFO server里的redis_version为准，因为那是运行实例真正报告出来的版本，比启动文件的版本号更可靠。只有在启动文件本身可疑，比如有人替换了二进制但没有重启服务时，才需要额外用redis-server --version做对比。

5. 常见问题与排查技巧实录

5.1 输入 redis-server -v 提示 command not found

这是最普遍的问题。Linux下很可能是因为安装源码后没有把bin目录加入PATH，Windows下则可能是解压目录没有被放进系统环境变量。解决思路不是马上去改全局PATH，而是先用绝对路径定位能运行的程序。比如Linux下先跑一下：

find / -name redis-server -type f 2>/dev/null

找到路径后，把它加到当前用户的.bashrc或.zshrc中，或者创建软链接：

ln -s /usr/local/redis/bin/redis-server /usr/local/bin/redis-server ln -s /usr/local/redis/bin/redis-cli /usr/local/bin/redis-cli

Windows下则把解压目录加入系统Path环境变量后，重开命令行窗口即可。这里要注意，改完环境变量后，当前已经打开的终端不会立刻生效，必须新开一个窗口。

5.2 版本号拿到了，但连接业务端口发现不一样

一台机器上可能通过系统包安装了一个Redis，又手工解压了一个Redis，或者一个在6379端口，一个在6380端口。你查看本机二进制版本只代表默认那个可执行文件，不等于所有实例都是这个版本。正确做法是先用ss -lntp或netstat查看当前监听的Redis端口，再逐个连接端口执行info server：

for port in 6379 6380; do redis-cli -p $port info server | grep redis_version done

这个循环在排查多实例时非常高效。我在生产环境里用过很多次，几乎每次都能发现有一两个实例的版本和其他实例不一致。版本不一致本身不算致命，但主从架构中如果主库版本太新而从库版本太旧，可能会出现RDB格式不兼容或复制命令参数不匹配的情况，所以多实例环境下确认“每个端口对应什么版本”比只查一次更有价值。

5.3 Windows 下双击 redis-server.exe 窗口一闪而过

这个问题虽然不是“查看版本号”的直接动作，但很多人在查版本时都会遇到。双击exe后窗口消失，并不代表Redis没有启动，而是因为Redis默认在前台运行，如果它启动后正常监听端口，窗口就会一直开着；如果启动失败，比如端口被占用或配置文件错误，窗口会一闪而过并退出。

因此，在Windows上查看版本号或做调试，应该养成用命令行的习惯。先cd到解压目录，执行redis-server.exe --version确认版本，再决定是否用redis-server.exe redis.windows.conf指定配置文件启动。尽量避免用双击的方式管理服务，否则既看不到日志也容易产生端口冲突的错觉。

5.4 需要跨机器批量确认版本时的小经验

如果你管理的Redis实例比较多，一台台登录查看比较费劲，可以在能访问所有机器的跳板机上用ssh批量执行。比如把机器IP列表写进ips.txt，然后循环执行：

for ip in $(cat ips.txt); do echo "==== $ip ====" ssh -o ConnectTimeout=5 $ip "redis-cli -p 6379 info server | grep redis_version" done

这个脚本依赖每台机器都能用redis-cli，如果没有，也可以用redis-server --version替代。需要注意的是，这样批量执行只能拿到“默认命令”对应的版本，如果有些实例用容器跑，就必须在ssh命令里嵌套docker exec。我加超时参数，就是为了防止某台机器SSH卡死导致循环挂起，这个细节在批量操作时非常重要。

5.5 场景速查表

下面把常用场景和命令整理成一个表格，方便以后直接翻。

这张表覆盖了绝大多数场景。实际上你只要记住一句话：看版本号最终要落到“运行的实例”上，二进制文件和运行实例不一定是一回事。这条原则在很多Redis问题排查里都适用。

最后说一个我自己的习惯。接手一台新的Redis服务器时，我会先执行redis-server -v确认二进制版本，再马上连接实际业务端口执行info server确认运行版本，两者一致才放心。如果遇到容器部署，就改成docker exec和redis-cli的组合。这个习惯帮我避免过好几次“以为升级成功，实际业务还在用旧实例”的尴尬。你先用这些方法把自己的环境查清楚，再去看命令兼容性、主从同步这些更深的主题，会顺手很多。