做运维的几乎没有不碰Redis的。但要说在Linux上把Redis装起来很多刚接触服务器的人还真不一定一次装顺——装完不知道怎么启动、启动后连不上的情况我见过太多了。这篇文章我就把Linux安装Redis这件事从头到尾过一遍重点放在三种启动方式上前台启动、后台守护进程启动、systemd托管启动。内容按实操顺序走从环境检查到编译安装再到配置参数和报警排查尽量把我自己踩过的坑也一并交代清楚适合刚入门Linux运维的读者也适合想理顺Redis部署流程的开发者参考。1. 安装前的准备先把环境盘清楚再动手1.1 Linux发行版和CPU架构别搞混不管你是用CentOS、Ubuntu还是Debian第一步永远是先确认机器本身的情况。原以为这是废话结果真有人拿着Ubuntu的命令往CentOS上敲装到一半才发现包管理器不一样。检查命令就两条cat /etc/os-release uname -m第一行告诉你系统是哪个发行版、什么版本。第二行告诉你CPU架构。x86_64是常见的Intel/AMD机器aarch64则是ARM架构。后面源码编译的命令两类架构都能用但你要是在x86机器上下了ARM的包那编译出来是跑不起来的。这个步骤花不了十秒钟但能省掉后面一堆麻烦。我见过一个典型的坑有人在飞腾ARM服务器上装Redis图省事直接复制了网上x86的二进制包运行的时候直接提示无法执行二进制文件。所以架构信息一定要先看清楚。1.2 包管理器安装和源码编译怎么选装Redis有三条路用系统包管理器、源码编译、容器化。我先说结论生产环境我最推荐源码编译理由后面一句句讲。包管理器安装CentOS上用yum install redisUbuntu上用apt install redis-server。优点是快依赖自动处理好有些发行版甚至把systemd服务脚本都准备好了。缺点是版本通常滞后装出来的Redis可能落后两三个大版本而且很多编译参数你没法自己调。源码编译优点是版本可选安装目录可控你在网上看到的大部分“定制化部署”都是基于源码编译做的。缺点是步骤多一点依赖要自己装。容器化部署用Docker拉官方镜像确实是一条捷径比较适合平台化标准化场景。但对于单机部署或刚入门的人Docker带来的网络、存储概念反而更容易把人绕晕。我用一个表格给你总结下安装方式优点缺点适合场景yum/apt安装速度快、依赖自动解决版本旧、定制受限本地开发、快速验证源码编译安装版本可选、参数可控、目录干净步骤多、依赖需要手动生产环境部署Docker容器安装环境隔离、分发一致、多实例方便网络/存储配置绕、测试成本高容器化平台、多实例场景事实上很多系统自带的Redis版本都低于6.x而Redis 6.0以后才有的ACL权限管理和多线程IO这些功能老版本都没有。如果你需要这些能力源码编译是绕不开的路。1.3 编译依赖提前补齐不然半路报错很折腾源码编译Redis主要依赖两个东西gcc和make。Ubuntu/Debian系统执行sudo apt update sudo apt install -y build-essentialCentOS/RHEL系统执行sudo yum install -y gcc make这里有个超级常见的坑CentOS 7自带的gcc是4.8.5编译Redis 6.2以上版本时经常报错。我当年就是被这个坑结结实实卡了一晚上报错信息五花八门查了半天才锁定是编译器版本问题。如果你也碰到编译中途报一些莫名其妙的语法错误先看看gcc版本gcc --version如果低于9建议直接用SCL软件集合升级sudo yum install -y centos-release-scl sudo yum install -y devtoolset-9 scl enable devtoolset-9 bash这条命令执行后当前终端就能用新的gcc了。注意如果你之前已经编译了一半升级完gcc后一定要先执行make distclean清理旧编译产物再重新make否则旧object文件残留可能导致怪异的链接错误。2. 源码编译安装Redis从下载到落地的完整步骤2.1 下载源码包版本怎么选去Redis官网下载区找稳定版源码包文件命名一般是 redis-7.2.5.tar.gz 这类格式具体版本号以官网最新稳定版为准。下载用wget或curl都行wget https://download.redis.io/releases/redis-7.2.5.tar.gz版本选择上生产环境建议选7.x的稳定版或者6.2.x这种广泛验证过的版本不要去追rc候选版。Redis 7.x相比6.x在内存效率、命令延迟和AOF相关机制上都有改进长期使用建议直接上7.x。如果你只是为了验证一个临时需求那装什么都无所谓但要是准备长期运行版本选型值得花两分钟看看官方release notes。2.2 解压编译安装三步走下载完成后解压并进入源码目录tar -xzf redis-7.2.5.tar.gz cd redis-7.2.5然后是核心三步第一步编译make -j$(nproc)-j$(nproc)表示用机器所有的CPU核心并行编译速度能快不少。如果编译过程中报jemalloc相关错误直接用下面这条跳过jemalloc改用系统自带的libc内存分配器make MALLOClibc -j$(nproc)第二步安装指定PREFIX把Redis装进统一目录make install PREFIX/usr/local/redis很多教程这一步直接裸跑make install执行完Redis会装到/usr/local/bin下面。我建议都加上PREFIX/usr/local/redis这样做的好处是将来想卸载一个rm -rf /usr/local/redis就彻底干净了所有文件都在一个目录里不会散落在系统各处。第三步布置目录结构mkdir -p /usr/local/redis/{etc,data,logs} cp redis.conf /usr/local/redis/etc/我习惯把配置、数据、日志分三个目录放后面调整权限和备份都方便。etc放配置文件data放持久化文件logs放日志。这个习惯帮我避过很多次“找持久化文件找不到”的尴尬。2.3 装完以后先检查一下装完先看一眼目录ls -l /usr/local/redis/bin正常情况下会有 redis-server、redis-cli、redis-benchmark、redis-check-aof、redis-check-rdb 这几个程序。再看一下版本/usr/local/redis/bin/redis-cli --version能输出版本号说明编译安装已经成功了。接下来就是启动环节。3. Redis三种启动方式逐一拆解3.1 前台启动适合调试一关终端就停最简单的启动方式直接执行/usr/local/redis/bin/redis-server不带任何配置文件启动Redis会使用内置的默认配置日志直接打印在终端上。你会看到经典的启动画面和一行“Ready to accept connections tcp”之类的提示。这种方式信息最直观启动过程和报错都在眼前调试阶段用非常合适。但它有两个明显问题第一终端一旦关闭Redis就跟着停止第二前台启动占用当前终端你没法同时干别的。所以这种方式基本只适合验证安装是否成功或者排查启动报错。还有一种情况是你手上只有编译后的二进制、没有配置文件临时想指定端口启动/usr/local/redis/bin/redis-server --port 6380这也可以跑但所有参数都是临时生效重启后失效。真要长期运行还得回到配置文件。3.2 后台守护进程启动让Redis自己悄悄跑日常运维中用的最多的还是后台启动。所谓后台启动核心就是配置里的daemonize参数。打开配置文件vim /usr/local/redis/etc/redis.conf找到并修改这两个参数daemonize yes logfile /usr/local/redis/logs/redis.logdaemonize yes表示Redis启动后自动进入后台守护进程模式。父进程启动后fork出子进程然后父进程退出由子进程提供服务。logfile指定日志输出位置不设置的话后台模式下日志会跑到/var/log/redis/redis.log或者直接丢到/dev/null排查问题的时候非常难受。然后执行/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf这次启动命令很快返回终端恢复到提示符状态。此时Redis已经在后台跑起来了。验证方式/usr/local/redis/bin/redis-cli ping如果返回PONG说明服务正常。也可以看日志tail -f /usr/local/redis/logs/redis.log后台启动的优点是不占用终端关闭SSH连接Redis也会继续运行。这是它和前台启动最本质的区别。缺点是Redis进程脱离终端管理以后怎么停止、怎么开机自启都得你自己手动管理。如果你用systemd来托管也就是下面第三种方式就可以把这些都交给系统管理。3.3 systemd托管启动生产环境的首选方案后台守护进程启动虽然方便但服务器一旦重启Redis并不会自动跟着启动。很多人就是吃了这个亏机房断电重启后服务迟迟起不来还得手动敲命令去拉Redis。生产环境正确的姿势是用systemd托管Redis让它开机自启、崩溃自动重启、日志统一交给journald。我这里直接给出我常用的unit文件写法。先创建一个低权限系统用户避免Redis以root身份运行sudo useradd -r -s /sbin/nologin redis sudo chown -R redis:redis /usr/local/redis然后新建/etc/systemd/system/redis.service[Unit] DescriptionRedis 7.x server Afternetwork.target [Service] Typenotify ExecStart/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf --supervised systemd --daemonize no ExecReload/bin/kill -HUP $MAINPID ExecStop/bin/kill -TERM $MAINPID Userredis Groupredis RuntimeDirectoryredis RuntimeDirectoryMode0755 LimitNOFILE65535 Restarton-failure RestartSec3 [Install] WantedBymulti-user.target这几行配置有几个关键点要讲透第一Typenotify配合--supervised systemd使用。Redis进程启动完成后会通过sd_notify机制主动告诉systemd“我已经就绪了”systemd根据这个状态来判断服务是否启动成功。相比Typeforking加PIDFile的老写法notify方式更干净不会出现“systemd以为服务起来了实际上Redis还在初始化”的竞态问题。第二--daemonize no必须显式传给redis-server。你可能会奇怪既然配置里已经写了daemonize yes为什么命令行还要传no因为如果用systemd来管进程Redis就不应该自己fork到后台去否则systemd会丢失对主进程的掌控服务状态会变得混乱。命令行参数优先级高于配置文件这样写是为了确保systemd能直接管理Redis进程本身。第三Userredis让Redis以低权限用户运行日志和数据目录归属都在/usr/local/redis下面之前设置的chown就是做这个准备的。用root跑Redis会有一个显眼的警告日志更重要的是一旦Redis被攻破攻击者拿到的是root权限这就很危险了。第四LimitNOFILE65535。很多人在高并发场景下会踩到“Too many open files”的报错就是因为系统默认的文件描述符上限是1024而Redis每一条连接都要消耗一个文件描述符。这个参数在unit里一设问题就解决了。创建好unit文件后执行sudo systemctl daemon-reload sudo systemctl enable --now redis sudo systemctl status redisenable --now表示设置开机自启并立刻启动。之后你就用systemctl start redis、systemctl stop redis、systemctl restart redis来控制Redis了跟管理其他系统服务一样自然。如果哪天不想要redis进程了一条命令清干净sudo systemctl disable --now redis这种托管方式我用了很久最大的体会就是“省心”。以前手动管理进程时重启一台服务器要逐个服务手工拉起现在systemd全部接管机器重启后Redis会自动恢复省去了很多半夜救火的操作。4. 启动前必须调好的配置参数4.1 网络与安全相关bind、protected-mode、port、requirepassRedis的配置文件/usr/local/redis/etc/redis.conf中有几个参数直接决定了别人能不能访问你的Redis这几个必须调明白。bind参数控制监听地址。默认配置是bind 127.0.0.1 -::1表示只允许本机连接外部一律拒绝。如果你需要局域网或云服务器外部访问必须改bind 0.0.0.0意思是监听所有网卡。生产环境更稳妥的做法是精确指定内网IP不要裸用0.0.0.0减少暴露面。protected-mode是Redis的保护模式默认值是yes。它的逻辑是当Redis没有设置密码并且绑定了非本机地址时它会拒绝外部连接。很多人在云服务器上装完Redis远程用可视化工具连不上查来查去发现就是protected-mode在“保护”你。如果你确实需要远程访问最合理的方案是设置一个强密码而不是简单粗暴地把保护模式关掉。port参数默认是6379一般不用改。但如果你要在一台机器上跑多个Redis实例每个实例必须有独立的端口比如6380、6381同时每个实例需要单独的配置文件、日志和数据目录。requirepass就是访问密码。我踩过一个真实的坑用命令行参数方式启动redis-server --requirepass mypassword结果后来想改密码用ps aux一查发现密码就明晃晃地出现在进程列表里等于密码裸奔在服务器上。所以密码一定要写在配置文件里并且把配置文件权限收紧chmod 600 /usr/local/redis/etc/redis.conf7.x版本还可以用ACL功能给不同用户分配不同权限这点在多人共用一个Redis场景下非常有用值得花时间看一下官方文档。4.2 日志与持久化logfile、dir、appendonly日志路径我之前已经提过配置文件里这样写logfile /usr/local/redis/logs/redis.logdir参数是我特别想强调的一个坑。它决定持久化文件放在哪个目录默认是Redis启动时所在目录。什么意思呢假如你在/home/user目录下执行redis-server /usr/local/redis/etc/redis.conf那么RDB快照文件dump.rdb就会生成在/home/user下面。等哪天换了启动目录Redis会重新生成一个空的dump.rdb原来那份数据就像“丢了一样”其实它就静静躺在你上次启动时所在的那个目录里。所以务必在配置里固定dir /usr/local/redis/data设置完之后无论从哪里启动持久化文件都只会落在同一个目录。持久化策略上生产环境我建议开启AOF并把RDB保留两者配合使用appendonly yes appendfsync everysec save 900 1 save 300 10 save 60 10000appendonly yes开启AOF日志appendfsync everysec表示每秒把日志刷盘一次兼顾安全性和性能。save系列是RDB快照触发条件比如900秒内至少1次写入就生成一次快照。AOF和RDB同时启用并不冲突Redis在重启时默认优先用AOF恢复数据因为AOF数据更完整。4.3 内存与性能maxmemory和淘汰策略这个参数我在很多初学者的配置里都没看到但它是生产事故的重灾区。maxmemory 4gb maxmemory-policy allkeys-lrumaxmemory限制Redis最大内存maxmemory-policy定义内存满了以后怎么办。allkeys-lru表示对所有键执行LRU淘汰最近最少使用的先被踢掉volatile-lru则只对设置了过期时间的键进行淘汰。如果你只设maxmemory不设淘汰策略默认的noeviction策略会让所有写操作在内存满之后直接报错这会让应用层瞬间出现一堆异常。我经历过一次没设maxmemory引发的宕机一个内部服务Redis数据不断增长到凌晨某时候机器内存打满整台服务器OOM不光是Redis挂了其他进程也跟着遭殃。那次之后我把所有Redis实例都强制加上maxmemory再配合监控报警内存类问题基本没再捅过娄子。还有一个启动时经常出现的警告说overcommit_memory是0这个参数影响Redis在后台执行BGSAVE时的内存申请策略建议按提示设置成1echo vm.overcommit_memory 1 /etc/sysctl.conf sysctl -p另外tcp-backlog默认511但如果系统内核参数somaxconn小于这个值启动时会有报警可以顺带调大echo net.core.somaxconn 1024 /etc/sysctl.conf sysctl -p5. 启动失败排查实录那些常见的坑5.1 编译报错gcc版本太低和jemalloc缺失编译阶段最典型的报错我在前面提过一半这里把完整的排查思路放出来。如果你在CentOS 7上编译Redis 6.2以上版本gcc 4.8.5不满足要求编译到某个文件时直接报cc1: error: unrecognized command line option之类的语法错误。解决办法是升级编译器SCL那套命令前面给过不再赘述。升级后务必先执行make distclean然后再重新make。我见过有人升级了gcc还是不停地报错最后发现是旧编译产物残留导致的。还有一个经典报错是MALLOC: jemalloc not found这是因为Redis源码默认使用jemalloc作为内存分配器但系统缺少相关的jemalloc依赖。解决办法是执行make MALLOClibc用系统标准的libc分配器替代。虽然jemalloc在某些场景下内存碎片控制更好但先能把服务跑起来更重要尤其在你只是为了验证功能时。5.2 远程连不上bind、保护模式和防火墙一个都不能少本机Redis正常远程就是连不上这个问题的排查是有固定套路的我按步骤给你捋一遍。第一步本机验证服务活着/usr/local/redis/bin/redis-cli -h 127.0.0.1 ping返回PONG说明Redis本身没问题问题出在访问路径上。第二步检查bind配置grep ^bind /usr/local/redis/etc/redis.conf默认是bind 127.0.0.1 -::1这就解释了为什么远程连不上。改成实际内网IP或0.0.0.0重启redis。第三步看protected-mode和requirepass。如果没设密码而bind已经改成了非本机地址protected-mode会直接拒绝远程连接并提示你需要设置密码。这时候最稳妥的做法是设一个密码而不是关掉保护模式。第四步查防火墙。CentOS上sudo firewall-cmd --list-all确认6379端口是否放行没有就加上sudo firewall-cmd --permanent --add-port6379/tcp sudo firewall-cmd --reloadUbuntu上可能使用ufwsudo ufw allow 6379/tcp还有个特别容易忽略的如果你用的是云服务器云厂商的安全组规则里也要放行6379端口。我遇到过好几回服务器本地全部正常防火墙也放行了最后发现是安全组那边没配这就真的很憋屈了。5.3 启动成功但状态不对日志、权限和进程管理如果你用systemd启动后查看状态是失败先别慌看日志是最好的入口sudo systemctl status redis sudo journalctl -u redis -n 50常见的失败原因是权限问题。比如日志写到/usr/local/redis/logs/redis.log提示Permission denied那是因为redis用户对这个目录没有写权限。解决sudo chown -R redis:redis /usr/local/redis另一个坑是启动后发现日志里提示Cant open the log file但配置文件里logfile路径明明是存在的。这多半是配置文件目录本身权限不对同样用chown收尾。还有一种是端口冲突。明明启动命令执行了但redis-cli ping不通先看进程ps -ef | grep redis-server如果发现好几个redis-server同时在跑可能是之前遗留了老进程占用端口新进程启动失败。处理办法是找到占用6379端口的进程确认后停掉sudo lsof -i :6379最后再强调一个关闭Redis的安全习惯。不要随手kill -9除非服务真的卡死。优雅关闭应该用redis-cli shutdown saveshutdown save会先做一次RDB持久化再退出最大限度保证数据不丢。如果明确不想保存用shutdown nosave。这俩命令比kill -9稳得多养成习惯对你日志的完整性也有好处。6. 我踩过几次坑之后的几点体会说句实在话Redis本身不太挑环境真正让人头疼的从来都不是编译那一下而是启动方式和数据路径没有提前想清楚。我把自己的经验浓缩成一句话生产环境直接用systemd托管daemonize no加--supervised systemd数据目录固定、日志目录固定、内存上限固定这三个固定做好Redis这台小马车基本就不会撂挑子。最后再分享一个小技巧也是我现在操作任何Redis节点都保留的习惯无论用哪种方式启动启动完第一件事就是敲一遍redis-cli -p 6379 ping看到PONG再离开终端。这个动作只用一秒钟但能帮你躲过至少一半“以为启动成功实际上端口被占用或配置出问题”的尴尬。先验证后离手做运维也好做开发也好这个习惯都能让你省心不少。
