第一次在Linux服务器上装Redis很多人都是这个流程搜教程、复制粘贴、make、make install然后启动的时候懵了——怎么一关终端服务就没了为什么我的redis.conf改了没效果systemctl start redis怎么老失败这篇文章我就把我在Linux上装Redis的全过程写清楚从环境准备到编译安装再到三种启动方式的原理和场景全部拆开讲。看完之后你不仅能顺利装起来还能根据自己需求选出最合适的启动方式不会再出现“服务跑着跑着丢了”或者“开机不自启”这种尴尬事。这期内容适合刚入门的运维、准备把项目部署上服务器的开发者以及那些Redis装了无数次、但一直没搞懂“守护进程”和“systemd托管”区别的朋友。1. 安装前的环境准备与版本选型1.1 先确认你的系统底子在动手安装Redis之前我一直建议你先花两分钟把服务器基础信息看清楚。很多人上来就是wgetmake结果编译到一半报错回头才发现gcc都没装白白浪费时间。先确认操作系统发行版和版本cat /etc/os-release这一步能看出你用的是CentOS、Ubuntu、Debian还是其他发行版后面安装依赖时用到的包管理器完全不一样。CentOS系用yumUbuntu/Debian系用apt搞混了就是各种“No package”报错。再看系统架构uname -m绝大多数云服务器是x86_64如果碰到ARM架构比如某些国产服务器编译参数和二进制兼容性需要注意不过从源码编译的话问题不大。接着检查编译工具链which gcc which make如果没有输出说明系统里没装编译工具。Redis是C语言写的官方给的是源码包必须用gcc编译成可执行文件。这一步绕不过去。CentOS/RHEL系列执行yum install -y gcc makeUbuntu/Debian系列执行apt update apt install -y build-essential顺便把tcl也装上后面如果想跑官方测试套件会用到# CentOS yum install -y tcl # Ubuntu apt install -y tcl这里有个实操心得我见过太多人在这一步翻车。有些系统是最小化安装不仅没有gcc连wget、tar、vim都没有。建议在装Redis之前先把这些基础工具补齐yum install -y wget vim tar一次性装好省得后面每个命令报一次“command not found”。1.2 下载Redis源码包确认好环境之后去Redis官网下载源码包。官方下载地址是https://download.redis.io/releases/这里会列出所有历史版本。选版本时我建议选最新的稳定版比如7.2.x或者更新一点的7.x系列。6.x和5.x虽然还有存量系统在用但新部署的项目没必要用老版本新版本在性能、安全补丁、新数据结构支持上都更好。下载时先建一个统一的源码目录不要随便丢在/home下mkdir -p /usr/local/src cd /usr/local/src然后用wget拉包wget https://download.redis.io/releases/redis-7.2.5.tar.gz我这里用的是7.2.5你下载时注意看一下官网最新的稳定版版本号把命令里的版本号替换掉就行。下载完后顺手看一眼文件大小合理范围应该在几MB左右。如果只有几百字节大概率下载出问题了检查一下网络。解压tar -xzf redis-7.2.5.tar.gz cd redis-7.2.5解压之后可以先看看README.md里面有基本的编译安装说明。源码包里的内容蛮有意思的除了C源码外还有配置模板、测试脚本、systemd相关文件后面启动方式部分会用上。2. 源码编译安装Redis全流程2.1 解压编译安装三步走进入源码目录后依次执行三条命令make make test make install第一条命令make是编译把C源码变成可执行文件。这里有个小技巧服务器核心多的话可以并行编译速度快很多make -j$(nproc)nproc会返回CPU核心数比如8核就是make -j8。实际体验下来编译速度快了不是一点半点。make test是跑官方测试套件这一步不是必须的但如果你时间充裕建议跑一遍。它能帮你确认当前环境的编译没问题避免某些隐藏兼容性问题在运行期才暴露。整个测试大概需要几分钟看到All tests passed就代表通过。最后make install会把Redis的可执行文件复制到/usr/local/bin目录下。安装完成后验证一下redis-server --version能正常打印版本号说明编译安装已经成功。踩坑提醒有时候make test会因为缺少tcl报错提示You need tcl 8.5 or newer in order to run the Redis test这就是我前面让你提前装tcl的原因。2.2 规划Redis的目录结构很多人用Redis是裸奔状态——二进制装完直接启动配置文件、日志、数据文件乱成一团。等你部署过几个正式项目就知道规范化目录结构有多重要。我的习惯是这样规划# 配置文件目录 mkdir -p /etc/redis # 数据文件目录RDB快照、AOF日志 mkdir -p /var/lib/redis # 日志目录 mkdir -p /var/log/redis然后把源码目录里的配置模板复制到配置目录cp /usr/local/src/redis-7.2.5/redis.conf /etc/redis/redis.conf这三个目录分别干什么用我简单解释一下/etc/redis存放redis.conf主配置文件系统里所有服务配置都习惯放/etc下统一管理。/var/lib/redisRedis持久化数据落盘的位置包括RDB快照文件dump.rdb和AOF日志文件appendonly.aof。这个目录的权限要特别注意后面讲。/var/log/redis日志文件目录排查问题全靠它。目录权限方面如果你后面要用非root用户运行Redis需要把数据目录所属用户改掉useradd redis chown -R redis:redis /var/lib/redis /var/log/redis /etc/redis这块是很多人容易漏的。用root启动Redis当然能跑但生产环境安全建议是用独立用户运行服务权限最小化。后面systemd部分会再提一次。2.3 基础配置文件模板解读Redis的redis.conf配置文件是真的长默认模板有上千行但真正必须理解的核心参数其实就那几个。我截取一段生产可用的基础配置你可以照着改# 监听地址默认只监听本机回环地址 bind 0.0.0.0 # 监听端口 port 6379 # 是否以后台守护进程方式运行systemd托管时必须是no daemonize no # PID文件位置 pidfile /var/run/redis_6379.pid # 日志级别debug / verbose / notice / warning loglevel notice # 日志文件路径空字符串表示输出到标准输出 logfile /var/log/redis/redis.log # 数据目录 dir /var/lib/redis # 配置密码生产环境必须设置 requirepass 你的强密码 # 是否开启AOF持久化 appendonly yes # RDB和AOF的设置... save 900 1 save 300 10 save 60 10000每个参数的含义和调优策略我后面在“启动后的配置调优”章节会细讲。现在先有个印象重点是daemonize这个参数它和启动方式强相关后面三种启动方式里会反复提到它。3. Redis三种启动方式一篇讲透3.1 方式一前台启动适合临时调试最简单的启动方式直接执行redis-server不加任何参数时Redis会使用内置的默认配置启动监听6379端口。你会在终端看到类似这样的输出127.0.0.1:6379 * Ready to accept connections tcp此时Redis就在当前终端前台运行。特点是日志实时刷在终端上调试时非常直观按Ctrl C直接停掉服务致命缺点一旦关闭终端或者SSH断开Redis进程就会被终止原理很简单前台进程的父进程是终端shell终端关闭时会向子进程发送SIGHUP信号Redis默认就退出了。所以前台启动只适合两种情况一是临时起个实例跑一下测试二是排查启动参数和配置问题时看实时日志。生产环境千万别这么干断个SSH连接Redis就没了这事故出了不是一两次。前台启动时如果想用指定配置文件要手动指定redis-server /etc/redis/redis.conf配置文件里如果设置了daemonize no照样是前台运行。3.2 方式二后台守护进程启动传统标配第二种方式就是把Redis作为守护进程daemon跑在后台。实现方式有两种第一种是改配置文件把daemonize改为yesdaemonize yes然后启动redis-server /etc/redis/redis.conf命令执行后终端会立即返回Redis进程在后台运行。用ps或者redis-cli ping都能确认服务状态。第二种是不改配置文件直接命令行加参数覆盖redis-server /etc/redis/redis.conf --daemonize yes这两种方式本质一样都是让Redis自己fork一个子进程到后台父进程退出。区别只是配置来源不同。命令行参数优先级比配置文件高适合临时测试时用不建议长期这么搞因为很容易忘记自己加过什么参数。后台启动后怎么关闭不要直接kill -9那不优雅可能导致数据丢失。正确方式是使用Redis自带的关闭命令redis-cli shutdown如果配置了密码redis-cli -a 你的密码 shutdownRedis收到shutdown命令后会先把内存中的数据持久化到磁盘再退出进程这是最安全的关闭方式。这里有个我踩过的坑用符号让redis-server在后台运行比如redis-server /etc/redis/redis.conf 这种方式其实不算真正的守护进程。关闭终端后虽然因为不会立即挂掉但进程会和终端产生一些关联尤其是SSH会话终止时SIGHUP信号依然有可能把Redis带走。正确的后台运行姿势就是修改daemonize yes别用凑合。3.3 方式三systemd服务化管理启动生产环境首选如果你用的是CentOS 7以上、Ubuntu 16.04以上系统的服务管理器基本都是systemd。用systemd管理Redis好处非常明显开机自动启动进程崩溃后自动拉起统一通过systemctl status查询状态日志交给journald统一管理可以用systemd的权限沙箱机制加固Redis这也是我现在做生产部署的标准做法。首先Redis源码包里其实自带了一个systemd服务模板文件位置在/usr/local/src/redis-7.2.5/utils/systemd-redis_server.service但我不太建议直接用这个文件它的配置比较简略。我习惯自己写一个配置更可控。创建服务文件vim /etc/systemd/system/redis.service写入以下内容[Unit] DescriptionRedis persistent key-value database Afternetwork.target Afternetwork-online.target Wantsnetwork-online.target [Service] # 使用systemd托管时redis必须以非守护进程方式运行 ExecStart/usr/local/bin/redis-server /etc/redis/redis.conf --supervised systemd ExecReload/bin/kill -s HUP $MAINPID ExecStop/bin/kill -s QUIT $MAINPID Typenotify Userredis Groupredis RuntimeDirectoryredis RuntimeDirectoryMode0755 LimitNOFILE65535 PrivateTmptrue ProtectSystemfull NoNewPrivilegestrue ProtectHometrue ReadWritePaths/var/lib/redis Restartalways [Install] WantedBymulti-user.target这里面有几个关键点必须说清楚。第一个关键点是--supervised systemd参数。加了它之后Redis会识别自己是受systemd管理的启动完成后会主动通知systemd“我已经就绪”这样systemd的Typenotify才能正常工作。如果不加这个参数Typenotify会一直等待就绪通知直到超时服务会启动失败。第二个关键是配置文件的daemonize必须设为no。因为systemd需要直接管理Redis主进程如果Redis自己fork到后台systemd会认为主进程已经退出从而判定服务启动失败。这一点特别容易踩坑网上很多教程让你在配置文件里设daemonize yes然后配systemd结果一启动就报错就是这个原因。第三个关键是我把服务运行用户设成了redis所以在启动之前必须先创建这个用户并且确保数据目录读写权限正确useradd --system --user-group redis mkdir -p /var/lib/redis chown -R redis:redis /var/lib/redis接下来就是标准的systemd操作流程# 重新加载服务配置文件 systemctl daemon-reload # 设置开机自启并立即启动 systemctl enable --now redis # 查看状态 systemctl status redisstatus输出里如果看到Active: active (running)说明服务起来了。开机自启也不用担心enable已经配置好。停止服务systemctl stop redis重启服务systemctl restart redis这种方式才是生产环境最稳妥的选择。3.4 三种启动方式横向对比三种启动方式放到一起对比你会看得更清楚维度前台启动后台守护进程systemd托管启动命令redis-serverredis-server /etc/redis/redis.confsystemctl start redis后台运行否是是关终端影响直接退出不受影响不受影响停止方式CtrlCredis-cli shutdownsystemctl stop redis开机自启不支持需自行添加启动项systemctl enable崩溃自动重启不支持不支持支持Restartalways日志管理终端实时输出配置指定的日志文件journald统一收集适用场景临时调试、快速实验传统手工管理环境生产环境、正式集群我自己的选择习惯是临时在本地虚拟机验个功能用前台启动VPS上小项目跑个Redis实例用后台守护进程公司正式环境一律systemd托管。每个方式都有它的应用场景不存在哪个“最好”只有哪个“最合适”。4. 启动后的连通性验证与关键配置调优4.1 用redis-cli确认服务是真的活着很多人启动完Redis看到终端“Ready to accept connections”就以为万事大吉其实这一步只说明进程起来了不代表服务一定正常。我最常用的验证命令是redis-cli ping如果返回PONG说明Redis能正常响应客户端请求这是最基本的连通性验证。如果配置了密码需要带上密码redis-cli -a 你的密码 ping不过要注意的是-a参数会把密码暴露在进程列表里在多人共用的服务器上有安全隐患。另一种安全方式是登录后再认证redis-cli 127.0.0.1:6379 AUTH 你的密码回车后返回OK就代表认证成功。接着可以看服务器信息redis-cli info server这里能看到Redis版本、进程ID、运行天数、连接的客户端数、内存使用情况等关键指标。我强烈建议你用redis-cli info memory看看内存以及redis-cli info persistence看看持久化状态。再验证一下数据读写是否正常redis-cli 127.0.0.1:6379 SET test_key hello OK 127.0.0.1:6379 GET test_key hello能正常SET和GET说明这个Redis实例已经不只是“活着”而是真正可用了。验证完把测试键删掉127.0.0.1:6379 DEL test_key这些基础验证步骤我建议你在每次启动完Redis之后都跑一遍尤其是重启过服务后别等到业务报错了才回头看。4.2 生产环境必须调整的几个配置项刚装好的Redis默认配置非常保守只适合本地开发直接上生产会出大问题。我整理了几个开箱后必须关注的核心配置项。bind和protected-mode默认配置下Redis只监听127.0.0.1外部机器是连不上的。如果你需要让其他服务器访问第一件事是把bind改成0.0.0.0同时把protected-mode设为no或者保留保护模式但配置好密码否则外部连接会被拒绝bind 0.0.0.0 protected-mode yes requirepass 你的强密码这里我必须多说一句对外开放Redis监听端口时如果密码没设置相当于把数据裸奔在公网上。现在网上有大量扫描脚本在扫6379端口一旦发现没密码的Redis立刻就会被入侵、篡改数据甚至植入挖矿程序。这个坑我亲眼见过不止一次血的教训。requirepass设置Redis访问密码。生产环境必须设置而且不能用弱密码requirepass Xz9#kLp2Qw8设置密码之后所有客户端连接都要认证包括前面提到的redis-cli。dir和持久化数据保存目录就是之前规划的/var/lib/redis。同时根据你的业务需求决定是否开启AOFdir /var/lib/redis appendonly yes appendfsync everysecappendfsync everysec表示每秒把AOF缓冲刷到磁盘一次是性能和安全的折中方案。如果数据对丢失零容忍可以改成always但写入性能会明显下降。maxmemory设置Redis最大可用内存。不设置的话Redis会一直吃内存直到系统OOM。建议根据服务器物理内存设置一个合理上限比如机器有8G内存Redis可以分到4Gmaxmemory 4gb maxmemory-policy allkeys-lrumaxmemory-policy是内存达到上限后的淘汰策略allkeys-lru表示对所有键按照LRU算法淘汰适用于缓存场景。logfile日志路径。确认配置文件里设置的是之前规划的日志目录logfile /var/log/redis/redis.log这样排查问题时直接看日志文件就行。4.3 外部客户端连不上Redis时怎么排查启动完Redis后面用代码或者Redis Desktop Manager等可视化客户端连的时候经常出现连接失败。我整理了一套排查思路顺序执行基本能定位问题。第一先确认Redis进程在跑ps -ef | grep redis第二确认端口在监听netstat -tlnp | grep 6379如果输出里有0.0.0.0:6379或者*:6379说明正在正常监听。如果只有127.0.0.1:6379说明Redis只绑定了本机外部连接会被拒绝这就是连接不上的原因之一。解决办法是修改bind配置后重启。第三确认防火墙放行了端口。很多云服务器还有安全组策略ECS安全组、防火墙规则都要检查# CentOS 7 使用firewalld firewall-cmd --list-ports firewall-cmd --add-port6379/tcp --permanent firewall-cmd --reloadUbuntu用ufw的话ufw allow 6379/tcp第四确认密码是否正确。配置了密码但客户端没带密码或者密码输错都会得到NOAUTH Authentication required或者ERR invalid password的错误提示。第五网络不通的话用telnet测一下telnet 服务器IP 6379能通的话会看到Redis banner不通就是网络层面的问题。这套流程走下来95%的“连不上”问题都能找到原因。5. 实操中遇到的高频问题与排查笔记5.1 编译报错command not found: make 或 gcc这个前面提到过一次后台私信问我这个问题的最多必须展开说。报错信息通常是-bash: make: command not found或者编译过程中报cc: command not found原因就是最小化安装的Linux系统没有装编译工具链。解决办法在第一节已经给过CentOS用yum install -y gcc makeUbuntu/Debian用apt install -y build-essential。装完重新执行make就行不需要重新解压源码包。还有一个变种问题gcc版本太老。比如CentOS 7默认的gcc 4.8.2编译Redis 7.x会报错。我遇到过You need tcl 8.5 or newer或者C标准相关的报错。解决办法是安装高版本gccyum install -y centos-release-scl yum install -y devtoolset-9 scl enable devtoolset-9 bash这是CentOS 7环境下的一个经典坑新系统比如CentOS 9、Ubuntu 22.04基本不会遇到。5.2 启动秒退日志里到底写了什么Redis启动后立即退出这是排查耗时最长的问题。我的建议很简单不要盯着终端看先看日志。如果日志路径配置为/var/log/redis/redis.logtail -100 /var/log/redis/redis.log最常见的报错有这么几类。权限不足Cant open the log file: Permission denied # 或 Cant chdir to /var/lib/redis: Permission denied大概率是你用redis用户启动但日志目录、数据目录属主还是root。解决chown -R redis:redis /var/log/redis /var/lib/redis /etc/redis数据目录不存在Cant chdir to /var/lib/redis: No such file or directory解决确认目录存在不存在就mkdir -p创建。端口被占用Could not create server TCP listening socket *:6379: bind: Address already in use说明6379端口已经被别的进程占用用netstat -tlnp | grep 6379查一下谁占用了要么杀掉旧进程要么给新Redis换端口。还有一种情况启动时明明看到一堆INFO日志然后进程消失这种多半是配置文件里daemonize yes和systemd配置冲突导致的接下来单独说。5.3 systemd启动失败的三个典型原因用systemd启动Redis失败systemctl status redis会显示failed。这时候先别慌按顺序查三件事。第一件事查看详细错误信息journalctl -u redis -n 50 --no-pager这是redis服务的详细日志错误原因基本都写在里面。第二件事检查daemonize和Type的匹配关系。我在3.3节强调过systemd托管时配置文件的daemonize必须是no。如果你的配置里写的是daemonize yessystemd会把Redis fork到后台然后认为主进程退出了Service显示启动失败。第三件事检查ExecStart的路径是否真实存在。很多人把redis-server装在别的目录但unit文件里写的是/usr/local/bin/redis-server找不到二进制文件自然会失败。确认一下which redis-server得到的路径就是ExecStart里要写的路径。另外如果用到--supervised systemd确保这个参数没有拼写错误。还有一个容易被忽略的权限问题systemd unit文件本身如果权限不对比如/etc/systemd/system/redis.service不是644权限systemctl会拒绝加载或者启动时行为异常。可以用chmod 644修正。5.4 启动时的几个warning要不要处理首次启动Redis时日志里经常出现几个WARNING很多人看到就心慌。我逐个说下要不要管。overcommit_memory warningWARNING: overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add vm.overcommit_memory 1 to /etc/sysctl.conf and then reboot or run the command sysctl vm.overcommit_memory1这个涉及Linux内核的内存分配策略Redis做RDB快照时需要fork子进程如果内存不足可能失败。建议按提示设置echo vm.overcommit_memory 1 /etc/sysctl.conf sysctl vm.overcommit_memory1TCP backlog warningWARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.这个影响的是高并发场景下的连接排队长度建议调大echo net.core.somaxconn 511 /etc/sysctl.conf sysctl net.core.somaxconn511transparent huge page warningWARNING: you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis.THP是Linux内核的透明大页机制对Redis这种延迟敏感型应用不太友好建议关闭echo never /sys/kernel/mm/transparent_hugepage/enabled这个命令重启后会失效要永久生效得写入rc.local或者systemd的ExecStartPost里。这三个warning我个人的处理原则是开发环境可以不管生产环境按提示全部处理掉。处理完Redis的响应延迟会更稳定尤其是第一个overcommit_memory直接影响RDB持久化的可靠性。6. 最后聊几句我的个人习惯Redis装好、三种启动方式都试过之后我建议你在这台服务器上建立一个固定的“服务操作肌肉记忆”——统一用systemd来管理生命周期把redis-cli shutdown作为在服务器上手动的兜底操作。我自己踩过太多次“进程莫名其妙没了”的坑后来养成的习惯是不管用哪种方式启动启动完立刻验证路径和数据持久化目录是否正确同时把配置文件的daemonize和supervised参数记清楚。再就是密码一定设bind一定改防火墙一定放行精确IP这些看似琐碎的东西往往是后面线上事故的根源。另外一个建议是刚装完Redis的阶段趁着实例是干净的多玩一玩基础命令比如SET、GET、EXPIRE、TTL还有常用的数据类型操作。Redis安装本身不难真正难的是理解它怎么工作、怎么配置才适合你的业务。希望这篇内容能帮你少走点弯路。如果你在安装或者启动阶段遇到问题按我上面给的排查路径走一遍基本都能定位到原因。