1. 为什么选择6.2.6这个版本
1.1 6.2.x系列的技术定位
很多人装Redis第一反应是直接拉最新版，但如果你负责的是生产老项目，或者刚接手一套既有系统，会发现一个很现实的问题：服务端组件真不适合追求“新版新功能”，尤其是Redis这种被业务读写路径高度依赖的中间件。6.2.x是我个人在生产环境里比较推荐的稳定序列，它介于6.0和7.x之间，既保留了对旧客户端和旧部署习惯的兼容，又补足了不少实际有用的能力。
Redis 6.0是官方支持多线程IO的起始版本，ACL权限模型和RESP3协议也都是6.0引入的，但当时这些功能的生态消化还不完全，部分客户端库、可视化工具对RESP3的支持也不够完善。6.2系列把这些能力推得更稳，并补上了如GETEX、GETDEL、BLMOVE等一系列命令细节，同时压缩了过期键清理、主从同步等场景下的异常行为。简单说，6.2.6是这套体系里比较成熟的维护版本，适合把“稳定跑起来”作为第一优先级的人。
1.2 6.2.6相比相邻版本有哪些实用改动
6.2.6属于维护版本，并没引入什么大功能，核心价值在于修复。我翻过它的发布说明，里面包含了若干崩溃点修复，比如XAUTH、客户端缓存失效处理，以及大量和内存碎片清理相关的优化。对于运行中偶尔遇到redis-server莫名掉线的场景，这些修复很实在。
与更早的6.2.1、6.2.2相比，6.2.6在复杂事务、Lua脚本边界场景下的表现更稳定。与7.x相比，6.2.6不需要强制适应AOF文件格式和新的多部分消息协议，部署方式也更贴近大多数老牌运维手册。因此，如果你的项目里已经有成熟的监控脚本、封装好的Redis客户端依赖，选择6.2.6能把升级成本压到最低。
提示：如果项目没有任何历史包袱，直接上7.x也没问题。但如果你希望“下载安装后配置一把梭，接下来两年尽量不折腾”，6.2.6会是一个更保守也更容易排错的选择。
2. 动手前先理清楚的三件事
2.1 环境评估与依赖清单
安装Redis不是只有tar解压后make install这么简单，踩坑往往发生在环境这个层面。我建议动手前先确认四件事：操作系统发行版和版本、是否有编译工具链、是否对tcmalloc或jemalloc有特殊偏好、以及目标端口是否空闲。
最常见的是开发机和生产机的Linux发行版不一致。比如开发环境是Ubuntu，生产环境是CentOS，依赖安装命令完全不同，后面编译时也可能出现gcc版本差异。Ubuntu上我一般装build-essential，CentOS上则用yum install -y gcc gcc-c++ make。另外，Redis默认内存分配器是jemalloc，低版本gcc在编译jemalloc时容易报错，遇到这种情况，可以临时改用make MALLOC=libc，把分配器切到glibc自带的malloc。虽然官方不推荐在生产环境长期用libc，但至少能保证安装流程跑通。
端口检查也要提前做。一个很常见的翻车现场是：Redis明明启动成功，客户端却说连不上，最后发现6379端口被别的进程占用了，或者防火墙策略没放行。可以先执行ss -lntp | grep 6379，确认端口干净再继续。
2.2 下载源选择与安装包校验
下载地址看起来是个小问题，实际上很多人在这栽过跟头。Redis官网redis.io首页会优先推荐最新稳定版，按版本号去下载的历史版本列表藏在下载页面里。如果直接访问官网下载6.2.6，需要找/releases/路径下的归档包。我习惯直接用这个稳定的下载地址模板：
https://download.redis.io/releases/redis-6.2.6.tar.gz这个路径是官方维护的，长期有效，版本号可以替换。如果公司内网有镜像源，优先走内网下载，速度会快很多。下载后不要急着解压，先做一下哈希校验。官方发布包的SHA256值可以在redis-6.2.6.tar.gz.sha256文件里看到，比对着校验能防止源站文件被篡改或者下载不完整。
wget https://download.redis.io/releases/redis-6.2.6.tar.gz wget https://download.redis.io/releases/redis-6.2.6.tar.gz.sha256 sha256sum redis-6.2.6.tar.gz # 对比输出结果是否和sha256文件里的一致3. Linux服务器上编译安装Redis 6.2.6
3.1 解压与编译操作
我把完整步骤写在下面，基于常见的CentOS 7/8和Ubuntu 18.04/20.04，命令基本通用。
# 1. 安装编译依赖 # CentOS/RHEL系 sudo yum install -y gcc gcc-c++ make # Ubuntu/Debian系 sudo apt update sudo apt install -y build-essential # 2. 解压源码 tar xzf redis-6.2.6.tar.gz cd redis-6.2.6 # 3. 编译，直接make即可 makemake这个过程会先编译依赖的jemalloc，再编译Redis本体，耗时取决于机器性能，一般几分钟到十几分钟。编译过程中最常遇到的问题就是gcc版本过老，报error: unknown type name ‘_Atomic’之类的错误。这是编译器不支持C11标准导致的，解决方法要么升级gcc，要么降低Redis版本，要么改用低版本内核方案。如果你确认来源是官方包，不必担心代码有问题，多数是编译环境太旧。
如果make正常结束，接着执行：
# 4. 安装到指定目录，推荐放到/usr/local/redis下 sudo make install PREFIX=/usr/local/redis这条命令会把redis-server、redis-cli、redis-benchmark等可执行文件装到/usr/local/redis/bin目录。如果你不指定PREFIX，默认会装到/usr/local/bin，我建议还是指定一个目录，这样后续升级、删除版本都更干净。
3.2 二进制目录和运行账号怎么安排
安装完成后，即便/usr/local/redis/bin/redis-server已经在系统里，我仍然倾向于构建一个规范化的运行目录，而不是直接裸奔。参考下面这组目录约定，后续维护会省很多事：
/usr/local/redis/bin # 可执行文件 /usr/local/redis/etc # 配置文件 /usr/local/redis/log # 日志文件 /usr/local/redis/data # RDB和AOF文件创建完目录后，把配置文件复制过去：
sudo mkdir -p /usr/local/redis/{etc,log,data} sudo cp redis-6.2.6/redis.conf /usr/local/redis/etc/生产环境不建议用root账号直接跑Redis，最好单独建一个系统用户：
sudo useradd -r -s /sbin/nologin redis sudo chown -R redis:redis /usr/local/redis这样即使服务被攻击，权限也在可控范围内。
3.3 systemd托管与开机自启
直接redis-server /usr/local/redis/etc/redis.conf虽然能启动，但进程退出后不会自动拉起，服务器重启后也不会自动恢复。推荐用systemd管理。新建/etc/systemd/system/redis.service文件，内容可以这样写：
[Unit] Description=Redis Server After=network.target [Service] User=redis Group=redis Type=forking ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf ExecStop=/usr/local/redis/bin/redis-cli shutdown Restart=always RestartSec=5 PIDFile=/var/run/redis.pid [Install] WantedBy=multi-user.target注意这里用了Type=forking，所以配置文件里必须开启daemonize yes，否则systemd会因为前台进程管理方式不匹配而报错。如果你不想开守护进程，也可以把Type改成simple并去掉PIDFile。
保存后执行：
sudo systemctl daemon-reload sudo systemctl enable redis sudo systemctl start redis sudo systemctl status redis看到active (running)就说明服务托管成功了。
4. Windows和Docker环境下的快捷部署
4.1 Windows开发者环境下的安装方案
很多同学是在Windows上做本地联调，想跑一个Redis实例模拟缓存，这种场景就不适合去源码编译了。虽然Redis官方不直接支持Windows，但微软和社区都有维护过Windows移植版本。我用过的方案里，比较省心的是用Windows包管理器直接安装：
wsl --install # 或者使用第三方Windows移植版如果你安装了WSL2，最稳妥的做法是在Linux子系统里按上一节的方式安装，体验和Linux生产环境完全一致。另一个选择是直接用社区维护的Windows可执行包，解压后运行redis-server.exe启动，连接工具用redis-cli.exe即可。这类包适合本地临时联调，不建议用于正式生产。
还有一条路子就是Docker Desktop，Windows上装好Docker后，拉镜像跑容器，具体命令见下一节。这个方案的好处是环境干净，不污染宿主机，删除也方便。
4.2 Docker容器方式部署Redis 6.2.6
Docker部署Redis最大的好处是免去了编译和依赖的麻烦，一条命令就能拉起。官方镜像的版本tag非常规范，直接用版本号即可。
docker pull redis:6.2.6 docker run -d --name redis626 \ -p 6379:6379 \ -v /opt/redis/data:/data \ -v /opt/redis/redis.conf:/etc/redis/redis.conf \ redis:6.2.6 \ redis-server /etc/redis/redis.conf这里我把/opt/redis/redis.conf挂载进容器，并用挂载的配置启动，这是很重要的一步。很多新手直接跑docker run redis:6.2.6，Redis会在默认配置下使用容器内默认入口启动，没有设置密码、没有持久化配置，容器一删数据就没了。
如果只是临时测试，也可以简化成一句：
docker run -d --name redis626 -p 6379:6379 redis:6.2.6但生产环境务必使用自定义配置挂载。进入容器的命令也不难记：
docker exec -it redis626 redis-cli -a yourpassword ping4.3 三种安装方式如何选
我觉得可以按场景直接对号入座：生产环境Linux裸机或虚拟机，优先编译安装或RPM/DEB包安装，便于和现有监控、systemd体系集成；本地开发机，优先Docker，干净且不影响宿主环境；纯Windows临时演示，用社区移植版或WSL即可。
这里多说一句：有人会在生产环境里图省事直接用Docker跑Redis，如果你的运维体系支持得比较好，容器的持久化和网络管理都成熟，完全可行。但如果容器平台本身还不稳定，我认为裸机安装更可靠，因为Redis本身定位就是轻量级，运维复杂度低，没必要为了容器化而容器化。
5. 安装后的基础配置与可用性验证
5.1 Redis配置文件的核心改动点
安装完成不等于配置完成。默认的redis.conf虽然能直接启动，但有几个地方不建议裸奔：端口、绑定地址、密码、持久化策略、日志位置。我通常按最小必要原则修改，不把配置改得面目全非，后续排查问题会更容易。
下面是一份常用的最小改动清单：
bind 127.0.0.1 protected-mode yes port 6379 daemonize yes pidfile /var/run/redis.pid logfile "/usr/local/redis/log/redis.log" dir /usr/local/redis/data requirepass yourpassword appendonly yes appendfilename "appendonly.aof"bind一定要按实际需求写。如果不修改网络配置，只允许本机连接，bind 127.0.0.1就足够了；如果同一内网的其他机器要访问，就写上具体的内网IP，例如bind 127.0.0.1 192.168.1.100。protected-mode yes配合bind，能防止Redis暴露到公网被恶意利用。真实生产里经常有人忘了改这两项，结果被蠕虫扫到，直接变成挖矿肉鸡，这种事情在运维圈并不少见。
requirepass是否设置取决于业务场景。如果Redis只在内网且网络隔离做得好，可能不需要密码；但只要涉及到跨网段访问或公网环境，密码是底线。设置密码后，客户端连接和redis-cli都要用-a参数或AUTH命令。
持久化这块，默认的RDB快照配置适合大部分场景，但如果有较高的数据可靠性要求，建议同时开启AOF。开启后，每次写操作都会记录到appendonly.aof，实例重启后通过重放AOF恢复数据。当然，AOF文件会持续增长，需要在配置里设置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，让Redis在AOF膨胀到一定程度时自动重写。
5.2 启动实例并用redis-cli验证
配置改完后，先做一次前台启动，确认没有配置错误：
sudo -u redis /usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf如果没有报错，再用redis-cli验证：
/usr/local/redis/bin/redis-cli -a yourpassword ping返回PONG就说明服务正常。接下来可以看一些基本状态，确认当前版本和运行情况：
/usr/local/redis/bin/redis-cli -a yourpassword info server | grep redis_version如果要检查持久化配置是否生效，可以执行：
/usr/local/redis/bin/redis-cli -a yourpassword config get appendonly看到输出为appendonly和yes，说明修改已生效。
注意：
redis-cli -a明文传密码会在历史记录里留下记录，本地测试没问题，但生产环境慎用。可以设置环境变量REDISCLI_AUTH，或使用交互式AUTH命令。
6. 我踩过的坑和排查记录
6.1 编译阶段的经典报错
源码编译那一步问题最集中，尤其集中在老系统上。第一个高频报错是cc: command not found，说明没装gcc；第二个是jemalloc编译失败，报zmalloc.h:50:31: fatal error: jemalloc/jemalloc.h: No such file or directory，这种情况在CentOS 7配合旧版本gcc时很常见。我的解决办法是先升级系统工具链，再重新执行make distclean && make。如果环境实在无法升级，再考虑make MALLOC=libc。
还有一种情况是磁盘空间不足，源码目录比较大，make过程会产生大量中间文件，建议先df -h检查/tmp和当前目录所在磁盘的剩余空间。
编译通过之后也别太高兴，启动时可能遇到WARNING overcommit_memory is set to 0!，这不是致命错误，只是Redis提示内存分配策略可能造成后台保存失败。生产环境我会建议调整内核参数：
sudo sysctl -w vm.overcommit_memory=1同时把THP（透明大页）关掉，Redis官方文档明确建议关闭系统中透明大页的支持，因为它会降低Redis的内存性能并增加延迟：
echo never > /sys/kernel/mm/transparent_hugepage/enabled6.2 启动和连接阶段的坑
启动后最常见的问题就是连不上。很多人第一反应是防火墙，于是去关防火墙，但真正的元凶往往是bind配置限制。如果bind 127.0.0.1而客户端从别的机器连，肯定连不上。解决方法是把本机内网IP追加到bind后面，或者让Redis监听所有网卡，但后者仅限内网隔离可靠的环境，我真的不推荐。
另一种连接问题是被密码挡住的：客户端报NOAUTH Authentication required。这时候只要确认配置文件里的requirepass和客户端传的密码是否一致即可。注意，如果用了redis-cli并开启了protected-mode yes，还要注意在交互时先用AUTH认证。
数据目录权限问题也值得留意。如果Redis以redis用户运行，但dir指向的目录是root创建的，可能出现Can't open the append-only file: Permission denied，导致启动失败。解决办法是chown redis:redis /usr/local/redis/data，确保运行用户对数据目录有写权限。
6.3 常见问题速查表
| 现象 | 常见原因 | 快速处理 |
|---|---|---|
cc: command not found | 未安装gcc | 安装build-essential或gcc |
| jemalloc编译失败 | gcc版本过老 | 升级gcc或make MALLOC=libc |
Could not connect to Redis at 127.0.0.1:6379 | 服务未启动、bind限制或防火墙拦截 | 检查进程状态、bind配置和防火墙规则 |
NOAUTH Authentication required | 未发送密码或密码错误 | 执行AUTH <password> |
MISCONF Redis is configured to save RDB snapshots... | 磁盘不足或权限问题 | 修复数据目录权限，检查磁盘空间 |
WARNING overcommit_memory is set to 0! | 内核参数未调优 | sysctl -w vm.overcommit_memory=1 |
Can't open the append-only file | AOF目录无写权限 | 查看日志中提示的路径，修正属主 |
最后再说一个我自己维护环境时的习惯：装完Redis后，我会把安装版本、配置文件路径、数据目录、启动方式和密码策略都记录在项目的部署文档里，而不是只依赖记忆。这个习惯帮了很多次忙。比如半年后需要升级版本或排查内存溢出时，直接看文档就能回忆起来当时做了哪些处理，不用重新翻配置、猜目录。你可能觉得这是小事，但真正出问题时，薄薄一张纸的记录就是最可靠的排查依据。
Redis 6.2.6的下载和安装本身不算复杂，但每一步选择都会影响后续的维护体验。希望这份记录能帮你少走几趟弯路，把一个稳定可用的Redis服务真正落地。
