企业官网建设流程全解析

1. 为什么先查版本号再动手

先讲个真实场景。组里新来一个同事，环境里 Redis 报错了，一上来就翻文档查配置，折腾半天没头绪。我过去看了一眼，先问了一句：你这里的 Redis 是什么版本？他愣了一下，说没看过。其实这个习惯很要命——Redis 的版本差异比大多数人想象中要大得多，5.0 之前没有 Stream 数据类型，6.0 才引入多线程 I/O，7.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 v=7.2.4 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=7f8b7c05d0a0e290

redis-cli --version的输出更简洁一些，通常直接告诉你redis-cli 7.2.4。

这里有个细节值得注意：redis-server --version输出的信息量更大，包含了内存分配器的类型（比如 jemalloc）、系统位数（64 位）、编译构建哈希等。这些信息在你排查性能问题或者编译问题时特别有用。比如你看到malloc=jemalloc-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 实例真实运行时的版本号，也是最权威的判定依据。相比命令行直接--version，INFO 模式还有额外收获：你能看到redis_mode（是 standalone 单机模式还是 sentinel 哨兵模式或者 cluster 集群模式）、multiplexing_api（Linux 下是 epoll，macOS 下是 kqueue，Windows 下是 win32 线程模型），以及进程 ID、运行时长等状态信息。

判断运行态版本还有一个办法，就是看启动日志。Redis 每次启动时都会在日志头部打印版本信息：

12345:M 15 Oct 2024 10:23:45.678 * Redis version=7.2.4, bits=64, commit=00000000, modified=0, pid=12345, 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 2>&1; then rpm -qa | grep redis 2>/dev/null || echo "未通过 rpm 安装" elif command -v dpkg >/dev/null 2>&1; 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 都是社区移植的产物。目前常见的几种来源是：

1. 微软维护的移植版：微软曾长期维护一个 Windows 移植分支，基于 Redis 3.x / 5.x / 6.x 的版本改造，下载包里直接是redis-server.exe和redis-cli.exe。
2. tporadowski / memurai 等第三方移植版：这是目前 Windows 下使用较广的 Redis 发行版，tporadowski 维护的版本更新到 5.0.14，Memurai 则是商业级的 Windows 原生 Redis 兼容实现。
3. WSL / Docker 里跑的 Linux 版 Redis：这是目前比较推荐的方式，相当于在 Windows 上跑一个 Linux 环境，里面运行的实际上是 Linux 版本。
4. 绿色免安装版：解压即用，一个文件夹涵盖所有 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 v=5.0.14 sha=00000000:0 malloc=jemalloc-4.0.0 bits=64 build=5c8b3a2f9a9f5a77

这里有个 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 server

3.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 环境下的查询方式

越来越多的人开始用 WSL（Windows Subsystem for Linux）或者 Docker Desktop 在 Windows 上跑 Redis，这种情况下查询版本走的是 Linux 那套逻辑。

WSL 里安装的 Redis，直接在子系统终端里执行：

wsl redis-server --version

Docker 里的 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.4

4. 版本号信息解读与版本选型的门道

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:name=search,ver=20810,api=1,filters=0,usedby=[] module:name=json,ver=20800,api=1,filters=0,usedby=[]

这就解释了为什么有的人查版本时发现同一套 Redis 命令行工具却多出一堆命令——因为有模块加载进来。这类问题在排查“为什么我的 Redis 支持 JSON 类型，同事的不支持”时尤其常见。

4.3 版本号直接决定你能用什么功能

不同版本的功能差异非常明显，选型时要根据项目需求提前确认。这里整理一份常用功能与版本对应关系：

版本太老时的尴尬很常见：项目组要求用 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/bin，apt 安装装在/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，不一定和版本查询有关，但确实会阻碍你查版本。排查步骤：

1. 先确认 Redis 进程是否真的在运行：ps -ef | grep redis-server或 Windows 下看任务管理器。
2. 确认端口是否在监听：Linux 用ss -lntp | grep 6379，Windows 用netstat -ano | findstr 6379。
3. 确认配置文件里是否把bind设置成了127.0.0.1，如果你是远程连接，就可能被拒。
4. 如果配置了protected-mode yes，而你是从非本机 IP 连接且没配置密码，也会被拒。

连接不上的时候，你没法通过实例查到运行版本，只能用文件版本先顶一下。一定要在文档里记录清楚“文件版本 vs 运行版本”的差异，方便后续排查。

5.4 Windows 下 Redis 服务启动但不是预期版本

Windows 用户最常见的困境是：服务里注册的 Redis 路径是 D 盘某个目录，而你在 C 盘新下载了一个版本，执行redis-server --version显示新版本，但服务实际用的还是 D 盘的老版本。对这种“版本混乱”，可以：

1. 先查端口占用情况：netstat -ano | findstr 6379，拿到进程 PID。
2. 在任务管理器里按 PID 找到对应进程，右键打开文件位置，直接看真实路径。
3. 用那个真实路径执行redis-server.exe --version，就能拿到服务真实版本。

如果你的系统里有多个 Redis 服务实例跑在不同端口，也可以借助端口来区分：

# Linux 下 redis-cli -p 6380 INFO server | grep redis_version # Windows 下 .\redis-cli.exe -p 6380 INFO server

5.5 查版本时的小技巧：用 --no-raw 让输出更清爽

redis-cli默认在终端里输出时会带一些格式化字符。如果想把版本号单独提取出来用在脚本里，可以用--no-raw配合 grep 或 awk：

redis-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 生产环境排查时的建议顺序

最后分享一个生产环境的操作习惯。每次接手一个陌生环境，我会按这个顺序检查 Redis：

1. redis-cli -h 目标主机 -p 端口 INFO server第一优先，先确认运行版本。
2. 如果连不上，再用redis-server --version确认文件版本。
3. 同时redis-cli --version确认客户端工具版本，避免因为客户端太老导致部分新命令不可用。
4. 把版本号、端口、数据目录、日志路径记录到环境信息文档里。

版本号这个东西，查出来只是第一步。查完还要能看懂它代表什么能力边界，这才是合格的后端或运维的基本功。比如你看到 5.0，就该知道它没有 ACL 功能；看到 6.0，就该知道它支持多线程 I/O，可以往这个方向调优；看到 7.x，就该知道 Stream 已经是成熟功能了，放心用。

我在实际维护中还发现一个规律：很多人排查 Redis 问题花几个小时，最后发现是版本太老不支持某个指令，或者编译时没启用某个特性。如果在第一步就花三秒钟查版本，后面能省掉大量无用功。这个习惯养成了，慢慢地你也会成为团队里那个“看一眼版本就知道问题出在哪”的人。