企业官网建设流程全解析

如果你正在为项目里的缓存方案选型而翻来覆去，或者刚接手一个后端服务，发现日志里不断出现connection refused，那么 Redis 大概率是你绕不开的话题。作为目前使用率最高的内存数据存储，Redis 凭借极快的读写速度、丰富的数据结构和简单的部署方式，几乎成了后端工程师的标配技能。这篇内容我把自己从零接触 Redis 到在项目里稳定运行的完整过程整理出来，覆盖安装、配置、常用命令、问题排查和踩坑经验，适合刚入门的新手，也适合想查漏补缺的开发者。

其实网上关于 Redis 的教程并不少，但很多要么只讲命令不讲部署，要么直接把配置文件一贴就完事，根本没有解释每项参数背后的逻辑。我在学习和实战过程中发现，真正卡住人的往往是那些“文档不会告诉你”的细节：比如为什么编译后启动老是失败，为什么明明设置了密码还连接不上，为什么数据量一大就频繁丢失。这篇内容会尽量把这些坑都讲透，并且给出我可以直接拿去用的实验配置和命令。

1. 安装前的准备：版本选择与环境依赖

1.1 为什么要选稳定版而不是最新版

很多新手上来就下载官网最新版本，觉得版本越新功能越强。这个思路在 Redis 上并不推荐。Redis 的发布节奏分为稳定版和候选版，候选版通常包含一些新特性，但也会引入未知的稳定性问题。除非你需要某个特定新功能，否则在正式环境里应该选择最新的稳定版分支。

我本人在测试环境里就吃过这种亏。有一次图新鲜用了某个发布候选版本，结果在高并发写入场景下出现了内存增长异常，查了一晚上才发现是某个新数据结构在特定条件下触发了内存碎片问题。换回稳定版之后一切恢复平静。所以我的建议是：去官网下载页面看版本号，选Stable标签对应的版本，千万不要看数字最大就往下拉。

实际项目里，我习惯选择的版本是 5.x 或 6.x 系列。它们经过了大量生产环境验证，相关的排错经验也最丰富，遇到问题能搜到的资料最多。7.x 系列现在也逐步稳定，但如果你所在的团队没有特别需求，从 6.x 起步完全够用。版本选择这件事上，保守一点不丢人。

1.2 Linux 环境依赖准备

Redis 本身是 C 语言写的，所以安装核心依赖就两样：编译工具链和 C 标准库。在大多数 Linux 发行版上，你需要确保已经装好了gcc、make以及基础开发库。以常见的 CentOS 环境为例，安装前先执行下面这一组命令，把依赖一次性补齐：

yum install -y gcc gcc-c++ make tcl

这里的tcl是 Redis 官方测试套件依赖的语言解释器。如果你想在编译后跑一遍官方自检（make test），没有tcl是跑不起来的。虽然生产环境不一定非要跑测试，但本地学习阶段我强烈建议装上，它能帮你验证当前机器的环境是否完全兼容。

Ubuntu / Debian 系的系统命令略有不同，对应的是：

apt update && apt install -y build-essential tcl

注意一下，不同发行版的包名有差异，如果安装时报“找不到软件包”，先执行一下包管理器的更新命令，比如 CentOS 的yum makecache或者 Ubuntu 的apt update，再重新安装。这个顺序不要弄反，很多人一上来就装，结果报错后才想起来源索引都没更新。

1.3 三种主流安装方式对比

Redis 的安装方式其实不止一种，我用一张表把最常见的三种方式列出来，方便你根据自己的场景选择：

在实际项目中，我见到最多的还是源码编译安装。原因很现实：包管理器自带的版本往往滞后于官方稳定版好几个版本，而 Docker 方式虽然部署方便，但日志采集、系统参数调优、以及和一些老旧的运维监控体系对接时，反而会额外增加复杂度。这也是为什么下面的内容我主要以源码编译安装为主线来讲解，这也是我认为最能帮助你理解 Redis 运行机制的方式。

2. 从零安装 Redis：源码编译与通用配置

2.1 下载、解压、编译的完整步骤

选定版本之后，下载源码包。以官方稳定版为例，在终端里依次执行：

wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar xzf redis-6.2.14.tar.gz cd redis-6.2.14

在编译之前，我建议你先做一件事：看一眼源码目录里的README.md。这个文件虽然不厚，但把 Redis 的编译选项解释得非常清楚，比网上很多二手教程都准确。比如它明确告诉你，默认编译出来的二进制文件其实带上了调试符号，如果你需要更小的体积或更好的性能，可以设置特定的编译变量，不过不是生产追求极致性能的话没必要折腾这一步。

接下来是编译和安装：

make -j 4 make install

这里的-j 4表示用 4 个并行任务来编译，可以显著缩短编译时间。具体的并行数可以根据你机器的 CPU 核心数来调整，一般用nproc命令查出来的核心数就行。如果编译过程报错，绝大多数情况是缺依赖或者 gcc 版本太老，先把上一节说的依赖装全再重试。

make install默认会把 Redis 的可执行文件安装到/usr/local/bin目录下，包括redis-server、redis-cli等核心工具。装完后你可以先跑一下版本命令验证是否成功：

redis-server --version

如果能看到版本号输出，说明安装已经完成了。这一步很简单，但许多人会忽略，直接跳到启动然后各种找不到命令，其实验证一下 10 秒钟都花不到。

2.2 安装后的目录结构

源码解压目录里有很多文件，但真正核心的就几个。我帮你梳理一下：

• src/目录：编译产物所在的目录，里面的redis-server和redis-cli是我们日常用到最多的二进制文件
• redis.conf：默认的配置文件模板，里面包含了所有可配置项的默认值和详细注释
• utils/目录：包含一些辅助脚本，比如创建 systemd 服务文件的工具
• tests/目录：官方测试用例，学习阶段可以翻看，能加深对功能的理解

安装完之后，正常情况你不需要在源码目录里启动 Redis，因为可执行文件已经复制到了系统路径中。但源码目录里的redis.conf建议复制到你自己规划的配置目录，我一般习惯放在/etc/redis/redis.conf，这样一个项目一个配置，互不干扰。

2.3 配置 systemd 管理 Redis 进程

生产环境里我们通常不希望 Redis 在前台终端直接运行，而是希望它作为后台守护进程随系统启动自动拉起。有几种实现方式，最传统的是直接打开daemonize yes让 Redis 自己后台化，但更规范的做法是用 systemd 来管理。因为 systemd 能帮你自动处理进程崩溃后的重启、开机自启、日志收集，这些运维能力在出问题时特别有价值。

先在工作目录里创建服务文件：

vim /etc/systemd/system/redis.service

内容可以参考下面的写法：

[Unit] Description=Redis Server After=network.target [Service] ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill -15 $MAINPID Restart=always User=redis Group=redis PIDFile=/var/run/redis/redis-server.pid [Install] WantedBy=multi-user.target

这里有几个注意点想特别说明一下。Restart=always表示进程不管因为什么原因退出，systemd 都会尝试重新拉起，这比 Redis 自己的daemonize更可靠。User=redis建议提前创建好专用的系统用户，不要用 root 直接跑 Redis，因为一旦应用被攻破，攻击者获得的就是 root 权限。创建用户的命令是：

useradd -r -s /sbin/nologin redis

同时要把配置目录和数据目录的所有者改成这个用户：

chown -R redis:redis /etc/redis mkdir -p /var/lib/redis chown -R redis:redis /var/lib/redis

服务文件写好后，执行：

systemctl daemon-reload systemctl enable redis systemctl start redis systemctl status redis

看到active (running)的绿色状态，就说明 Redis 已经被 systemd 成功托管了。这一步完成之后，你再也不用手动启动进程，系统重启后 Redis 也会自动跟在网络服务后面跑起来。

3. Redis 核心配置解析：这些参数一定要改

3.1 启动方式与基础网络配置

Redis 默认的redis.conf其实已经是一个能跑的配置了，但直接用默认值上线基本等于裸奔。我们先从最基础的配置说起。

修改daemonize的时候要特别留意：如果你计划用 systemd 管理 Redis，就不要在配置文件里开daemonize yes，否则 systemd 会认为进程没有成功前台化从而无法跟踪。正确做法是保持daemonize no，由 systemd 负责后台托管。

网络相关的配置有三件套要理解：bind、port和protected-mode。

• bind 127.0.0.1表示只允许本机连接
• bind 0.0.0.0表示监听所有网卡
• protected-mode yes是 Redis 自带的安全防线，当没有配置密码且绑定公网地址时，它会拒绝外部访问

实际部署时我的建议是：如果 Redis 和应用部署在同一台机器，bind 127.0.0.1就足够了；如果 Redis 独立部署，需要被其他服务器访问，必须明确绑定到内网 IP 并设置密码，同时保持protected-mode yes。不要图省事直接绑定0.0.0.0而不设密码，这相当于把你的数据裸奔到公网，被扫描爆破只是时间问题。

3.2 持久化配置：RDB 与 AOF

Redis 是内存数据库，一旦进程退出，内存里的数据都会清空。所以持久化配置是上线前必须想清楚的事情。Redis 提供了两种持久化方案：

RDB（快照模式）是把某个时间点的内存数据全量写入磁盘文件。默认配置里已经开启，核心参数是save，例如：

save 900 1 save 300 10 save 60 10000

这行配置的含义是：如果 900 秒内至少有 1 次写操作，就触发一次快照；或者 300 秒内至少有 10 次写操作，以此类推。RDB 的优点是恢复速度快、文件紧凑；缺点是快照间隔内如果宕机，会丢失这段时间的写入数据。

AOF（追加模式）是把每一次写命令追加到日志文件，重启时通过重放这些命令来恢复数据。配置项是：

appendonly yes appendfsync everysec

appendfsync有三个候选值：always（每次写命令都同步到磁盘，最安全但性能最差）、everysec（每秒同步一次，平衡性能和安全性）、no（由操作系统决定何时落盘，性能最好但丢失风险最大）。生产环境用everysec是对的，既不会损失太多性能，最多也就丢一秒的数据。

关于两者如何选择，我的实践经验是：对数据安全性要求高、允许少量性能损失的系统，同时开启 RDB 和 AOF，用 AOF 保证数据不丢，用 RDB 做快速恢复；对数据丢失不敏感、追求极致读写的缓存系统，干脆只开 RDB 甚至不开持久化都可以。

3.3 安全配置：认证密码和命令重命名

Redis 的密码认证非常简单，配置里设置requirepass即可：

requirepass your_strong_password

设置之后，所有客户端连接都必须通过AUTH认证。如果忘了密码，可以在redis-cli中执行CONFIG GET requirepass查看当前配置，但这个命令本身也需要认证，所以本质上只能靠配置文件找回。

除了密码认证，还有一个容易被忽视的安全手段：危险命令重命名。Redis 里有几个命令在生产环境应该被禁用或改名，比如FLUSHALL（清空所有数据）、FLUSHDB（清空当前库）、KEYS（全量扫描键，会阻塞服务）。配置写法是：

rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command KEYS "some_hard_to_guess_name"

把FLUSHALL和FLUSHDB重命名为空字符串，等同于彻底禁用了这两个命令；把KEYS改成一个复杂的名字，防止线上误操作用它扫出所有键导致卡顿。这些细节平时看不出效果，真出问题时能救你一命。

3.4 内存管理：上限设置与淘汰策略

Redis 作为缓存，不可能无限占用内存，所以内存上限必须显式设置：

maxmemory 2gb

单位可以用gb、mb、kb，也可以直接用字节数。设置了上限之后，当内存达到上限时，Redis 会根据maxmemory-policy决定如何淘汰数据。常用的淘汰策略有这几种：

• noeviction：不淘汰，直接返回写入错误。适合不允许丢数据的场景
• allkeys-lru：从所有键中按照最近最少使用算法淘汰。这是缓存场景最常用的
• volatile-lru：只从设置了过期时间的键里按 LRU 淘汰
• allkeys-random：随机淘汰任意键
• volatile-ttl：优先淘汰剩余生存时间最短的键

我对大多数缓存场景的建议是allkeys-lru。原因很简单，缓存的意义就是把热数据留在内存里，冷数据被淘汰是合理行为；而volatile-lru要求你必须给每个键设置过期时间，一旦某个键漏设了，它就会一直占着内存不释放，反而可能触顶。

顺便提一句，maxmemory不设置的话，Redis 默认在 64 位系统上可以吃满所有可用内存，一旦内存不足触发操作系统的 OOM Killer，整个进程会被直接杀掉，后果非常严重。所以无论你做什么用途，都必须配置这个值。

4. 客户端连接与常用命令实战

4.1 redis-cli 连接与基础认知

安装完 Redis 后，最直接的客户端工具就是自带的redis-cli。连接本机 Redis 的默认命令是：

redis-cli -p 6379

如果需要认证，加-a参数传密码。但我不太建议直接在命令行明文带密码，因为会出现在 shell 历史记录里。更安全的方式是连接后再执行AUTH：

redis-cli AUTH your_password

连接成功后，你可以用PING命令测试连通性，返回PONG就代表一切正常。很多人会用INFO命令来查看 Redis 运行状态，这是非常有用的诊断命令，后面排查问题会经常用到。

redis-cli还有一大功能是可以进入交互模式后直接执行任何命令，也支持管道和脚本，调试时非常方便。不过要注意，redis-cli本身不会对命令做语法检查，敲错命令会直接报错并返回给客户端。

4.2 五种基本数据类型与操作示例

Redis 最核心的卖点就是它丰富的数据结构，而不只是简单的键值对。学习 Redis 命令，我建议按照这五种基础类型入手。

String（字符串）

这是最基础也是最常用的类型，可以用它做缓存、计数器、会话存储。基础命令有：

SET user:1:name "张三" GET user:1:name SET user:1:age 25 INCR user:1:age SETEX user:1:token "abc123" 3600

INCR命令用于原子自增，特别适合做计数场景，比如统计文章的阅读数。SETEX可以同时设置值和过期时间，适合保存带时效性的数据。

Hash（哈希）

Hash 适合存储对象，比如一条用户记录。它可以让你对单个字段进行读写，而不用把整个对象序列化成字符串：

HSET user:1 name "李四" age 30 city "北京" HGET user:1 name HGETALL user:1 HINCRBY user:1 age 1

对比一下，如果用 String 保存用户对象，更新一个字段就得 read-modify-write 整个对象，而 Hash 直接操作字段，性能和便利性完全不在一个层级。

List（列表）

List 底层是双向链表，适合做消息队列、时间线等场景。常用的命令：

LPUSH queue:task "job1" "job2" RPUSH queue:task "job3" LPOP queue:task LRANGE queue:task 0 -1

LPUSH 从左边压入，RPOP 从右边弹出，组合起来就是先进先出的队列模型。LRANGE 带索引遍历，0 到 -1 表示全部元素。用 List 做简单的任务队列在中小型项目里非常实用，不需要额外引入消息队列中间件。

Set（集合）

Set 是无序且元素唯一的集合，适合做标签、去重、共同好友等场景：

SADD user:1:tags "python" "redis" "backend" SMEMBERS user:1:tags SISMEMBER user:1:tags "python" SINTER user:1:tags user:2:tags

SINTER可以计算两个集合的交集，用来找共同关注的人非常方便。Set 还支持并集、差集等操作，灵活度很高。

ZSet（有序集合）

ZSet 在 Set 基础上给每个元素附加了一个分数，Redis 会根据分数自动排序。这个特性让它特别适合做排行榜：

ZADD ranking 100 "userA" ZADD ranking 90 "userB" ZINCRBY ranking 5 "userB" ZREVRANGE ranking 0 9 WITHSCORES

ZREVRANGE按分数从高到低取前 10 名。做排行榜、延时队列、实时热度排名都能用上。我在实际项目里用 ZSet 实现过基于用户活跃度的积分排名，改动很小，效果却非常稳定。

4.3 键管理与过期时间应用

无论哪种数据类型，键本身还有一些通用的管理命令：

EXISTS user:1:name TTL user:1:name EXPIRE user:1:name 300 PERSIST user:1:name DEL user:1:name TYPE user:1:name

TTL返回键的剩余存活时间，返回 -1 代表键永不过期，返回 -2 代表键不存在。EXPIRE可以给一个原本没有过期时间的键设置过期时间，PERSIST用来移除过期时间。TYPE查看键的类型，判断某个键存的是字符串还是 Hash。

键命名是一个非常容易被忽略但是很重要的话题。我习惯的命名规范是“业务域:对象ID:字段”，用冒号做分隔符。比如user:1001:profile、order:20240101:status。这样命名有两个好处：一是可读性强，任何人都能看懂键的含义；二是后续可以用SCAN按前缀扫描特定业务的数据，在排查问题时特别有用。不过我要提醒一下，尽量不要用KEYS user:*这样的命令做模糊匹配，因为它在键数量大的时候会阻塞整个 Redis 服务。生产环境应该用SCAN命令配合游标进行增量遍历。

4.4 发布订阅与管道优化

Redis 还支持发布订阅模式，适合做简单的消息通知。基本用法：

SUBSCRIBE channel:news PUBLISH channel:news "hello world"

订阅端会实时收到发布端推送的消息。这个功能在实现站内信、系统通知、在线状态广播时很轻便。但要注意，发布订阅是即发即弃的，如果订阅端不在线，消息就丢了。需要可靠消息投递的场景，还是老老实实用专业的消息队列。

另一个值得掌握的性能优化技巧是管道。Redis 在执行多条命令时，每条命令都要经历一次网络往返。如果你要批量插入大量数据，这样的开销会很浪费。管道模式可以把多条命令一次性发送到服务器再批量取回结果：

redis-cli --pipe < commands.txt

commands.txt里每行写一条 Redis 协议命令。我做过一次简单的测试，一次性插入一万条数据，普通逐条执行耗时好几秒，用管道只需要几百毫秒。日常开发和数据迁移场景，这个技巧能帮你省下大量时间。

5. 日常运维与常见问题的排查思路

5.1 连接失败的第一反应

遇到 Redis 连接失败，很多人第一反应是“Redis 是不是挂了”。但根据我的经验，大部分连接失败其实不是进程挂掉，而是网络、配置或认证问题。我会按下面的顺序排查：

第一步，确认进程是否存活。执行ps -ef | grep redis-server，看不到进程说明 Redis 可能没有启动，或者启动后崩溃了。这时候看一下之前的 systemd 状态和日志，定位原因。

第二步，确认端口是否在监听。执行ss -tlnp | grep 6379，看看 Redis 是否真的监听在预期地址。如果只能看到127.0.0.1:6379，说明bind配置限制只有本机可以连接，外部自然连不上。

第三步，确认防火墙有没有放行。很多人把配置改好了，结果云平台的防火墙还拦住 6379 端口，白忙一场。用telnet测试一下端口连通性，排除网络层的干扰。

第四步，确认密码是否正确。如果 Redis 开启了认证，客户端没有带密码或者密码错误，连接会被拒绝。日志里会看到类似NOAUTH Authentication required的提示。

这四步走完，绝大多数连接问题都能找到根因。我还遇到过一种情况：客户端连接数达到上限maxclients导致新的连接被拒绝。调整这个参数前，先检查一下是否有应用在频繁创建连接而没有释放，不然调大配置也只是治标不治本。

5.2 内存占用过高与性能变慢的定位

Redis 变慢，最常见的原因是慢查询和大键。Redis 是单线程模型，任何一个命令执行时间过长，都会阻塞后续所有命令。当你发现某个时间点 Redis 响应突然变慢，先执行：

SLOWLOG GET 10

查看最近执行的慢命令。如果慢查询集中在KEYS、SMEMBERS这类全量操作，说明有业务方在用危险命令，需要推动业务方改用SCAN或增量接口。

另一个常见原因是某个键的 value 特别大。比如一个 List 里有几十万条数据，或者一个 Hash 有几十万个字段，任何对这个键的全量操作都会卡住服务。处理大键的思路不是把它删掉，而是把它拆成多个小键，或者用专门的数据结构替代。

内存占用过高的话，用INFO memory查看used_memory、used_memory_human和mem_fragmentation_ratio。最后一个指标是内存碎片率，如果大于 1.5，说明内存碎片比较严重，可以考虑重启实例让碎片得到整理；如果小于 1，说明 Redis 可能触发了 swap，性能会直线下降，最好检查一下是否开启了 swap 以及内存是否真的够用。

5.3 持久化异常与数据丢失的防范

数据丢失是 Redis 使用中最让人崩溃的问题，我总结了几种常见的丢失场景和应对方式。

如果只开了 RDB 持久化，那么在上一次快照与宕机之间的写入数据会全部丢失。要降低丢失窗口，可以调短save的触发间隔，但这会增加磁盘写入频率，需要权衡。

如果开了 AOF，但appendfsync设成no，操作系统可能还没把数据写回磁盘，进程就崩了，同样会有丢失。所以至少要保证everysec。

如果 AOF 文件损坏导致无法启动，Redis 提供了修复工具：

redis-check-aof --fix appendonly.aof

运行修复工具会扫描 AOF 文件并移除损坏的部分。但要注意，修复后的文件可能会丢掉部分数据，这是没办法的事情。最好的防线永远是提前做好备份，定期把 RDB 文件复制到另一台机器或者对象存储上，不然等到故障发生才后悔就晚了。

还有一个容易踩的坑：服务重启后数据全没了。这通常是因为配置文件和启动参数不一致。比如你改的是/etc/redis/redis.conf，但启动 Redis 时没有指定这个配置文件，Redis 用的还是默认配置，持久化自然没生效。每次启动前用redis-server /etc/redis/redis.conf明确指定配置路径，能避免这类问题。

6. 高频命令速查与配置模板

6.1 日常高频命令速查表

我整理了一份我自己经常翻看的速查表，覆盖了日常开发、运维里最常用到的命令，建议直接收藏：

这个表格不是完整命令手册，但覆盖了 90% 的日常场景。真正深入使用某类数据结构时，再去查官方命令文档补充也不迟。

6.2 一份可以直接上线的纯净配置

下面是我在一台 4GB 内存的云服务器上使用的配置模板，你可以根据自己的机器和业务情况微调。这个配置兼顾了数据安全、性能上限和远程访问控制，适合中小型项目直接参考：

bind 127.0.0.1 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no supervised no pidfile /var/run/redis/redis-server.pid loglevel notice logfile "" databases 16 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /var/lib/redis appendonly yes appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb maxclients 10000 maxmemory 2gb maxmemory-policy allkeys-lru requirepass your_strong_password_here rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command KEYS "some_hard_guess_name"

这个模板里有几个点我再强调一下。bind 127.0.0.1加protected-mode yes属于保守配置，只允许本机访问，这是最安全的一种。如果 Redis 要给其他服务器用，把bind改成内网 IP。密码是必须要设的，这一点没有任何商量余地。maxmemory 2gb比物理内存 4GB 减去系统占用后的值略低，为操作系统和其他服务留出了缓冲，避免触发 OOM。rename-command那三行是安全加固，按生产习惯保留。

使用这个模板时，把your_strong_password_here替换成你自己的高强度随机密码，比如用openssl rand -base64 32生成的字符串，然后保存到/etc/redis/redis.conf，重启 Redis 服务：

systemctl restart redis systemctl status redis

注意修改配置后一定要用 systemd 重启，不是只改文件就算数。

7. 我踩过的三个坑，和一条实用建议

7.1 三个典型的翻车现场

第一个坑发生在初次接触 Redis 的时候。我当时照着文档写完配置，启动也成功了，但第二天看数据全没了。排查了很久才发现，启动时没有用redis-server /etc/redis/redis.conf指定配置文件，导致save和appendonly的设置全都没生效。后来我把配置文件路径当成启动命令的一部分，这个习惯保持到了今天，再也没犯过这个错。

第二个坑是密码问题。有次我在一台内网服务器上把bind改成了内网地址、设置了密码，结果开发环境连接一直报DENIED。查来查去，发现是客户端里存的旧密码过期了，新密码没有同步到所有调用方。从那以后我要求所有使用 Redis 的同事把连接信息集中放到配置中心，而不是散落在各自的代码里。

第三个坑让我印象最深。有一段时间线上 Redis 实例 CPU 持续飙高，百思不得其解。后来通过SLOWLOG才发现是一个数据分析任务在定期执行KEYS user:*，而用户表有十几万个键，每次扫描都让 Redis 停顿几十毫秒。统计任务本身不频繁，但每次执行都会阻塞主线程，在线高峰时段影响被放大。后来换成SCAN分页扫描，CPU 立刻恢复平静。

7.2 一条使用习惯建议

最后说说我最想分享的一条建议：学习 Redis 命令时，不要死记硬背，把命令分类记忆。String 就是存字符串和做计数器，Hash 存对象字段，List 做队列，Set 做集合运算，ZSet 做排行和排序。理解了每种数据结构背后的场景，命令自然而然就记住了。遇到不确定的用法，直接redis-cli里敲命令试，比翻书效率高得多。

另外也建议大家养成一个习惯：每次上线前用CONFIG REWRITE把当前生效的配置写回文件。有时候你临时用CONFIG SET改了一些参数，比如调大了maxmemory，但忘了改配置文件，重启之后改动全部丢失。用CONFIG REWRITE能让当前的运行时配置自动落盘，我每次调优完都会执行一次，算是给自己上一道保险。

根据我个人的体会，Redis 这套东西真的不难，难的是理解它运行的边界和容错机制。安装、配置、命令、排查，一条线走下来，你对后端缓存的整体认知会变得非常扎实。这篇内容里所有命令和配置，你都可以直接复制到自己的环境里去验证，动手试一遍比看十遍都管用。踩过几次坑之后你会发现，Redis 的核心技能其实就是谨慎、有条理、以及用好它提供的信息工具。