说实话如果目标只是“让 Redis 跑起来”绝大多数 Linux 发行版上一条命令就够了Ubuntu 上sudo apt install redis-serverCentOS 上sudo yum install redis。但我见过太多人这样装完直接改两行配置就丢进生产环境结果半夜被监控报警叫醒——要么是 Redis 连不上要么内存直接打满要么服务器重启后服务根本没起来。问题不在 Redis 本身而在安装过程中绕过了太多本该确认的细节。所以这篇文章不是教你怎么敲那一条命令而是把“在 Linux 上安装 Redis”这条路的完整链路走一遍动手前的环境确认、源码编译的完整过程、包管理器安装的取舍、redis.conf 里必须改的参数、用 systemd 做服务托管以及装完之后的验证和排错。适合刚接触 Linux 服务器的新手也适合已经能装、但没认真想过“为什么这么装”的人。1. 动手前先摸清底细你手头的 Linux 决定了安装方式1.1 发行版与包管理器的第一道分水岭Linux 不是铁板一块。同样是“装 Redis”Debian/Ubuntu 系列用 aptCentOS/RHEL/Rocky Linux 系列用 dnf 或 yumAlpine 用 apkopenSUSE 用 zypper。包管理器不同软件包名称、配置文件路径、systemd 服务文件的位置都可能不一样。最典型的一个坑是 CentOS 默认源里没有redis-server这个包名只有redis而且通常要先启用 EPEL 源才有。Ubuntu 则正好相反包名就是redis-server。如果你照着 CentOS 的教程在 Ubuntu 上搬运命令第一步就会卡住。千万别小看这一步我见过不止一个人在这上面浪费一整个下午。所以动手之前先花三十秒确认系统cat /etc/os-release uname -r getconf LONG_BIT第一行告诉你发行版名称和版本号第二行看内核版本第三行确认系统是 64 位还是 32 位。Redis 官方对老旧 32 位系统的支持已经很弱这种环境下与其折腾源码编译不如直接换台 64 位机器更省时间。1.2 编译工具链版本源码安装前的隐性门槛如果打算选择源码编译gcc 和 make 的版本就是第一道坎。Redis 7.x 源码对编译器版本有隐性要求拿一个 GCC 4.8 的老环境去编大概率会在某个不显眼的地方报错。检查方式很简单gcc --version make --version正常来说 GCC 8 以上编译 Redis 7 系列没有压力。如果你手头是 CentOS 7 这种老发行版默认 GCC 是 4.8编译 Redis 6.x 都可能遇到 C 标准相关的报错。碰到这种情况别急着硬怼编译器要么换系统要么用发行版自带的低版本 Redis这是性价比更高的选择。1.3 版本选择不要闭眼装最新也不要闭眼装仓库版版本选择有几个务实原则。发行版仓库里的 Redis 通常比官方最新版落后一到两个大版本比如某系统自带 6.0.x而官方已经稳定在 7.x。仓库版的优势是“有人替你踩过兼容性的坑”适合不想折腾的环境官方最新版的优势是包含新特性和性能优化比如 Redis 7 在内存碎片处理上的改进对大规模缓存场景很有价值。我个人的选择逻辑是开发测试环境随便装生产环境优先用官方 stable 版本源码编译固定到一个具体的次版本号而不是跟着最新小版本跑。这样方便复现问题也方便团队统一维护。2. 源码编译安装为什么有人绕开包管理器也要自己编2.1 编译安装的真实价值有人会问包管理器一把梭不香吗为什么还要源码编译答案是三点。第一版本可控。仓库里是什么版本不由你决定官方发布新稳定版你也只能等发行版维护者打包。源码编译则可以把版本精确锁定今天装的版本和昨天装的一样线上出问题能稳定复现。第二目录可控。用 PREFIX 参数可以把二进制装到指定位置多实例部署时各放各的目录互不污染。第三学习价值。编译一次 Redis 成本不高却能逼你把整个工具链跑通。之后编译 Nginx、编译其他 C 项目都是同一套思路一次学会终身受用。2.2 编译环境的准备在 Debian/Ubuntu 系列上最小依赖是sudo apt update sudo apt install -y build-essential pkg-config tclbuild-essential包含 gcc、g、makepkg-config用于检测依赖库tcl是运行make test用的。注意tcl 不装也能编译通过但跑不了测试。编译完不跑测试的风险后面会专门讲。在 CentOS/RHEL 系列上对应命令是sudo yum groupinstall Development Tools sudo yum install -y tcl如果不想用 root 编译可以自建一个编译用户这不是必需但环境更干净。2.3 下载、校验、编译、安装从 Redis 官网下载页找稳定版 tarball比如 redis-7.0.15.tar.gz然后执行wget https://download.redis.io/releases/redis-7.0.15.tar.gz sha256sum redis-7.0.15.tar.gz tar xzf redis-7.0.15.tar.gz cd redis-7.0.15 make -j$(nproc)这里有几个细节需要说明。wget之后一定要先比对sha256sum与官网给出的校验值防止文件在传输过程中损坏或被替换。这个习惯非常重要尤其是你经手服务器时一步校验能省掉后面一堆莫名其妙的编译错误。-j$(nproc)让 make 用上机器全部核心编译速度快很多。编译完先确认src/redis-server存在再执行安装sudo make install PREFIX/usr/local/redisPREFIX是可选项。不指定时make install默认装到/usr/local/bin指定后会装到/usr/local/redis/bin。很多公司的一键部署脚本都会指定 PREFIX主要是为了方便统一管理路径和后续版本回滚。装完之后redis-server、redis-cli、redis-benchmark 等工具都会出现在这个 bin 目录下。2.4 编译过程最容易踩的几个现场我实际见过也帮别人排查过不少编译报错最有代表性的是三类。第一类make 阶段报 jemalloc 相关错误。Redis 默认使用自带的内存分配器 jemalloc个别老旧环境会配不上并报错。处理方式是显式指定 libcmake MALLOClibc代价是失去 jemalloc 的碎片优化但能让编译通过适合临时验证环境。真上生产还是建议搞明白为什么 jemalloc 编译失败通常跟内核版本或缺少头文件有关。第二类make test阶段报缺 tcl。报错提示通常是“You need tcl 8.5 or newer”。装好 tcl 再重新跑一遍即可。生产环境哪怕时间再紧我也建议至少把make test过一遍——这能提前暴露大量运行时才可能出现的问题。第三类编译过程中磁盘满了或者 make 中断。调整好磁盘空间后直接进入目录重新 make 就行不需要重新解压整个包因为编译产物是增量生成的。还有个细节编译完第一次启动前把 tar 包和解压出来的目录留好不要急着rm -rf。版本升级、出问题需要回看源码时这份现场就是排查的依据。3. 不折腾的路线包管理器安装 Redis以及它与编译安装的取舍3.1 两条快速路径的区别包管理器安装的最大优点就是快。Debian/Ubuntu 上sudo apt install -y redis-serverCentOS/RHEL 上sudo yum install -y epel-release sudo yum install -y redis装完系统会自动创建 redis 用户、生成/etc/redis/redis.conf、注册redis-server.service数据目录在/var/lib/redis日志默认走/var/log/redis/redis.log。这一套目录规范是发行版维护者定好的和源码编译默认都堆在/usr/local下的习惯完全不同。如果你习惯自己编译切到包管理器后别凭经验去/usr/local/redis找东西多半找不到。3.2 包管理器隐藏的细节包管理器装完有一件事必须确认服务是否真的在跑以及配置是不是生产可用。Ubuntu 的 redis-server 包装完会把服务设为启用但默认配置是bind 127.0.0.1、protected-mode yes只允许本机访问。这其实是安全默认值但很多人以为装完就能被远程应用连接结果客户端连不上就以为“Redis 坏了”。不是坏了是默认安全策略在起作用。另外版本滞后是真的。某系统默认源里 Redis 是 6.0.16官方 7.x 已经发了好久。对大多数 set/get、做缓存的需求来说 6.0 完全够用但如果要使用新特性比如 Redis 7 的 Function、更细粒度的内存碎片整理就必须自己编译或添加维护者提供的第三方源。3.3 三种安装方式的对比对比维度包管理器安装源码编译安装容器方式安装速度最快一条命令较慢依赖编译工具链快依赖 Docker/Podman版本自由度低仓库版本滞后高可精确指定中取决于镜像标签配置位置/etc/redis/redis.conf自己掌控挂载卷内配置系统集成度高自动注册 systemd需要手动写服务文件与宿主机隔离适合场景快速验证、小规模使用生产环境、多实例部署容器化环境、研发机表格看着清楚但真实选择没那么泾渭分明。我的习惯是开发机和临时验证用包管理器真正要长期维护的环境用源码编译固定版本容器化平台里则直接以镜像方式下发根本不需要关心宿主机上的安装细节。3.4 从包管理器迁移到自定义版本的注意点如果你之前用 apt/yum 装过后来决定换编译版记住先停掉原服务再小心处理数据目录。Ubuntu 上sudo systemctl stop redis-server sudo apt remove --purge redis-server--purge会清掉配置和部分数据目录如果想保留 RDB/AOF 数据提前备份/var/lib/redis下的文件。我见过不止一次因为卸载清库直接丢掉整份缓存数据——如果那里面是登录会话或商品库存这个损失就不是一杯咖啡能解决的了。4. redis.conf 核心配置装完不调这几个参数等于白装4.1 后台运行daemonize 与 supervised 的正确姿势这是第一次启动 Redis 最先遇到的问题。直接执行redis-server会默认前台运行终端一关服务就没了。老做法是在配置文件里写daemonize yes让 Redis 自己 fork 到后台。但对被 systemd 托管的服务推荐在配置文件里写supervised systemd daemonize no这个组合的意思是让 Redis 对接 systemd 的通知机制由 systemd 来判断服务是否就绪。它比daemonize yes更可靠因为 systemd 能拿到进程的真实状态做崩溃拉起和开机自启都更顺畅。直接手动redis-server 是三者里最不推荐的做法没有任何监督机制进程死了都不知道。4.2 安全三件套bind、protected-mode、requirepass默认情况下Redis 只监听 127.0.0.1也就是只能本机访问。要给局域网内其他服务器提供服务需要改bind 0.0.0.0 protected-mode yes requirepass 你的强密码这里要特别注意bind 和 protected-mode 是配合工作的。protected-mode yes时如果只 bind 了本机回环地址Redis 认为自己处于安全状态不需要密码一旦你 bind 对外网卡或 0.0.0.0Redis 会严格检查 requirepass。很多人在这里翻车bind 改了 0.0.0.0 但没设密码Redis 启动后拒绝一切请求日志里写“Client sent AUTH, but no password is set”。即使只在内网使用密码也不建议省。内网扫描工具很容易发现开放 6379 的机器没密码的 Redis 等于把数据直接交出去。Redis 6 之后还支持 ACL可以用redis-cli ACL SETUSER给不同业务建独立账号比全局 requirepass 更细粒度。生产环境一旦涉及多团队共用ACL 几乎是必选项。4.3 内存上限与持久化策略不做限制的 Redis 会把内存吃光。设置 maxmemory 不是可选项是必选项maxmemory 4gb maxmemory-policy allkeys-lru单位可以是 512mb、4gb。maxmemory 建议设置为物理内存的 60%~80%留出系统和其他进程的余量。如果整机只跑 Redis可以到 80%混跑业务服务就保守一点。maxmemory-policy常用的两种allkeys-lru表示所有键都参与淘汰适合纯缓存场景noeviction表示内存到上限后写入直接报错适合不能丢数据的队列场景。持久化方面默认 RDB 快照适合宕机恢复但会丢最后一次快照之后的数据。需要更高可靠性就开启 AOFappendonly yes appendfsync everysecappendfsync everysec是性能和安全的平衡点每秒刷盘一次最多丢一秒数据。写成always更安全但性能损耗明显写成no就别指望崩溃恢复。这是标准的“你要哪一头”选择题没有绝对正解取决于业务对数据丢失的容忍度。4.4 日志、目录与连接数源码编译安装后Redis 默认把日志打到标准输出、RDB 文件写到启动目录下这对正式运行不友好。建议在配置文件统一指定logfile /var/log/redis/redis.log dir /var/lib/redis pidfile /var/run/redis/redis.piddir决定 RDB 和 AOF 文件的落盘位置务必提前创建目录并确保运行用户有写入权限否则启动时会出现“Cant open the log file”或持久化失败。连接数方面默认maxclients 10000通常够用但单机部署大量连接时系统层可能会先报 no file descriptors。此时需要提高进程文件描述符上限这个建议写进 systemd 服务文件下一节具体说。5. 用 systemd 把 Redis 管起来开机自启与崩溃拉起5.1 为什么不能直接 redis-server 先给结论任何正式环境都不建议让 Redis 以裸后台进程的方式跑。原因很简单redis-server 只是把进程丢到后台机器重启后它不会自动回来进程异常退出也没人知道更别说做资源限制。systemd 的价值在于三件事开机自启、崩溃自动拉起、统一日志。这些都是生产环境的基础能力。包管理器安装的发行版已经帮你把redis-server.service写好了源码编译安装则需要自己动手。5.2 手写一个 redis.service 单元文件新建/etc/systemd/system/redis.service内容如下[Unit] DescriptionRedis Server Afternetwork.target [Service] Userredis Groupredis Typesimple ExecStart/usr/local/redis/bin/redis-server /etc/redis/redis.conf ExecReload/bin/kill -s HUP $MAINPID Restarton-failure RestartSec5 LimitNOFILE65535 ProtectSystemfull PrivateTmptrue [Install] WantedBymulti-user.target逐个解释关键项。User和Group指向 redis 用户。用普通用户跑服务而不是 root是安全底线。编译安装默认没有 redis 用户先创建sudo useradd --system --user-group redis sudo mkdir -p /var/lib/redis /var/log/redis /etc/redis sudo chown -R redis:redis /var/lib/redis /var/log/redis注意配置文件里dir指向的目录必须是 redis 用户有权限的目录否则启动直接报错。ExecStart指定了配置文件的绝对路径Redis 会按配置文件里的supervised systemd设置决定自己是否前台运行。Typesimple表示 ExecStart 启动的进程就是主进程这也是配合daemonize no使用的。Restarton-failure表示只在异常退出时自动拉起。RestartSec是重启间隔避免进程反复崩溃时疯狂拉起。LimitNOFILE提高文件描述符上限避免连接数增长时被内核卡住。ProtectSystemfull和PrivateTmptrue是 systemd 的沙箱选项防止进程随意写系统目录多一层保护。5.3 内核层面的两个参数除了服务文件Redis 官方文档还建议检查两个内核参数很多人装完 Redis 根本不知道它们的存在。第一个是overcommit_memory。Redis 做数据持久化时依赖 fork 写时复制如果系统内存偏紧内核可能在 fork 时直接拒绝分配内存导致后台保存失败。建议设为 1echo vm.overcommit_memory 1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p第二个是 Transparent Huge PagesTHP。THP 会增大 Redis 的延迟抖动官方建议关闭echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled注意第二条是运行时修改重启后失效。要把关闭动作做成开机执行的脚本或 systemd 单元否则每次重启还得手动来一遍。5.4 启动、启用的标准流程写完单元文件之后执行sudo systemctl daemon-reload sudo systemctl enable --now redis sudo systemctl status redisenable --now等于 enable 加 start 一步到位。status 输出里如果显示Active: active (running)说明服务起来了。之后机器重启也会自动拉起来。排查时用 journalctlsudo journalctl -u redis -n 100Redis 进程输出到标准输出的日志、报错都会汇总到这里比翻文件方便得多。凡是 systemd 托管服务日志第一站先来这里别去猜。6. 安装后的验证与现场排错别让装完变成“看似成功”6.1 用 redis-cli 走一遍基本验证装完不验证等于白装。最基本的验证redis-cli ping返回 PONG 说明服务在跑。设了密码就加-aredis-cli -a 你的密码 ping注意-a会把密码留在 shell 历史里安全做法是用环境变量export REDISCLI_AUTH你的密码 redis-cli ping然后跑一遍关键配置核对redis-cli INFO memory redis-cli CONFIG GET maxmemory redis-cli CONFIG GET appendonlyINFO memory里的used_memory_human可以直观看到当前占用used_memory_peak_human是历史峰值。这两个数据之后配监控告警也用得上值得记一下。6.2 用 redis-benchmark 压一轮Redis 自带压测工具 redis-benchmark简单跑一轮redis-benchmark -t set,get -n 100000 -c 50-t只测 set 和 get-n是请求总数-c是并发连接数。输出里重点看 Requests per second 字段能对当前机器的性能基线有个大致判断。benchmark 主要压的是本机资源结果只能做横向参考别拿它当线上容量规划的绝对依据更别拿它来和网上的跑分对比然后自我怀疑。6.3 安装现场最常见的几个报错速查我把这些年装 Redis 遇到的报错整理成一张速查表按出现频率排序报错/现象可能原因处理方式Could not create server TCP listening socket *:6379: bind: Address already in use6379 端口已被占用ss -lntp | grep 6379找到进程停掉旧服务或改 portCant open the log file: Permission deniedlogfile 目录不存在或属主不对创建 /var/log/redis 并chown给 redis 用户You must specify a password / AUTH requestedrequirepass 未设置但 protected-mode 生效给 requirepass 配密码或客户端加密码MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on diskdir 目录不可写、磁盘满查 dir 指向、磁盘空间修好后CONFIG SET dir加BGSAVEWarning: /proc/sys/vm/overcommit_memory is set to 0内核参数未调按 5.3 节设置vm.overcommit_memory 1Please use the same user for Redis and jemalloc配置里 user 参数与运行用户不一致修改 redis.conf 的 user 或 systemd 的 User最后给一个排错顺序建议先systemctl status redis看服务状态再journalctl -u redis看日志最后redis-cli ping做连通性测试。大多数问题都能在这条链路里定位别一上来就怀疑配置改错了更别随手删数据文件。日志里也有种情况是只给出一大段警告文字比如 THP、overcommit 相关它不是致命错误但看到了就顺手按上面方法处理掉能避免很多线上的诡异延迟和进程被杀问题。最后说点我自己的习惯。生产环境装 Redis我基本都走官方 stable 版本源码编译固定到一个具体版本号配置文件统一放/etc/redis/redis.conf用 systemd 托管数据目录独立密码必须设maxmemory 必须设。这套组合我维护了好几年没有一次因为 Redis 没起来被半夜叫醒。还有个经验是把 redis.conf 和 redis.service 文件都纳入配置管理不要只靠本机文件。出问题的时候能对比出“上一版配置到底改了什么”比什么都管用。多实例场景下复制多个 systemd 单元文件配合不同端口和目录6379、6380 各管一摊数据互不干扰。装 Redis 本身不难难的是把环境、配置、托管方式这些地基一次打对这篇文章就是希望你把地基一次打好。