★ FEATURED ARTICLE 做后端开发的朋友应该都听过 Redis 的大名。接口缓存、排行榜、分布式锁、消息队列、限流计数很多场景里它都是那个抗压的角色。这篇文章是 Redis 系列的第一篇先把最基础的下载、安装、启动和简单使用讲透后续再慢慢展开持久化、集群、哨兵这些重头戏。写这篇的初衷很直接。我这些年帮别人排查过很多 Redis 问题也带过不少刚接触后端的同学发现大多数人在第一步就卡住了。有的不知道去哪下载有的装完连不上有的甚至不知道装好之后怎么确认自己在用的这个 Redis 是不是真的能扛业务。与其让这些基础琐事劝退新手不如直接整理一份拿来就能用的环境搭建手册。这篇不会只扔命令我会把为什么要这么装、踩过哪些坑、哪些参数必须改一起讲清楚争取让一个完全没装过 Redis 的人也能照着走完整个过程。1. 动手装 Redis 之前先把这些事想清楚1.1 这套环境要解决什么问题很多人一上来就搜Redis 下载结果下到一个长得像官网的第三方站点要么版本老旧要么捆绑了一堆乱七八糟的东西。所以先把概念理顺Redis 本质上是一个基于内存的键值型数据库它以极低的延迟处理读写请求数据默认存储在内存中也支持按策略持久化到磁盘。装 Redis 就是装一个这样的服务端程序装完之后我们需要用客户端工具连接它、发命令、读写数据。在开始安装之前先明确你这台机器要拿来干什么。如果是本地学习、跑通 demo那随便选一个稳定版本就行优先级是快速可用不用过度纠结。如果是要搭一个能跑业务的服务器就得关注系统兼容性、配置文件调优、内存规划、访问控制这些细节。我见过有人把 Windows 版 Redis 直接搬到生产环境后来遇到并发量上来就频繁重启排查半天才发现是版本和系统适配的问题。所以开头的第一步不是下载而是确认你的场景和平台。1.2 版本选择背后的逻辑Redis 目前的稳定版本迭代很快官方在版本命名上分稳定版和预发布版。普通用户我建议避开 RC 和 beta也不要追最新的大版本。生产环境推荐选用你所在生态里被验证过的成熟版本比如很多云服务商和框架默认对接的版本区间。Redis 在偶数版本和奇数版本之间有个微妙的规律通常偶数为稳定推荐奇数为功能预览。这个规律不完全绝对但可以作为一个选择的参考思路。版本选择还会影响你后续的学习路径。不同版本在数据结构、命令语法、多线程模型、权限管理上有差异。老版本没有 ACL 机制新版本支持细粒度的用户权限控制早期版本需要手动配置持久化参数后续版本在默认配置上做了若干优化。我的做法是优先选当前主流云厂商和框架兼容性最好的版本这样无论是网上搜问题还是接第三方客户端工具遇到的信息差都会小很多。另一个细节是 32 位和 64 位的区别生产环境一定要 64 位32 位版本内存限制非常严重基本只能当玩具。1.3 安装前的基础依赖自查清单虽然不同平台的安装步骤不一样但有几个共性的检查项可以提前做能省去后面很多折腾。确认系统架构Windows / Linux / macOS 的安装包互不通用即使同样是 Linux还有 glibc 版本、系统包管理器如 apt / yum / dnf的差异。确认编译工具链如果是源码编译安装必须提前装好 gcc、make 等基础工具。确认网络与端口Redis 默认监听 6379 端口需要保证该端口没被占用防火墙如果开启需要决定放行策略。确认内存规划Redis 是内存型数据库数据量要评估到底占多大内存避免一台小机器塞了过大数据集直接 OOM。确认访问范围是本机使用还是允许局域网访问这直接关系到密码和 bind 配置。很多新手忽略最后一条。默认配置下 Redis 只监听本机回环地址如果你想让另一台机器连接它光改密码是不够的绑定地址也得一并处理。反过来如果你只是本地测试强行改 bind 反而会引入安全风险。我见过有人在云服务器上把 Redis 暴露到公网又忘了设密码结果被人写入了定时任务做挖矿程序这个教训相当惨烈。2. 各平台下的下载与安装全流程2.1 Windows 环境下的安装方式Redis 官方其实并不提供 Windows 原生产品这是很多新手会疑惑的地方。社区维护了一个 Windows 移植版本主要用来开发调试和学习。在 Windows 上装 Redis 主要有三种方式直接下载压缩包解压、使用包管理器安装、在 Docker 容器里跑。最省事的做法是下载预编译的压缩包解压之后就能看到 redis-server.exe、redis-cli.exe 等可执行文件双击或命令行启动即可。我建议 Windows 用户在命令行里操作这样能看到更完整的日志。启动方式很简单redis-server.exe默认情况下它会加载内置默认配置控制台会打印当前版本、端口和运行模式。如果你想指定配置文件redis-server.exe redis.windows.conf这里有个细节值得留意Windows 移植版的配置文件名字可能是 redis.windows.conf和 Linux 下的 redis.conf 不完全一样。我第一次帮别人排查时发现有人改了半天配置不生效原因就是启动时没有加载这个文件。用命令行验证一下是否加载成功看启动日志最前面有没有打印 Config file 的路径即可。除了直接解压也推荐 Windows 用户试试包管理器方式。以常见包管理器为例执行安装命令后 Redis 会被注册成系统服务可以设置开机自启适合想模拟真实部署场景的同学。缺点是包管理器仓库的版本可能滞后于官方学习时问题不大但连接 Redis 7 以后新增的命令时要注意客户端工具的兼容性。2.2 Linux 下从源码编译安装Linux 是 Redis 的主力舞台。在生产服务器上最常见的方式是源码编译安装虽然看起来比包管理器多几步但好处是版本可控、目录可控、编译参数可控。先安装必要依赖以最常见的 Debian/Ubuntu 系为例apt update apt install -y gcc make libc6-dev tcltcl 这个包很多人会漏掉它是 Redis 自带的测试套件运行时要用的依赖。缺了它不会影响编译但会影响 make test 这一步所以最好提前装上。如果你在 CentOS/RHEL 系对应包名是 gcc、make、tcl安装命令换成 yum install 或 dnf install 即可。接着下载源码包。从官方发布页拿到 tar.gz 链接后在服务器上执行wget https://download.redis.io/releases/redis-7.x.x.tar.gz tar -xzf redis-7.x.x.tar.gz cd redis-7.x.x进入源码目录后的标准三步是make make test make installmake 会编译整个项目这一步耗时取决于机器的性能通常在几十秒到几分钟之间。make test 会跑一遍内置的功能测试如果前面没装 tcl这一步会直接报错提示缺依赖。make install 会把 redis-server、redis-cli 这些可执行文件复制到系统路径下装完之后就不需要每次都进源码目录启动了。如果你不希望所有二进制散落在系统目录里也可以手动指定安装路径。比如把可执行文件放到 /usr/local/redis/bin配置文件放到 /etc/redis 下这种方式对后续做服务管理和多实例部署更清晰。个人建议初期不用过度设计目录先把服务跑起来等需要做集群、做容器化时再重新梳理也不迟。2.3 macOS 等其他环境的安装方式macOS 用户装 Redis 相对简单最常见的做法是通过 Homebrew 安装brew install redis安装完成后可以用 brew services 管理 Redis 的后台运行也可以直接用 redis-server 启动。Homebrew 会自动装好配置文件和基础环境省去很多手工步骤。但要注意Homebrew 默认的数据目录和配置文件路径和源码编译略有差异网上很多教程混着写容易踩坑。我的经验是先 whereis redis-server 和 redis-cli 看清楚可执行文件在哪再通过 redis-server --version 确认装的是什么版本做到心里有数。如果是用 Docker 跑 Redis那更干净。一条命令就能拉起一个实例docker run -d --name redis-test -p 6379:6379 redis:7这种方式的优势是我可以随时起一个全新的实例做测试用完直接删掉不给宿主机留下任何垃圾文件。缺点是容器里的数据默认不持久化重启容器数据可能丢失。需要保存数据的话要把容器内的数据目录挂载到宿主机。对于学习阶段推荐 Docker 方式因为可以自由尝试各种姿势比如用不同版本镜像对比行为差异这在单机上很难做到。安全起见Docker 部署生产 Redis 时端口映射和密码策略需要额外注意避免把没有保护的实例直接暴露到外面。3. 配置、启动与基础自检3.1 redis.conf 核心参数解读配置文件是整个 Redis 使用过程中最重要的部分。虽然默认配置可以让 Redis 跑起来但如果完全不理解里面的参数遇到问题就是一头雾水。我按重要程度挑几个必须知道的参数展开。bind 参数决定了 Redis 监听哪些网络接口。默认情况下通常绑定 127.0.0.1也就是只能本机访问。如果想局域网内的其他机器能连上来需要增加机器对应的 IP或者直接改成 0.0.0.0监听所有网卡。但这里有个容易被忽略的点改完之后不仅仅是局域网的人能连公网如果也通了那就等于把数据裸露在网络上。所以只要不是纯本机测试就必须配合密码认证。protected-mode 是 Redis 的一个安全开关。当它开启且没有设置密码、同时监听的是外部接口时Redis 会拒绝来自非本机的连接请求。很多人连接不上配置文件里 bind 也改了密码也设了结果还是不行问题往往出在 redis.conf 中 protected-mode yes而密码又没配好。这个参数的设计初衷是保护那些我就临时用一下的用户但有时候反而成了排查时的迷雾。daemonize 控制是否以后台守护进程方式运行。开发调试时可以用前台模式no日志输出到控制台看得清楚。真正部署时改成后台模式yes并配合 pidfile 记录进程号方便管理。日志级别默认 notice 即可线上遇到排查性能问题时再临时调成 debug注意别开太久否则日志量会很吓人。内存相关的参数同样需要提前理解。maxmemory 不设置的话Redis 会一直使用系统内存直到被系统杀掉。学习阶段可以不管但要对自己的数据量心里有数。maxmemory-policy 是内存达到上限后的淘汰策略常见的 noeviction不淘汰直接报错和 allkeys-lru对所有 key 做 LRU 淘汰需要分清楚。我经常提醒初学者先搞清楚自己要的是缓存场景还是存储场景选错了淘汰策略轻则数据被莫名清掉重则线上告警不断。3.2 启动、连接与基础自检启动 Redis 最常见的两种方式直接启动或指定配置启动。开发环境最简单的方式是redis-server此时 Redis 会以默认配置启动控制台输出一大段 logo 之后出现 Ready to accept connections 的字样就说明它已经在监听了。带上配置文件启动则更接近生产模式redis-server /etc/redis/redis.conf启动之后要确定它真的活着打开另一个终端窗口用自带的命令行客户端连一下redis-cli ping如果返回 PONG说明服务正常。这个 ping/pong 是一个非常简单又有效的自检操作凡是怀疑 Redis 没起来先敲这一句基本能定位大半问题。如果 redis-cli 在另一台机器上可以指定地址端口redis-cli -h 192.168.1.100 -p 6379 -a yourpassword注意 -a 明文传密码会出现在 shell 历史记录里生产环境要小心这个习惯。另外如果设置了密码但没带上执行 ping 会返回 NOAUTH 之类的提示这其实是安全机制在正常工作不用慌。自检时还可以用 info 命令看关键信息redis-cli info server redis-cli info memory redis-cli info clients如果是在本地开发至少要会看 redis_version、os、uptime_in_seconds 这几项。我曾经碰到一个场景服务莫名其妙重启最后就是靠 info server 里的 uptime 和 config get 里的参数定位出配置被改动的过程。Redis 自带的这种排错工具链其实一点不比商业数据库差只不过大多数人只在能用的层面就停下来了。3.3 客户端工具与连接配置服务端跑起来之后日常操作不一定要用命令行。虽然 redis-cli 是最底层的工具但图形化客户端在查看 key 分布、观察内存和 TTL、执行批量操作时明显更直观。市面上的 Redis 图形管理工具很多选一个顺手的学习工具即可我个人的标准是能看 key、能看内存、能看实时监控、支持命令控制台这四条占满就行。使用图形工具连接时有几个常见配置项要注意地址要填 host 和 port如果实例设置了密码需要在连接配置里填上如果是 Docker 端口映射出来的注意映射关系别填错如果是远端服务器先确认防火墙和安全组是否放行对应端口。很多人在图形工具上卡住不是工具本身有问题而是服务端 bind、protected-mode、密码这三者其中之一没配合好。这里有一个我特别推荐的排查顺序先用 redis-cli 从本机连排除服务端问题再换到远程机器上用 redis-cli 连排除网络和防火墙问题最后才去折腾图形工具的配置项。这个顺序能帮你把问题分层一次只解决一个环节不会因为同时动了好几个配置而不确定到底是哪一步生效的。图形工具是锦上添花命令行基本功才是根本。4. 快速上手五大数据结构的实际应用4.1 String 与 Hash 的日常用法Redis 的基本使用核心就是数据操作。我经常对初学者说先把五大数据结构的命令过一遍你就已经学会了 Redis 的八成日常用法。String 是最基础的结构它就是一个键对应一个字符串值。平时做缓存、做计数、做分布式锁String 都能胜任。SET user:10001:name zhangsan GET user:10001:name这里要说明一点Redis 的键设计中冒号只是约定俗成的分隔符没有特殊的语法含义。用冒号组织 key 的命名空间是为了可读性和后续按前缀扫描。String 还可以做自增SET page:view:20240615 0 INCR page:view:20240615INCR 是原子自增操作用在计数场景里非常稳。不适合用 INCR 的场景我也举个例子如果每个请求都要先读再写并发一高就会出现近似计数不准确、甚至覆盖写入的问题这种时候就得考虑 Lua 脚本或别的方案。Hash 适合存放对象类型的数据。举个例子用户资料有姓名、年龄、城市用 String 的话要拆成好几个 key用 Hash 一个 key 就搞定了HSET user:10001 name zhangsan age 25 city beijing HGETALL user:10001 HGET user:10001 nameHash 最大的好处是字段级别的读写更新某一个字段不会影响其他字段内存占用也比大量 String 更省。做对象缓存时我通常优先 Hash比如缓存数据库中的一行记录。它还能单独对某个字段做自增适用于某个订单状态的计数等细粒度操作。4.2 List、Set、ZSet 各自适合做什么List 是双向链表结构可以用来做简单的消息队列、最新动态列表。左侧推入、右侧弹出这种队列模式在后端异步任务里很常见LPUSH task:queue job1 BRPOP task:queue 0BRPOP 是阻塞式弹出如果队列为空它会一直等待直到有数据进来。这种设计在实现异步消费时非常方便能减少很多空轮询。做最新XX列表场景也很顺手每次新数据进来 LPUSH再 LTRIM 只保留前 N 条。Set 是无序去重的集合适合做标签、好友关系、抽奖池。交并差集运算让它在社交类场景里特别好用SADD user:10001:tags java redis mysql SADD user:10002:tags java python SINTER user:10001:tags user:10002:tagsSINTER 求两个集合的交集可以用来快速算共同好友、共同兴趣。这个场景如果用 SQL 表来做关联查询数据量一大就要索引优化而在 Redis 就是一个命令的事。ZSet 是有序集合每个成员关联一个分数按分数排序。排行榜、延时队列、取 Top N 都离不开它ZADD leaderboard 100 alice ZADD leaderboard 200 bob ZREVRANGE leaderboard 0 9 WITHSCORESZREVRANGE 按分数从高到低取前十名基本就是排行榜的标准写法。ZSet 的底层实现是跳跃表加哈希表所以它的排序查询复杂度很高这也是它在海量数据下仍然好使的原因。做延时任务时还可以把任务执行时间戳作为分数循环从最小值弹出到期的任务。4.3 过期时间与 key 管理Redis 的缓存能力离不开 TTL生存时间。给 key 设置过期时间就能让数据在设定的时间点之后自动消失这是缓存和数据库保持一致的经典手段。SET session:token abc123 EX 3600 EXPIRE session:token 3600EXPIRE 的坑在于对一个已经存在过期时间的 key 重新赋值默认会清除原过期时间。比如你先 SET key value EX 100接着又执行 SET key value2那 key2 就不会再过期了。这个问题我在生产环境遇到过不止一次所以现在写缓存代码时都会刻意检查赋值时有没有带 EX 参数。查看过期时间用 TTL 命令返回 -1 表示没有设置过期时间-2 表示 key 不存在。TTL session:token内存清理机制了解一个大概即可过期 key 的清理有惰性删除和定期删除两种策略前者是访问时发现过期再删后者是后台定期抽查删除。两者是配合使用的关系。我做缓存设计时习惯把所有缓存 key 都设置 TTL即使某些业务希望长期保留也会设置一个很长的过期时间而不是完全不过期。这样能避免后续上线新逻辑时因缓存了老数据导致数据不一致的尴尬局面。5. 常见问题与排查技巧实录5.1 启动失败与端口占用最全排查最常遇到的启动失败原因之一就是端口被占用。这个问题的表现是启动命令执行后立刻报错或者服务起来了但连不上。排查思路很简单netstat -tlnp | grep 6379 lsof -i:6379如果发现 6379 被别的进程占用要么杀掉占用进程要么改 Redis 的 port 配置。端口占用本身并不复杂复杂的是有些程序会动态监听随机端口干扰之后还会再出现。用 netstat 看清进程 PID 和进程名之后再决定是 kill 还是改端口。另外一类启动失败是权限和目录问题。Redis 在写持久化文件或日志文件时如果对应目录没有写入权限启动就会失败或运行中报错。磁盘满了同样会导致写 AOF 或 RDB 文件失败Redis 默认策略下会拒绝写操作。我排查过很多次明明服务正常、读写却报错的问题最后发现就是磁盘空间满了。养成定期 df -h 的习惯比临时慌着删数据强得多。5.2 连接超时与保护模式问题本机连不上、远程更连不上的问题几乎每个人都会遇一遍。现象通常是客户端报 Connection refused 或者超时。这类问题我建议按这个清单逐项排查Redis 进程是否在跑ps -ef | grep redis-server。端口是否监听netstat 或 lsof 确认。bind 配置是否包含你要连的 IPconfig get bind。protected-mode 是否拦住了你检查 redis.conf 中 protected-mode 的值。有没有设置密码requirepass 是否配置、客户端有没有带上密码。防火墙和安全组是否放行这是云服务器上最常见的问题。在本地一切正常、换台机器就连不上的案例里八成以上是 bind 或安全组问题。有一次我排查了快一小时最后发现是某云服务器的安全组规则没加 6379 端口服务端怎么改都没用。所以远程连接问题永远要先确认网络链路能通再怀疑 Redis 本身。5.3 内存占用与性能隐性问题Redis 是内存型数据库内存问题几乎是必然要面对的。常见现象是 maxmemory 设置过小或没有设置数据一多就触发淘汰策略或大量换页。先用命令查内存redis-cli info memory重点看 used_memory_human 和 maxmemory_human 这两个值。如果数据量已经逼近上限就需要考虑扩容或优化数据结构。另一个异常现象是内存涨得异常快这通常不是单条数据大而是大量小 key 堆积。一个空 key 就有几十字节的开销几十万上百万个短 key 叠加起来非常可观。排查大 key 也有现成命令redis-cli --bigkeys它会扫出占用最大的 key 并分类汇总。不过在生产环境对大实例跑这个命令要谨慎虽然 Redis 做了处理但确实会带来一定开销。我通常会在业务低峰期执行或者用一个只读的副本实例来扫。内存优化本身是个细活string 换成 hash、批量设置改成 pipeline、合理设 TTL 及时清掉垃圾 key都是常见手段。5.4 远程访问权限控制怎么做才稳妥Redis 本身不提供加密传输层它把加密交给了外部方案如 TLS 代理但它原生支持的访问控制主要是密码和用户权限机制。生产环境我建议至少做到设置强密码、关闭 protected-mode 或保留它作为兜底、bind 限制到具体网段、不把 6379 暴露到公网。密码配置是 requirepass加上之后客户端所有命令都要求先认证# redis.conf requirepass 这里换个足够随机的密码新版 Redis 还有更细粒度的 ACL 机制可以给不同业务建不同用户、不同权限。比如给某个应用只开放缓存前缀的读写权限其他人连数据库命令都不能执行。这个机制在团队协作时特别有用能避免误操作导致全库被清掉。也提醒一句密码和 bind 是叠加关系。只看好密码但 bind 0.0.0.0等于把门打开但上了锁如果密码泄露就是灾难。只看好 bind 但没密码如果本机有其他用户服务一样存在被越权访问的风险。成熟的做法是把两者搭配起来用配合防火墙做网络层限制从多个维度堵住风险。6. 实际运行中的心得与常见误区6.1 配置改了半天不生效先想想加载了没有这是我见过频率最高的问题改了 redis.conf 里的参数重启服务发现没变化。排查方法很简单启动时终端会打印配置文件路径如果没有打印检查启动命令有没有指定 conf。用 config get 命令也能看实际生效值redis-cli config get save redis-cli config get maxmemory在运行中可以通过 CONFIG SET 命令临时改参数例如redis-cli config set maxmemory 256mb但这种形式是临时生效重启之后会恢复成配置文件里的值。所以判断一个配置是否永久生效一定以配置文件内容为准。记住这套逻辑之后排查配置问题就会快很多。6.2 学习阶段与生产部署的差别要拎清学习期间我最推荐用 Docker 快速拉起实例随手玩、随手删不怕污染本机环境。但生产环境我不太建议图省事直接拿默认配置启动至少要把持久化策略、密码、内存上限、日志位置都梳理一遍。下面是我总结的一个学习验收清单每项都能做到说明你已经能独立使用 Redis 了本机能通过 redis-cli 连接并能 ping 通。能看懂 info server 里打印的版本、运行时间、端口。能自己用配置文件启动 Redis并设置 requirepass。能执行 String、Hash、List、Set、ZSet 至少各两条常用命令。能定位常见的端口占用和连接失败问题。知道如何查看和修改运行中的配置参数。对照这个清单自测一遍如果全部搞定那这一篇的内容就算是真正吸收了。接下来可以进入下一个阶段学习 RDB/AOF 持久化、主从复制、哨兵和集群方案。我自己回头看整个 Redis 上手过程最关键的其实不是记住命令而是建立起配置、启动、连接、排错这一套完整的心智模型。有了这个底子后续不管什么版本、什么部署方式、什么客户端工具对你来说都只是换个操作界面而已。6.3 一个小习惯用命名前缀和数据分目录减少混乱最后分享一个很实用的习惯给 key 设计统一命名前缀。业务名、模块名、对象名用冒号或点号隔开比如 order:user:10001:list、cache:product:123。这样做的价值在 Redis 运维时会彻底体现出来——扫描某个业务的 key 时可以按前缀过滤排查缓存数据异常时能快速定位相关 key清理垃圾数据时也能按前缀批量删掉不会误伤其他业务。另一个习惯是不要把多个毫无关联的业务数据全塞进同一个实例。学习阶段当然无所谓但进入真实项目后缓存和队列建议分实例或分库Redis 的 SELECT 命令可以切库管理避免某个业务的慢查询把其他业务拖下水。Redis 的单个实例性能很强但它同样需要合理的规划和隔离。把这些日常习惯先建立起来后续做架构演进时就不会被一堆历史债拖住。
阅读完成 · 觉得有帮助？
