Linux下Redis安装与三种启动方式详解：从编译到systemd托管

1. 写在前面的实话：为什么大家都在Linux上装Redis

作为一个天天跟服务器打交道的后端开发，我太清楚Redis在Linux上的地位了。公司里无论是做缓存的、做session共享的、做分布式锁的、还是搞排行榜的，基本都绕不开这个基于内存的键值数据库。但每次有新人入职，总能在Redis安装这一步卡住半天——不是装不上，就是装上了不知道怎么真正把它跑起来，或者启动了以后开个终端窗口能跑、一关窗口就没了。

我见过太多例子：有人用 redis-server 启动后只见一个前台日志在刷屏，窗口一关服务就没了；有人为了让Redis开机自启，百度了半天配了一堆乱七八糟的脚本；还有人装完压根没带配置文件，默认配置下连远程都连不上。这三个坑，本质上就是你不清楚Redis在Linux环境下到底有哪几种启动方式、每种方式适合什么场景。

这篇文章我会把整个流程掰开揉碎给你讲透：从安装前的准备工作、编译安装细节，到现在Linux上最常用的三种启动方式——前台启动、守护进程启动、systemd托管启动。我会把我实际踩过的坑、改过的配置、验证过的命令全部写出来。如果你是在学Linux、准备面试，或者需要自己搭一个Redis环境，这篇文章可以直接照着操作。

2. 动手前先把方案定下来

2.1 为什么我推荐编译安装而不是包管理器装

很多人上来就问：为什么不用 yum install redis 或者 apt install redis 直接装？这里我必须说清楚，包管理器确实省事，但有一个致命短板——版本太旧。

我曾经在CentOS 7上用过yum自带的redis，装完一看版本是3.2，当时Redis官方已经到7.x了，很多新特性根本用不上。比如Redis 4.0才有的混合持久化、Redis 6.0才引入的多线程IO，旧版本全都没有。更难受的是，如果在生产环境里因为版本太旧导致某些特性不可用，重新换版本部署的成本远比一开始就编译安装高得多。

编译安装虽然多花几分钟时间，但你能拿到官方最新的稳定版，也可以自己指定安装路径、选择编译参数，后续维护起来心里特别有底。所以在这篇文章里，我以编译安装为主线来讲，这也是绝大多数生产环境的标准做法。

2.2 安装前必须确认的几件事

在真正敲编译命令之前，先检查三样东西，缺一个后面都会出幺蛾子。

第一，检查系统有没有装gcc编译器。Redis是C语言写的，编译安装绕不开编译器。我之前在全新的一台CentOS服务器上直接编译Redis，结果报了一堆 cc: command not found 的错，就是因为没装gcc。给出的经验是不要凭感觉，直接用命令验：

bash复制gcc --version

如果提示没有这个命令，就根据系统发行版安装。CentOS/RHEL系列使用：

bash复制yum install -y gcc make

Ubuntu/Debian系列使用：

bash复制apt update && apt install -y build-essential

第二，确认磁盘空间和目录规划。Redis本身二进制文件很小，不需要什么专门的规划，但我个人习惯是统一放在 /opt/redis 这样的目录下，方便后续多版本管理。数据目录建议单独建一个，比如 /data/redis，这样日志、持久化文件和程序文件是隔离的，万一要清理或者备份数据，不会误动到程序。

第三，检查端口冲突。Redis默认用6379端口，如果之前装过其他东西占了这个端口，启动时会直接失败。先看下端口情况：

bash复制netstat -tlnp | grep 6379

如果有进程占用了，要么杀掉那个进程，要么等会改配置里的端口。我建议直接顺手把这件事做了，免得启动报错的时候又手忙脚乱。

3. 编译安装Redis全流程实录

3.1 下载稳定版源码包

日常操作中，下载Redis源码我首选去官网拿，不建议去那些来路不明的镜像站。Redis官网的下载页会列出当前最新的稳定版，你拿到的是一个tar.gz压缩包。

在这里可以用wget直接下载，省得本地下载再上传，太绕了。比如目前一个比较新的稳定版是7.x系列，命令大概是这样的形式（具体版本号以官网为准）：

bash复制wget https://download.redis.io/releases/redis-7.2.4.tar.gz

如果你是在企业内网，外网下载受限，那就只能在有网的机器上下好了再传过去。这一步没什么技术难度，但版本号一定要记清楚，后面清理和换版本的时候用得上。

3.2 解压、编译、安装三步走

下载完成之后，解压到工作目录，然后进入解压出来的目录进行编译。

bash复制tar -zxvf redis-7.2.4.tar.gz
cd redis-7.2.4
make

这里我多说一句编译时的细节。如果你不需要自定义编译参数，直接 make 就够了，它会自动编译出 redis-server、redis-cli 这些可执行文件。如果你用的是老版本Redis（比如5.x），编译时可能会提示需要jemalloc之类的内存分配器，这个基本不用管，Redis源码包里已经帮你处理好了，直接 make 就行。

如果编译过程中报错，八成是gcc版本太老或者缺少某个依赖库。我碰到过一次比较典型的情况：新装的Ubuntu系统gcc版本是9.x，编译老的Redis 4.x反而报错。这种时候不是系统问题，是源码太老跟新编译器不兼容，最好的办法是换一个新一点的Redis版本，别在编译报错里死磕。

编译完成后执行安装命令：

bash复制make install

它会默认把可执行文件复制到 /usr/local/bin 目录下面。装完你可以验证一下：

bash复制redis-server --version

能看到版本信息就说明装好了。

3.3 配置文件：不加载配置文件的Redis是不完整的

编译安装完之后，默认配置其实是不带配置文件的，直接启动Redis会用内置的默认配置。但默认配置在生产环境里就是个定时炸弹——它只绑定了本机回环地址，外部根本连不上；它没有设置密码；它还默认是前台启动。所以我在实际部署中，一定会把 redis.conf 配置文件拿出来，放到明确的位置，再针对性地修改。

Redis解压目录里自带一份 redis.conf 模板，拷贝到 /etc/redis/ 下面：

bash复制mkdir -p /etc/redis
cp redis.conf /etc/redis/redis.conf

拷贝完成以后，再根据自己的场景去调整配置。这里简单梳理几个一定会动的参数，后面启动方式里我再展开细讲：

• daemonize：决定是前台启动还是后台守护进程启动
• bind：决定允许哪些网卡访问
• protected-mode：保护模式开关，跟bind配合使用
• requirepass：设置访问密码
• dir：持久化文件存放的目录

配置文件是Redis运行的核心，不夸张地说，你在Linux上跑Redis遇到的大部分“诡异”问题，最后都是配置文件里的参数在作怪。

4. 三种启动方式：前台启动、守护进程启动、systemd启动

4.1 方式一：前台启动——最适合调试，千万别用于生产

前台启动是最简单、最原始的方式，直接执行：

bash复制redis-server

如果你没有指定配置文件，它会加载内置默认配置，启动后日志会像流水一样直接打印在当前终端的屏幕上。为什么说它适合调试？因为启动报错的信息会直接打在屏幕上，你能第一时间看到日志内容。比如你改了配置以后启动报错，前台启动时错误信息一目了然，排错效率极高。

但前台启动的坏处也是致命的：终端窗口一关，Redis进程就没了。我之前有一次临时在服务器上想测试一下Redis，直接前台启动就跑起来了，结果临时接了个电话回来发现SSH会话断了，Redis也跟着没了，当时还纳闷是不是系统把它杀了。其实根本不是系统杀它，是它依附于终端而存在，终端没了它自然就退出了。

所以前台启动的正确使用场景就是临时调试、排错、验证配置。生产环境千万不要用这种方式，除非你想体验一下“重启一下服务器，Redis就永远消失了”的刺激。

使用前台启动时，如果要指定配置文件，就用 -c 参数或者直接把它作为第一个参数：

bash复制redis-server /etc/redis/redis.conf

用这种方式启动，即使配置文件里设置了 daemonize yes，它也会按照配置去后台运行，不会在前台刷日志。

4.2 方式二：守护进程启动——后台运行的基本玩法

守护进程启动是很多教程里最常推荐的方式，核心就是把配置文件里的 daemonize 参数改成 yes。

打开配置文件：

bash复制vim /etc/redis/redis.conf

找到下面这一行：

conf复制daemonize no

改成：

conf复制daemonize yes

保存退出后，再启动：

bash复制redis-server /etc/redis/redis.conf

启动完之后你会感觉“什么都没发生”——终端干净利落地回到了命令行提示符，没有日志刷屏，Redis就在后台默默运行了。这是因为它把自己变成了daemon进程，脱离了终端控制。

这时候你验证一下进程状态：

bash复制ps -ef | grep redis

如果看到类似这样一个带 redis-server 的进程在跑，就说明成功了。还可以用自带的命令行客户端验证一下：

bash复制redis-cli ping

返回 PONG 就代表服务是活的。

这里有一个我在实际中经常踩的坑：如果你的配置里开启了守护进程，同时日志文件的配置是默认的 stdout，你会发现启动后日志根本无处可看。所以建议顺手在配置文件里设置一个日志文件路径：

conf复制logfile "/var/log/redis.log"

这样排查问题的时候有日志可查，不用干瞪眼。

守护进程方式的优点是简单、灵活、不依赖systemd。但缺点也比较明显：如果你重启了服务器，它不会自己拉起来，需要手动执行启动命令。你说我可以把这条命令塞到 /etc/rc.local 里面让它开机自启，可这么干的问题在于——它跟systemd的资源管理、日志管理、异常重启机制完全是脱节的，crash了就是crash了，没有任何机制帮你恢复它。所以这种方式适合个人开发机、临时测试环境，真正要上生产的，还是得用第三种方案。

4.3 方式三：systemd托管——生产环境的标准答案

现在主流Linux发行版（CentOS 7+、Ubuntu 16.04+、Debian 8+）都用systemd来做系统和服务管理。用systemd托管Redis，能让Redis像系统内置服务一样开机自启、崩溃自动重启、日志交给journald管理，这才是生产级该有的待遇。

第一步，在 /etc/systemd/system/ 下面创建一个service unit文件：

bash复制vi /etc/systemd/system/redis.service

文件内容如下，这是我经过多次调整后稳定使用的版本：

ini复制[Unit]
Description=Redis persistent key-value database
After=network.target

[Service]
ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
Type=simple
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

这里重点解释一下几个关键项，因为很多人都是直接复制粘贴，完全不知道每行在干嘛。

ExecStart 是启动命令。我在这里用了绝对路径 /usr/local/bin/redis-server，配置文件的路径也写全。注意，虽然我这里配置了配置文件路径，但如果配置文件里的 daemonize 还开着 yes，systemd会出问题。因为systemd要求前台进程，它需要直接管理这个进程的生命周期，如果Redis自己又fork成后台守护进程，systemd会认为服务启动失败或者出现“主进程退出了但子进程还在跑”的诡异状态。所以用systemd管理的时候，配置文件里的 daemonize 必须是 no，这一点极其重要。

Type=simple 的意思是，ExecStart启动的这个进程本身就是系统服务的主体，不需要额外的通知机制。对于Redis这种一直在前台运行的进程来说，这个设置是对的。如果你的Redis配置了 daemonize yes，那其实更像 Type=forking 的语义，但我不建议在systemd里用forking，会把事情搞复杂，直接保持前台运行让systemd管理是最清晰的做法。

Restart=always 意味着只要进程异常退出，systemd就会自动拉起它。RestartSec=3 是重启前等3秒，防止频繁崩溃时疯狂重启把机器拖垮。我测试过，Redis被意外kill掉之后，3秒内系统会自动把它拉起来，这一点对生产环境太重要了。

WantedBy=multi-user.target 则指定了此服务要跟随系统进入多用户模式而启动，也就是开机自启的开关。

第二步，重新加载systemd配置：

bash复制systemctl daemon-reload

第三步，设置开机自启：

bash复制systemctl enable redis

第四步，启动服务：

bash复制systemctl start redis

启动以后用systemd的方式查看运行状态：

bash复制systemctl status redis

输出里能看到 Active: active (running) 就说明跑起来了。这里日志不再是文件里的内容，而是被journald统一接管，用下面命令查看Redis日志：

bash复制journalctl -u redis

哪怕Redis真的启动失败，也能从这个日志里看到具体的报错。

使用systemd以后你会发现，“重启服务器”这件事终于不用提心吊胆了。开机后啥都不用干，Redis自己就起来了，这在生产环境的日常运维中非常省心。

5. 启动后的必备验证与常用运维命令

5.1 三种方式各自怎么验证

很多新手把服务启动起来后，心里还是没底，不知道到底成没成功。因为在Linux上“命令没报错”不代表“服务真的在跑”，这里有我每次部署完都要做的一套检查，每一步都不多余。

第一步，看进程：

bash复制ps -ef | grep redis-server

如果能看到进程，说明进程层面是正常的。注意别被 grep 自己干扰，你可以在grep后面加 [r]edis-server 或者手动看输出里是不是真的有redis-server进程。

第二步，ping服务：

bash复制redis-cli ping

返回 PONG 表示服务正常。这一步是强力验证——说明不仅进程在，而且端口是通的、客户端能连上、服务在正常响应请求。我见过有的服务器上进程僵尸一样挂着，但端口不通，这时ping就能发现问题。

第三步，如果设置了密码，ping命令需要带密码：

bash复制redis-cli -a yourpassword ping

这里我要强调一个安全细节，redis-cli -a 会把密码暴露在命令行里，通过 history 命令就能看到你输入的密码。我建议使用环境变量的方式，比如：

bash复制REDISCLI_AUTH=yourpassword redis-cli ping

这样能避免密码留在shell的历史记录里。

5.2 systemd下的常用管理命令

三种方式里系统最推荐的是systemd，所以日常管理命令也重点围绕它展开。这里给你整理成一个速查表：

如果你用的是守护进程方式，重启就是先找到进程ID然后kill掉再启动：

bash复制pkill redis-server
redis-server /etc/redis/redis.conf

但比起systemd的 systemctl restart redis，这种手动处理在操作上麻烦得多，而且容易漏掉一些清理步骤。

5.3 设置密码后客户端怎么连

在配置文件里设置密码：

conf复制requirepass yourpassword

重启Redis后，直接用 redis-cli 会发现什么命令都提不了数据，提示 NOAUTH Authentication required。这时必须先认证才能操作：

bash复制redis-cli
auth yourpassword

或者直接带密码访问。对于远程连接来说，生产环境使用可视化工具如RedisInsight、Another Redis Desktop Manager，在连接配置里填上刚才设置的密码就行。

这里我要提醒一个容易踩的坑：如果你在一个局域网里跑了多个Redis实例，不同实例用不同密码，配置里一定要确认好密码对应的是哪个实例。我有一次在Redis里配了两个端口，由于密码配置没分开设，结果一个端口能连一个不能连，排查了半天才发现是配置文件里注释错位了。

6. 我踩过的坑：常见报错与排查方案

6.1 启动报错：Can't open the log file

有一次我在一个很干净的全新机器上安装了Redis，按照习惯把配置里的 logfile 设成了 /var/log/redis.log，但启动的时候直接报错说打不开日志文件。排查了半天，原因竟然是 /var/log 目录下没有权限创建文件——我当前是用普通用户启动的，而 /var/log 属于root。

解决办法很简单，两个方向：一是给日志目录授权，把目录所有权交给启动Redis的用户；二是直接把日志路径放在一个有权限的目录里，比如 redis 用户的家目录下。在生产环境里我建议创建一个专用的redis系统用户，然后用 chown 把数据目录、日志目录的所有权给它，这样权限模型清晰，不容易出乱子。

还有一个跟日志有关的冷门坑：如果你的日志文件在某个目录下，但目录不存在，Redis不会自动创建。启动时会报 Can't open the log file: No such file or directory。所以务必先 mkdir -p 建好目录再启动。

6.2 前台启动时可以跑，后台启动就失败

这种问题极具迷惑性，我早期排查过很长时间。现象是：用 redis-server 前台启动一切正常，一改用 daemonize yes 后台启动，Redis立刻消失。

后来看日志才明白，问题出在 dir 这个配置上。后台启动时，Redis的工作目录会变成你配置的 dir，如果这个目录不存在或者没有写入权限，Redis初始化持久化文件时就会失败，然后进程直接退出。而前台启动时，工作目录就是当前终端所在的目录，恰好这个目录可写，所以一切正常。

解决办法是把配置文件里的 dir 设置成一个确实存在且有权限的目录，比如：

conf复制dir /data/redis

然后 mkdir -p /data/redis，再启动就正常了。这个坑凡是做过守护进程部署的人基本都踩过，而且如果你不去翻日志，光看现象真的很难猜到是 dir 的问题。

6.3 服务器重启用systemd启动失败：redis.service not found

这个问题往往不是真的没配置service文件，而是配置文件路径写错了，systemd找不到unit。比如你明明创建了 /etc/systemd/system/redis.service，但如果在别的机器上搞混了路径，把它放到了 /etc/init.d/ 下面，那systemd风格的操作就会直接报service not found。

检查一下文件是不是真的在 /etc/systemd/system/ 下面，然后执行：

bash复制systemctl daemon-reload

再试一次。注意每次修改service文件后都得daemon-reload，否则systemd还会用旧的内存缓存，这一点特别容易忽略。

6.4 端口不通：bind和protected-mode配合出来的问题

这是远程访问Redis最常遇到的问题。默认配置下Redis只绑定 127.0.0.1，外面的机器当然连不上。本地测试没问题，一跨机器就玩完。

要允许外部访问，需要改两个地方。一个是 bind 参数：

conf复制bind 0.0.0.0

或者是绑定具体的内网IP。另一个是 protected-mode，它在没有密码且没有bind特定IP时，会拒绝来自非本机的访问。最直接的方案是把 protected-mode 设置成 no，但我更建议开启密码验证，毕竟生产环境下暴露一个无密码的Redis端口到网络上，等于给攻击者递刀。

正确的远程配置组合是，bind 0.0.0.0 + requirepass 设置复杂密码 + 开启防火墙只放行指定IP来源的6379端口。这样才能安全地让外部访问。

6.5 Redis进程在，但是内存一直涨、响应变慢

这个问题虽然不是启动阶段的，但部署完正式使用后很容易遇到，我顺手写在这里。如果你运行的Redis是当缓存用，没有设置内存上限，它在极端写入场景下会吞噬所有可用内存，直到操作系统OOM把进程干掉。

所以配置里一定要设置 maxmemory，比如：

conf复制maxmemory 2gb
maxmemory-policy allkeys-lru

maxmemory 是内存上限，allkeys-lru 是满了之后按照最近最少使用原则淘汰键。有了这两行配置，Redis在内存压力下能自动牺牲一些数据来保全自身，否则生产环境迟早会因为内存被打爆而出事故。

7. 根据我的经验，三种方式到底怎么选

启动方式的选择，说到底取决于你的使用场景，我在这里直接给一套自用的选型建议。

如果你是本地自己写代码，临时起一个Redis来做缓存、做队列，用守护进程方式就够了，开起来以后后台运行，不干扰终端操作。但记得要把开机自启这件事配置好，用systemd会更省心。

如果你是给公司的测试环境、预发布环境部署，直接上systemd托管。哪怕这台机器就是一台测试机，也要保证重启后服务能自己起来，而且日志能被journald统一接管。测试环境的稳定性往往影响开发效率，别在这种地方省事。

如果是生产环境，想都不要想，只用systemd托管。因为生产环境Redis必须做到开机自启、崩溃重启、日志可查，这三个诉求恰好都是systemd的长项。不要用守护进程方案替代systemd，虽然那种方式当年在旧时代也跑得挺好，但在现代Linux上，规范做法就是把服务交给systemd。

8. 最后再提醒你几件小事

我编译安装过多次Redis，踩过的坑上面基本都覆盖了。最后再分享几个不太起眼但很影响体验的细节。

第一，make test 是验证编译结果的好帮手，虽然它跑起来比较耗时，但在生产安装前花两分钟跑一遍，能提前发现环境兼容性问题，比后面出了问题再去回溯安心得多。

第二，Redis的命令行客户端有个很好用的交互方式，输入 redis-cli 进入命令行以后，可以用 info 命令快速查看当前Redis的版本、内存、连接数。我每次部署完都要看一眼 info server 和 info memory，确认一切正常才敢交付。

第三，如果你在云服务器上部署，记得在安全组层面把6379端口控制好。无论你在Redis层怎么设密码，都别把端口对全网开放，除非你有非常明确的理由。

总而言之，安装Redis在Linux上不难，难的是把它跑得明明白白。编译安装、配置文件调整、三种启动方式怎么选，这些事情并不需要复杂的技术功底，但确实需要经验。希望我这篇内容能帮你把每一步都走稳，后面再遇到跟Redis有关的部署问题，至少心里有张清晰的地图了。