1. 动手之前先弄清楚Redis到底解决了什么问题我在日常工作中见过太多人一上来就敲yum install redis装完跑起来就算完事结果过两星期线上出问题连日志都不知道去哪看。安装Redis本身不复杂但如果你不清楚自己为什么要装、装哪种版本、用哪种方式装后面踩坑的成本会远高于那几分钟的安装时间。Redis是一个基于内存的键值型数据库常被用作缓存、分布式锁、消息队列的轻量实现、排行榜服务、会话存储等等。它的核心优势是快——单实例QPS能轻松跑到十万级别数据存放在内存里同时支持RDB和AOF两种持久化机制保证重启后数据不丢。这些特性让它在后端架构里几乎是标配组件。这篇教程适合谁刚接触Linux服务部署的同学、准备在本地或测试环境搭一套Redis做开发的工程师以及那些已经装过但每次都用默认配置、从来没研究过启动方式和开机自启的“半吊子”使用者。我会把从环境准备到配置调优再到问题排查的完整链路走一遍所有命令都标注了作用和执行时机你照着做就能跑起来同时也能理解每一步背后的逻辑。需要说明的是我下面所有操作都在某台基于Debian系的干净Linux服务器上演示不过涉及的核心命令在绝大多数主流发行版上都通用个别包管理器差异我会专门标注。2. 安装前的三件事环境、版本、方式2.1 确认你的Linux环境安装Redis之前先明确几件事。如果你用的是云服务器确认操作系统位数是64位——Redis官方早就不提供32位的正式支持了虽然源码理论上能编但我不建议你在生产环境尝试。查看命令uname -m # 输出 x86_64 表示64位aarch64 表示ARM64都没问题接着确认有没有编译工具链因为后面源码安装方式需要用到gcc和make。如果用的是CentOS/RHEL系sudo yum install -y gcc makeDebian/Ubuntu系则用sudo apt-get install -y build-essential还有一个容易忽视的点Redis对系统参数有要求它默认使用epoll事件驱动模型在高并发场景下受文件描述符数量限制。我的建议是装完正式使用前调大系统的vm.overcommit_memory和单进程文件描述符上限这些我在第4章会细讲。2.2 版本选择的原则很多教程会让你直接apt install redis-server然后告诉你完事了。我不否认这是最快的方式但如果你用过几次就会发现发行版仓库里的Redis版本往往滞后于官方最新稳定版一两年甚至更久。这带来的直接问题是新特性用不上更关键的是部分已知安全漏洞和性能优化无法及时覆盖。我的建议是分场景选择生产环境下载官方稳定版源码自行编译或者使用官方提供的二进制发布包。这样能完全掌控版本和编译参数。测试/学习环境用系统包管理器安装完全没问题省时省力。容器环境直接用官方维护的镜像但注意镜像版本也需要你主动更新跟踪。当前主线稳定版的版本号规律是奇数为开发版不稳定偶数为稳定版。比如某个时候的稳定版可能是7.x系列不要看到新版本号就追稳定优先。2.3 三种安装方式的取舍我在实际项目里用过全部三种方式给你一个客观的对比视角安装方式优点缺点适用场景包管理器安装命令少、快、自动处理依赖版本旧、目录结构分散、难以定制学习、快速验证源码编译安装版本可控、可定制编译参数、目录统一编译耗时长、需要工具链生产环境、特殊需求二进制发布包免编译、版本新、解压即用需要手动配置环境变量生产环境、运维自动化我下面重点演示源码编译安装因为这种方式能让你真正理解Redis的目录结构、启动流程和配置逻辑换一台机器或者遇到问题你知道去哪找答案而不是只会执行命令。3. 源码编译安装Redis全流程实录3.1 下载与解压先去Redis官网获取最新稳定版的下载链接或者直接用固定镜像站路径。我习惯于把源码放在/usr/local/src下和编译安装的最终目录/usr/local/redis区分开。cd /usr/local/src wget https://download.redis.io/releases/redis-7.2.4.tar.gz tar -xzf redis-7.2.4.tar.gz cd redis-7.2.4这里的7.2.4只是演示时的具体版本号你实际操作时请到官网或镜像站查看当前的稳定版本号再替换。下载后建议核对一下SHA256校验值官网每个发布包旁边都附了哈希值执行sha256sum redis-7.2.4.tar.gz对比一下防止下载损坏或被篡改。我见过有人跳过校验结果编译到一半报各种莫名其妙的错误最后发现是压缩包没下载完整。这个习惯强烈建议养成。3.2 编译与安装目录规划Redis的源码编译不像某些项目需要额外配置它自带Makefile直接执行make这里你可以先不急着make install观察编译过程有没有报错。编译完成后会在src/目录下生成redis-server、redis-cli、redis-benchmark、redis-check-rdb、redis-check-aof这几个核心可执行文件。你可以先跑一下./src/redis-server --version看到版本信息说明编译成功。make install默认会把可执行文件拷贝到/usr/local/bin下但我不建议这么干。我更推荐的方式是定义安装根目录让所有Redis相关文件集中存放make PREFIX/usr/local/redis install执行完后Redis的可执行文件会被放到/usr/local/redis/bin下。这种做法的好处是卸载时直接删掉这个目录就行不会在系统里留下散落的文件备份和迁移时拷整个目录即可。提示PREFIX指定的是安装根目录可执行文件默认放在PREFIX/bin下。这个参数是Makefile约定的标准用法很多开源软件都遵循这个规则。3.3 初始化目录结构编译安装完成后Redis不会替你创建数据目录、日志目录和配置文件目录你需要自己规划。这是我生产环境的使用习惯mkdir -p /usr/local/redis/{bin,conf,data,logs} cp /usr/local/src/redis-7.2.4/redis.conf /usr/local/redis/conf/目录含义bin可执行文件安装时已自动生成conf存放redis.conf配置data存放RDB持久化快照和AOF重写日志logs存放运行日志配置文件在源码包的根目录下是一个带大量注释和默认参数的模板拷到conf目录后我们再针对性修改。把源码目录和安装目录分开源码可以随时删掉但配置和数据都在安装目录里一目了然。3.4 创建一个不用于登录的系统用户安全底线。Redis官方文档也明确建议不要用root运行Redis服务。因为Redis本身存在远程命令执行的攻击面一旦被利用root权限会让攻击者直接拿下整个服务器。单独创建一个无登录权限的系统用户useradd -s /sbin/nologin -M redis参数说明-s /sbin/nologin禁止这个用户交互式登录shell-M不创建家目录。之后把安装目录和日志、数据目录的所有权交给这个用户chown -R redis:redis /usr/local/redis从这步开始后续所有Redis进程都以redis用户身份运行而不是root。4. 核心配置文件详解别再用默认配置跑生产4.1 必须修改的基础项Redis启动时不带配置文件也能运行但那用的是内置默认参数通常是protected-mode yes、bind 127.0.0.1、不开启持久化。这种状态当玩具可以但只能本地访问重启数据就丢。我们用刚才拷贝的/usr/local/redis/conf/redis.conf做修改。打开配置文件逐一调整以下参数# 绑定的监听地址默认127.0.0.1只能本机访问 # 如果本机只有一个内网IP直接指定它如果有多个网卡用空格分隔 bind 0.0.0.0 # 保护模式生产环境建议开启 protected-mode yes # 监听端口 port 6379 # 以后台守护进程方式运行 daemonize yes # 进程PID保存位置 pidfile /usr/local/redis/run/redis_6379.pid # 日志级别和输出位置 loglevel notice logfile /usr/local/redis/logs/redis_6379.log # 数据持久化目录 dir /usr/local/redis/data这里面bind 0.0.0.0意味着监听所有网卡接口如果你只需要内网访问而服务器同时有公网IP那么建议只绑定内网IP例如bind 192.168.1.100。这是防止把Redis直接暴露到公网的重要防线搭配protected-mode yes双重保险。daemonize yes让Redis以后台守护进程方式运行终端关闭后进程继续存活。你也可以选择保持daemonize no然后用systemd托管由systemd负责后台化这条路径我在第5章讲。4.2 内存管理参数设置Redis是内存数据库内存管理参数直接决定它能存多少数据、什么时候开始淘汰旧数据# 最大可用内存根据机器实际情况调整 maxmemory 2gb # 内存淘汰策略 maxmemory-policy allkeys-lrumaxmemory一旦设置Redis会在内存使用超过阈值后按照maxmemory-policy定义的策略清理数据。常用的策略有几种noeviction不淘汰写入直接报错。适合必须保证所有key都在的场景。allkeys-lru对所有key按LRU最近最少使用淘汰。最常用适合缓存场景。volatile-lru只对设置了过期时间的key做LRU淘汰。适合混合场景。allkeys-random随机淘汰适合数据访问频率均匀的场景。我的经验是纯缓存场景用allkeys-lru有持久化和强一致需求的场景用noeviction或volatile-lru具体取决于你的业务能不能容忍数据丢失。4.3 持久化配置RDB与AOF如何抉择这是很多人容易忽略的配置。Redis默认开启RDB快照在save条件满足时生成快照文件AOF默认关闭需要手动开启。RDB相关配置save 900 1 save 300 10 save 60 10000含义是900秒内至少有1个key变更、300秒内至少有10个key变更、60秒内至少有10000个key变更满足任意一条就触发快照生成。这是性能和数据安全之间的折中方案但RDB的缺点是最后一次快照后的数据可能丢失。AOF配置appendonly yes appendfilename appendonly.aof appendfsync everysecappendfsync有三个选项always每次写操作都同步刷盘最安全但性能最差everysec每秒刷一次性能和数据安全的平衡点no交给操作系统决定刷盘时机最快但丢数据风险最大我几乎总是选择everysec这是官方推荐也是工业界共识。生产环境建议RDB和AOF同时开启Redis重启时会优先用AOF恢复数据因为AOF默认记录更完整。提示如果你对数据一致性要求极高比如用Redis存秒杀库存、订单状态可以临时把appendfsync调到always但你要清楚这意味着写入性能可能下降一个数量级。全盘always在生产上我做过对比写QPS能从10万掉到一两万不是所有业务都承受得了。4.4 安全相关的访问密码不要觉得内网就安全。我见过很多内网Redis被扫描爆破的案例一旦沦陷攻击者写入crontab反弹shell是分分钟的事。设置密码是基本操作requirepass YourStrongPassword设置后客户端连接时需要执行AUTH YourStrongPassword或者连接时带密码参数redis-cli -a YourStrongPassword要注意用-a传密码会在命令行历史里留下明文痕迹shell的history文件里能翻到。更妥帖的方式是连接后用AUTH命令交互输入或者设置环境变量引用。另外密码别写在业务代码的仓库里建议通过配置中心或环境变量注入。4.5 系统内核参数优化Redis官方文档提到两个关键内核参数不调的话高并发下能见到坑。一是内存分配策略vim /etc/sysctl.conf # 添加如下内容 vm.overcommit_memory 1然后sysctl -p生效。为什么Redis提供bgsave后台持久化它依赖fork()创建子进程而fork时子进程会复制父进程的内存页表。如果系统内存分配策略设置为0启发式拒绝当内存已用较多时fork可能直接失败bgsave无法执行数据持久化中断。设置为1表示内核永远允许超量分配内存让fork在内存紧张时也能成功。代价是系统可能因内存不足触发OOM Killer但Redis的守护进程本身内存占用相对可控配合maxmemory参数风险是可控的。二是禁用内存透明大页THPecho never /sys/kernel/mm/transparent_hugepage/enabledRedis官方明确建议关闭THP因为THP会导致fork时内存页合并操作变慢产生延迟毛刺卡顿并且增加内存开销。很多人在压测时发现Redis响应时间偶尔飙到几十毫秒排查半天最后发现是THP的锅。另外调整文件描述符上限。默认是1024Redis这种高并发服务根本不够用打开/etc/security/limits.conf添加redis hard nofile 100000 redis soft nofile 100000注意这是针对redis用户的替redis用户设置进程级可打开文件数上限。5. 启动与验证从前台到systemd托管5.1 手动启动验证配置正确性第一次启动建议用前台模式这样日志能直接打在终端上方便排查配置错误cd /usr/local/redis ./bin/redis-server conf/redis.conf如果配置有误会当场报错告诉你哪一行有问题。最常见的报错是配置文件里的目录不存在比如我前面提到的pidfile指向的run目录还没创建。遇到这种报错就回到第3.3步补建目录再给redis用户授权。确认没问题后按CtrlC停掉改用后台模式./bin/redis-server conf/redis.conf查看进程ps -ef | grep redis如果看到类似redis-server 0.0.0.0:6379的进程说明已经跑起来了。5.2 用redis-cli验证读写Redis自带的命令行客户端是最直接的验证工具./bin/redis-cli 127.0.0.1:6379 ping PONG输出PONG代表服务正常。再测一下密码认证和读写./bin/redis-cli -a YourStrongPassword 127.0.0.1:6379 set mykey hello OK 127.0.0.1:6379 get mykey hello数据能写入能读出说明配置生效。这里建议顺手在配置文件里给key设置一个过期时间验证一下127.0.0.1:6379 set session_token abc123 EX 60 OK 127.0.0.1:6379 ttl session_token (integer) 58TTL显示剩余秒数说明过期机制正常工作。5.3 验证持久化是否生效这是最容易忽略的一步。写入数据后触发一次bgsave./bin/redis-cli -a YourStrongPassword bgsave看到Background saving started后检查data目录ls -l /usr/local/redis/data/正常情况下会看到dump.rdb文件生成。然后故意重启一下Redis进程./bin/redis-cli -a YourStrongPassword shutdown ./bin/redis-server conf/redis.conf ./bin/redis-cli -a YourStrongPassword get mykey如果能重新读到hello说明RDB持久化工作正常。这一步在安装阶段花两分钟做完后面能省一大笔排查时间。5.4 把Redis托管给systemd实现开机自启每次重启服务器后要手动执行redis-server是很原始的玩法。生产环境建议写一个systemd服务单元文件把Redis纳入系统服务管理实现开机自启、异常退出自动拉起、统一日志管理。创建/etc/systemd/system/redis.service[Unit] DescriptionRedis In-Memory Data Store Afternetwork.target [Service] Userredis Groupredis Typeforking ExecStart/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf ExecReload/bin/kill -USR2 $MAINPID ExecStop/bin/kill -TERM $MAINPID PIDFile/usr/local/redis/run/redis_6379.pid Restartalways RestartSec3 LimitNOFILE100000 [Install] WantedBymulti-user.target注意几个细节Typeforking对应配置文件里的daemonize yessystemd需要知道主进程fork到后台后PID变化因此要配合PIDFile参数。Userredis和Groupredis指定运行用户配合前面创建的系统用户。Restartalways让服务异常退出后systemd自动拉起RestartSec3是重启间隔3秒。启用服务systemctl daemon-reload systemctl enable redis systemctl start redis systemctl status redisstatus输出显示active (running)就成功了。此后服务器的日常管理通过systemctl start/stop/restart/status redis完成这和手动执行redis-cli shutdown是等价的推荐统一用systemd。6. 常见安装与启动问题排查实录6.1 编译阶段常见问题问题一make时提示gcc命令找不到这是环境里没装编译工具链。Debian系执行apt-get install -y build-essentialCentOS/RHEL系执行yum install -y gcc make装完重新make。问题二make报错与jemalloc相关完整报错信息类似“You need tcl 8.5 or newer in order to run the Redis test suite”这个不太影响编译主体但如果你执行的是make test才会触发。只在源码目录用make编译可执行文件不需要tcl。还有个常见的情况是MALLOCjemallocRedis编译时默认采用jemalloc内存分配器某些老版本的glibc环境下会报错。这种场景可以指定使用libc替代make MALLOClibc我遇到过一台老系统上jemalloc编译失败的情况改用libc后一切正常。不过生产上如果条件允许还是尽量保留jemalloc它的内存碎片控制比libc的malloc更好长时间运行下优势明显。问题三make test阶段失败如果你之后想跑测试套件验证Redis功能完整性需要先安装tcl再执行make test。测试跑完通常输出一堆PASS不用全看关注最后的汇总行里有没有FAIL即可。6.2 启动阶段常见问题问题一启动后立即退出且日志无输出这种情况往往是配置里指向的目录或者文件没有权限。查看配置里pidfile、dir、logfile指向的路径是否存在并且redis用户是否有权限读写。执行# 检查目录权限 ls -ld /usr/local/redis/conf /usr/local/redis/data /usr/local/redis/logs # 如果归属还是root重新授权 chown -R redis:redis /usr/local/redis问题二远程连接被拒绝redis-cli -h 服务器IP ping超时或提示Connection refused。排查顺序先看6379端口是否在监听ss -lntp | grep 6379再看防火墙云服务器安全组可能没放行6379端口最后确认redis.conf里的bind是否包含客户端能访问到的IP以及protected-mode是否误设为yes导致非本机连接被拒。这里特别提一句如果安全组没有把6379加入白名单即使redis.conf配了bind 0.0.0.0外部仍然无法连接。云服务器场景的端口放行要先到控制台确认再回来排查系统内iptables/firewalld。问题三启动时提示“Cant open the log file”配置文件里的logfile路径不存在或没权限。日志目录需要提前创建并归redis用户所有。不要图省事把日志写到根目录或系统tmp下长期运行日志量大放在Redis自己的logs目录才能配合logrotate做轮转。6.3 运行期常见问题问题一运行一段时间后服务自动挂掉优先查日志tail -100 /usr/local/redis/logs/redis_6379.log最常见的原因是OOM Killer把进程杀了尤其是没设置maxmemory的时候。查看内核日志确认dmesg | tail -20 | grep -i oom解决办法是给redis.conf设置一个合理的maxmemory并配合maxmemory-policy淘汰策略避免内存无限增长。问题二bgsave一直不执行或失败确保第4.5节设置的内核参数生效了没有调整过vm.overcommit_memory的机器fork时会因内存不足失败。另外检查磁盘空间data目录所在磁盘满了RDB文件写入失败会让bgsave静默失败。问题三QPS上不去或延迟不稳定先从配置层面排查确认THP已关闭appendfsync是否是everysec或更低。再用内置的诊断命令./bin/redis-cli --latency -h 127.0.0.1观察返回的延迟数据。如果avg已经达到毫秒级甚至几十毫秒说明系统层面有问题可能是内存、CPU争抢或网络瓶颈。排除自身配置因素后检查同一台机器上是否有其他进程抢占资源。7. 实测下来的几个重要心得装了这么多次Redis踩过不少坑有几条经验值得单独写下来。第一把配置文件的每一行都搞明白再上生产。我的习惯是安装完成后把redis.conf从头到尾过一遍凡是改动过的参数用注释标清楚原因。Redis的默认配置已经相当克制但默认值不会完全符合你的业务。绑定地址、密码、持久化策略、内存上限这四项是底线缺一不可。第二systemd托管和源码目录规划是配套的。你如果用包管理器安装systemd unit文件通常自动生成但这也意味着你失去了目录管理灵活性。源码编译加上自定义systemd unit人工成本就装在第一次后面运维和搬迁的收益远超这点成本。第三Redis安装完不等于交付完。真正的交付标准是服务能开机自启、配置有备份、日志有轮转、监控有告警、数据有验证恢复演练。我在第5章的验证步骤并不是走形式而是每次新环境都必须过的关卡。尤其是持久化验证装完立刻重启一次进程确认数据恢复这个习惯帮我规避过多次“配置了但没生效”的尴尬。这里顺带推荐一个小习惯把安装和配置的关键命令整理成一个shell脚本放到项目文档里下次换机器直接跑比翻聊天记录、翻博客效率高得多。脚本里记得用参数占位符标注密码和IP别图省事明文写死。Redis的安装只是起步后续的监控、调优、集群化都是大话题。但底子打好了这些进阶工作才能站得住脚。希望这篇教程能帮你少走一些弯路有任何在安装过程中遇到的具体报错欢迎在评论区带上环境信息和报错截图我看到后会结合实操经验帮你一起排查。
1. 动手之前先弄清楚Redis到底解决了什么问题我在日常工作中见过太多人一上来就敲yum install redis装完跑起来就算完事结果过两星期线上出问题连日志都不知道去哪看。安装Redis本身不复杂但如果你不清楚自己为什么要装、装哪种版本、用哪种方式装后面踩坑的成本会远高于那几分钟的安装时间。Redis是一个基于内存的键值型数据库常被用作缓存、分布式锁、消息队列的轻量实现、排行榜服务、会话存储等等。它的核心优势是快——单实例QPS能轻松跑到十万级别数据存放在内存里同时支持RDB和AOF两种持久化机制保证重启后数据不丢。这些特性让它在后端架构里几乎是标配组件。这篇教程适合谁刚接触Linux服务部署的同学、准备在本地或测试环境搭一套Redis做开发的工程师以及那些已经装过但每次都用默认配置、从来没研究过启动方式和开机自启的“半吊子”使用者。我会把从环境准备到配置调优再到问题排查的完整链路走一遍所有命令都标注了作用和执行时机你照着做就能跑起来同时也能理解每一步背后的逻辑。需要说明的是我下面所有操作都在某台基于Debian系的干净Linux服务器上演示不过涉及的核心命令在绝大多数主流发行版上都通用个别包管理器差异我会专门标注。2. 安装前的三件事环境、版本、方式2.1 确认你的Linux环境安装Redis之前先明确几件事。如果你用的是云服务器确认操作系统位数是64位——Redis官方早就不提供32位的正式支持了虽然源码理论上能编但我不建议你在生产环境尝试。查看命令uname -m # 输出 x86_64 表示64位aarch64 表示ARM64都没问题接着确认有没有编译工具链因为后面源码安装方式需要用到gcc和make。如果用的是CentOS/RHEL系sudo yum install -y gcc makeDebian/Ubuntu系则用sudo apt-get install -y build-essential还有一个容易忽视的点Redis对系统参数有要求它默认使用epoll事件驱动模型在高并发场景下受文件描述符数量限制。我的建议是装完正式使用前调大系统的vm.overcommit_memory和单进程文件描述符上限这些我在第4章会细讲。2.2 版本选择的原则很多教程会让你直接apt install redis-server然后告诉你完事了。我不否认这是最快的方式但如果你用过几次就会发现发行版仓库里的Redis版本往往滞后于官方最新稳定版一两年甚至更久。这带来的直接问题是新特性用不上更关键的是部分已知安全漏洞和性能优化无法及时覆盖。我的建议是分场景选择生产环境下载官方稳定版源码自行编译或者使用官方提供的二进制发布包。这样能完全掌控版本和编译参数。测试/学习环境用系统包管理器安装完全没问题省时省力。容器环境直接用官方维护的镜像但注意镜像版本也需要你主动更新跟踪。当前主线稳定版的版本号规律是奇数为开发版不稳定偶数为稳定版。比如某个时候的稳定版可能是7.x系列不要看到新版本号就追稳定优先。2.3 三种安装方式的取舍我在实际项目里用过全部三种方式给你一个客观的对比视角安装方式优点缺点适用场景包管理器安装命令少、快、自动处理依赖版本旧、目录结构分散、难以定制学习、快速验证源码编译安装版本可控、可定制编译参数、目录统一编译耗时长、需要工具链生产环境、特殊需求二进制发布包免编译、版本新、解压即用需要手动配置环境变量生产环境、运维自动化我下面重点演示源码编译安装因为这种方式能让你真正理解Redis的目录结构、启动流程和配置逻辑换一台机器或者遇到问题你知道去哪找答案而不是只会执行命令。3. 源码编译安装Redis全流程实录3.1 下载与解压先去Redis官网获取最新稳定版的下载链接或者直接用固定镜像站路径。我习惯于把源码放在/usr/local/src下和编译安装的最终目录/usr/local/redis区分开。cd /usr/local/src wget https://download.redis.io/releases/redis-7.2.4.tar.gz tar -xzf redis-7.2.4.tar.gz cd redis-7.2.4这里的7.2.4只是演示时的具体版本号你实际操作时请到官网或镜像站查看当前的稳定版本号再替换。下载后建议核对一下SHA256校验值官网每个发布包旁边都附了哈希值执行sha256sum redis-7.2.4.tar.gz对比一下防止下载损坏或被篡改。我见过有人跳过校验结果编译到一半报各种莫名其妙的错误最后发现是压缩包没下载完整。这个习惯强烈建议养成。3.2 编译与安装目录规划Redis的源码编译不像某些项目需要额外配置它自带Makefile直接执行make这里你可以先不急着make install观察编译过程有没有报错。编译完成后会在src/目录下生成redis-server、redis-cli、redis-benchmark、redis-check-rdb、redis-check-aof这几个核心可执行文件。你可以先跑一下./src/redis-server --version看到版本信息说明编译成功。make install默认会把可执行文件拷贝到/usr/local/bin下但我不建议这么干。我更推荐的方式是定义安装根目录让所有Redis相关文件集中存放make PREFIX/usr/local/redis install执行完后Redis的可执行文件会被放到/usr/local/redis/bin下。这种做法的好处是卸载时直接删掉这个目录就行不会在系统里留下散落的文件备份和迁移时拷整个目录即可。提示PREFIX指定的是安装根目录可执行文件默认放在PREFIX/bin下。这个参数是Makefile约定的标准用法很多开源软件都遵循这个规则。3.3 初始化目录结构编译安装完成后Redis不会替你创建数据目录、日志目录和配置文件目录你需要自己规划。这是我生产环境的使用习惯mkdir -p /usr/local/redis/{bin,conf,data,logs} cp /usr/local/src/redis-7.2.4/redis.conf /usr/local/redis/conf/目录含义bin可执行文件安装时已自动生成conf存放redis.conf配置data存放RDB持久化快照和AOF重写日志logs存放运行日志配置文件在源码包的根目录下是一个带大量注释和默认参数的模板拷到conf目录后我们再针对性修改。把源码目录和安装目录分开源码可以随时删掉但配置和数据都在安装目录里一目了然。3.4 创建一个不用于登录的系统用户安全底线。Redis官方文档也明确建议不要用root运行Redis服务。因为Redis本身存在远程命令执行的攻击面一旦被利用root权限会让攻击者直接拿下整个服务器。单独创建一个无登录权限的系统用户useradd -s /sbin/nologin -M redis参数说明-s /sbin/nologin禁止这个用户交互式登录shell-M不创建家目录。之后把安装目录和日志、数据目录的所有权交给这个用户chown -R redis:redis /usr/local/redis从这步开始后续所有Redis进程都以redis用户身份运行而不是root。4. 核心配置文件详解别再用默认配置跑生产4.1 必须修改的基础项Redis启动时不带配置文件也能运行但那用的是内置默认参数通常是protected-mode yes、bind 127.0.0.1、不开启持久化。这种状态当玩具可以但只能本地访问重启数据就丢。我们用刚才拷贝的/usr/local/redis/conf/redis.conf做修改。打开配置文件逐一调整以下参数# 绑定的监听地址默认127.0.0.1只能本机访问 # 如果本机只有一个内网IP直接指定它如果有多个网卡用空格分隔 bind 0.0.0.0 # 保护模式生产环境建议开启 protected-mode yes # 监听端口 port 6379 # 以后台守护进程方式运行 daemonize yes # 进程PID保存位置 pidfile /usr/local/redis/run/redis_6379.pid # 日志级别和输出位置 loglevel notice logfile /usr/local/redis/logs/redis_6379.log # 数据持久化目录 dir /usr/local/redis/data这里面bind 0.0.0.0意味着监听所有网卡接口如果你只需要内网访问而服务器同时有公网IP那么建议只绑定内网IP例如bind 192.168.1.100。这是防止把Redis直接暴露到公网的重要防线搭配protected-mode yes双重保险。daemonize yes让Redis以后台守护进程方式运行终端关闭后进程继续存活。你也可以选择保持daemonize no然后用systemd托管由systemd负责后台化这条路径我在第5章讲。4.2 内存管理参数设置Redis是内存数据库内存管理参数直接决定它能存多少数据、什么时候开始淘汰旧数据# 最大可用内存根据机器实际情况调整 maxmemory 2gb # 内存淘汰策略 maxmemory-policy allkeys-lrumaxmemory一旦设置Redis会在内存使用超过阈值后按照maxmemory-policy定义的策略清理数据。常用的策略有几种noeviction不淘汰写入直接报错。适合必须保证所有key都在的场景。allkeys-lru对所有key按LRU最近最少使用淘汰。最常用适合缓存场景。volatile-lru只对设置了过期时间的key做LRU淘汰。适合混合场景。allkeys-random随机淘汰适合数据访问频率均匀的场景。我的经验是纯缓存场景用allkeys-lru有持久化和强一致需求的场景用noeviction或volatile-lru具体取决于你的业务能不能容忍数据丢失。4.3 持久化配置RDB与AOF如何抉择这是很多人容易忽略的配置。Redis默认开启RDB快照在save条件满足时生成快照文件AOF默认关闭需要手动开启。RDB相关配置save 900 1 save 300 10 save 60 10000含义是900秒内至少有1个key变更、300秒内至少有10个key变更、60秒内至少有10000个key变更满足任意一条就触发快照生成。这是性能和数据安全之间的折中方案但RDB的缺点是最后一次快照后的数据可能丢失。AOF配置appendonly yes appendfilename appendonly.aof appendfsync everysecappendfsync有三个选项always每次写操作都同步刷盘最安全但性能最差everysec每秒刷一次性能和数据安全的平衡点no交给操作系统决定刷盘时机最快但丢数据风险最大我几乎总是选择everysec这是官方推荐也是工业界共识。生产环境建议RDB和AOF同时开启Redis重启时会优先用AOF恢复数据因为AOF默认记录更完整。提示如果你对数据一致性要求极高比如用Redis存秒杀库存、订单状态可以临时把appendfsync调到always但你要清楚这意味着写入性能可能下降一个数量级。全盘always在生产上我做过对比写QPS能从10万掉到一两万不是所有业务都承受得了。4.4 安全相关的访问密码不要觉得内网就安全。我见过很多内网Redis被扫描爆破的案例一旦沦陷攻击者写入crontab反弹shell是分分钟的事。设置密码是基本操作requirepass YourStrongPassword设置后客户端连接时需要执行AUTH YourStrongPassword或者连接时带密码参数redis-cli -a YourStrongPassword要注意用-a传密码会在命令行历史里留下明文痕迹shell的history文件里能翻到。更妥帖的方式是连接后用AUTH命令交互输入或者设置环境变量引用。另外密码别写在业务代码的仓库里建议通过配置中心或环境变量注入。4.5 系统内核参数优化Redis官方文档提到两个关键内核参数不调的话高并发下能见到坑。一是内存分配策略vim /etc/sysctl.conf # 添加如下内容 vm.overcommit_memory 1然后sysctl -p生效。为什么Redis提供bgsave后台持久化它依赖fork()创建子进程而fork时子进程会复制父进程的内存页表。如果系统内存分配策略设置为0启发式拒绝当内存已用较多时fork可能直接失败bgsave无法执行数据持久化中断。设置为1表示内核永远允许超量分配内存让fork在内存紧张时也能成功。代价是系统可能因内存不足触发OOM Killer但Redis的守护进程本身内存占用相对可控配合maxmemory参数风险是可控的。二是禁用内存透明大页THPecho never /sys/kernel/mm/transparent_hugepage/enabledRedis官方明确建议关闭THP因为THP会导致fork时内存页合并操作变慢产生延迟毛刺卡顿并且增加内存开销。很多人在压测时发现Redis响应时间偶尔飙到几十毫秒排查半天最后发现是THP的锅。另外调整文件描述符上限。默认是1024Redis这种高并发服务根本不够用打开/etc/security/limits.conf添加redis hard nofile 100000 redis soft nofile 100000注意这是针对redis用户的替redis用户设置进程级可打开文件数上限。5. 启动与验证从前台到systemd托管5.1 手动启动验证配置正确性第一次启动建议用前台模式这样日志能直接打在终端上方便排查配置错误cd /usr/local/redis ./bin/redis-server conf/redis.conf如果配置有误会当场报错告诉你哪一行有问题。最常见的报错是配置文件里的目录不存在比如我前面提到的pidfile指向的run目录还没创建。遇到这种报错就回到第3.3步补建目录再给redis用户授权。确认没问题后按CtrlC停掉改用后台模式./bin/redis-server conf/redis.conf查看进程ps -ef | grep redis如果看到类似redis-server 0.0.0.0:6379的进程说明已经跑起来了。5.2 用redis-cli验证读写Redis自带的命令行客户端是最直接的验证工具./bin/redis-cli 127.0.0.1:6379 ping PONG输出PONG代表服务正常。再测一下密码认证和读写./bin/redis-cli -a YourStrongPassword 127.0.0.1:6379 set mykey hello OK 127.0.0.1:6379 get mykey hello数据能写入能读出说明配置生效。这里建议顺手在配置文件里给key设置一个过期时间验证一下127.0.0.1:6379 set session_token abc123 EX 60 OK 127.0.0.1:6379 ttl session_token (integer) 58TTL显示剩余秒数说明过期机制正常工作。5.3 验证持久化是否生效这是最容易忽略的一步。写入数据后触发一次bgsave./bin/redis-cli -a YourStrongPassword bgsave看到Background saving started后检查data目录ls -l /usr/local/redis/data/正常情况下会看到dump.rdb文件生成。然后故意重启一下Redis进程./bin/redis-cli -a YourStrongPassword shutdown ./bin/redis-server conf/redis.conf ./bin/redis-cli -a YourStrongPassword get mykey如果能重新读到hello说明RDB持久化工作正常。这一步在安装阶段花两分钟做完后面能省一大笔排查时间。5.4 把Redis托管给systemd实现开机自启每次重启服务器后要手动执行redis-server是很原始的玩法。生产环境建议写一个systemd服务单元文件把Redis纳入系统服务管理实现开机自启、异常退出自动拉起、统一日志管理。创建/etc/systemd/system/redis.service[Unit] DescriptionRedis In-Memory Data Store Afternetwork.target [Service] Userredis Groupredis Typeforking ExecStart/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf ExecReload/bin/kill -USR2 $MAINPID ExecStop/bin/kill -TERM $MAINPID PIDFile/usr/local/redis/run/redis_6379.pid Restartalways RestartSec3 LimitNOFILE100000 [Install] WantedBymulti-user.target注意几个细节Typeforking对应配置文件里的daemonize yessystemd需要知道主进程fork到后台后PID变化因此要配合PIDFile参数。Userredis和Groupredis指定运行用户配合前面创建的系统用户。Restartalways让服务异常退出后systemd自动拉起RestartSec3是重启间隔3秒。启用服务systemctl daemon-reload systemctl enable redis systemctl start redis systemctl status redisstatus输出显示active (running)就成功了。此后服务器的日常管理通过systemctl start/stop/restart/status redis完成这和手动执行redis-cli shutdown是等价的推荐统一用systemd。6. 常见安装与启动问题排查实录6.1 编译阶段常见问题问题一make时提示gcc命令找不到这是环境里没装编译工具链。Debian系执行apt-get install -y build-essentialCentOS/RHEL系执行yum install -y gcc make装完重新make。问题二make报错与jemalloc相关完整报错信息类似“You need tcl 8.5 or newer in order to run the Redis test suite”这个不太影响编译主体但如果你执行的是make test才会触发。只在源码目录用make编译可执行文件不需要tcl。还有个常见的情况是MALLOCjemallocRedis编译时默认采用jemalloc内存分配器某些老版本的glibc环境下会报错。这种场景可以指定使用libc替代make MALLOClibc我遇到过一台老系统上jemalloc编译失败的情况改用libc后一切正常。不过生产上如果条件允许还是尽量保留jemalloc它的内存碎片控制比libc的malloc更好长时间运行下优势明显。问题三make test阶段失败如果你之后想跑测试套件验证Redis功能完整性需要先安装tcl再执行make test。测试跑完通常输出一堆PASS不用全看关注最后的汇总行里有没有FAIL即可。6.2 启动阶段常见问题问题一启动后立即退出且日志无输出这种情况往往是配置里指向的目录或者文件没有权限。查看配置里pidfile、dir、logfile指向的路径是否存在并且redis用户是否有权限读写。执行# 检查目录权限 ls -ld /usr/local/redis/conf /usr/local/redis/data /usr/local/redis/logs # 如果归属还是root重新授权 chown -R redis:redis /usr/local/redis问题二远程连接被拒绝redis-cli -h 服务器IP ping超时或提示Connection refused。排查顺序先看6379端口是否在监听ss -lntp | grep 6379再看防火墙云服务器安全组可能没放行6379端口最后确认redis.conf里的bind是否包含客户端能访问到的IP以及protected-mode是否误设为yes导致非本机连接被拒。这里特别提一句如果安全组没有把6379加入白名单即使redis.conf配了bind 0.0.0.0外部仍然无法连接。云服务器场景的端口放行要先到控制台确认再回来排查系统内iptables/firewalld。问题三启动时提示“Cant open the log file”配置文件里的logfile路径不存在或没权限。日志目录需要提前创建并归redis用户所有。不要图省事把日志写到根目录或系统tmp下长期运行日志量大放在Redis自己的logs目录才能配合logrotate做轮转。6.3 运行期常见问题问题一运行一段时间后服务自动挂掉优先查日志tail -100 /usr/local/redis/logs/redis_6379.log最常见的原因是OOM Killer把进程杀了尤其是没设置maxmemory的时候。查看内核日志确认dmesg | tail -20 | grep -i oom解决办法是给redis.conf设置一个合理的maxmemory并配合maxmemory-policy淘汰策略避免内存无限增长。问题二bgsave一直不执行或失败确保第4.5节设置的内核参数生效了没有调整过vm.overcommit_memory的机器fork时会因内存不足失败。另外检查磁盘空间data目录所在磁盘满了RDB文件写入失败会让bgsave静默失败。问题三QPS上不去或延迟不稳定先从配置层面排查确认THP已关闭appendfsync是否是everysec或更低。再用内置的诊断命令./bin/redis-cli --latency -h 127.0.0.1观察返回的延迟数据。如果avg已经达到毫秒级甚至几十毫秒说明系统层面有问题可能是内存、CPU争抢或网络瓶颈。排除自身配置因素后检查同一台机器上是否有其他进程抢占资源。7. 实测下来的几个重要心得装了这么多次Redis踩过不少坑有几条经验值得单独写下来。第一把配置文件的每一行都搞明白再上生产。我的习惯是安装完成后把redis.conf从头到尾过一遍凡是改动过的参数用注释标清楚原因。Redis的默认配置已经相当克制但默认值不会完全符合你的业务。绑定地址、密码、持久化策略、内存上限这四项是底线缺一不可。第二systemd托管和源码目录规划是配套的。你如果用包管理器安装systemd unit文件通常自动生成但这也意味着你失去了目录管理灵活性。源码编译加上自定义systemd unit人工成本就装在第一次后面运维和搬迁的收益远超这点成本。第三Redis安装完不等于交付完。真正的交付标准是服务能开机自启、配置有备份、日志有轮转、监控有告警、数据有验证恢复演练。我在第5章的验证步骤并不是走形式而是每次新环境都必须过的关卡。尤其是持久化验证装完立刻重启一次进程确认数据恢复这个习惯帮我规避过多次“配置了但没生效”的尴尬。这里顺带推荐一个小习惯把安装和配置的关键命令整理成一个shell脚本放到项目文档里下次换机器直接跑比翻聊天记录、翻博客效率高得多。脚本里记得用参数占位符标注密码和IP别图省事明文写死。Redis的安装只是起步后续的监控、调优、集群化都是大话题。但底子打好了这些进阶工作才能站得住脚。希望这篇教程能帮你少走一些弯路有任何在安装过程中遇到的具体报错欢迎在评论区带上环境信息和报错截图我看到后会结合实操经验帮你一起排查。
