Redis本身的设计目标就是高性能，但高性能并不等于零配置。很多参数直接决定内存使用上限、数据持久化时机、客户端连接行为以及主从复制的稳定性。动手改配置之前，先要明确一个原则：不存在一套适合所有业务的万能配置，必须根据数据量、读写比例、可容忍的数据丢失窗口和机器内存大小来综合判断。
内存管理配置：maxmemory 与淘汰策略怎么选
maxmemory 是 Redis 中最容易被忽略又最危险的一个参数。它的默认值是 0，表示不限制内存使用。如果你只把 Redis 当纯缓存用，机器内存是 32GB，不设置这个值意味着 Redis 可以一直往物理内存里写数据，直到触发操作系统的 OOM Killer，轻则 Redis 进程被杀，重则整个服务器无响应。因此第一件事就是把 maxmemory 设置成一个合理值。一般建议预留 20% 左右的内存给操作系统和其他进程，例如 16GB 内存的机器，Redis 的 maxmemory 可以设置为 12GB，单位可以是 mb 或 gb，配置文件里写 maxmemory 12gb 即可。
设了内存上限之后，还必须配置 maxmemory-policy，也就是内存写满后使用哪种淘汰策略。Redis 提供了八种策略，常见的有 noeviction、allkeys-lru、volatile-lru、allkeys-lfu、volatile-lfu 等。noeviction 是默认值，表示内存满了之后直接拒绝所有写请求，只允许读和删除操作。这种策略适合数据库类场景，绝不能用于纯缓存，否则内存一满整个业务就不可用。allkeys-lru 在全部键里用最近最少使用算法淘汰，适合大多数缓存场景；allkeys-lfu 用最不经常使用算法，能更好地应对热点数据分散的情况。如果你的键都设置了过期时间，可以使用 volatile-lru 或 volatile-lfu，但要注意没有设置过期时间的键不会被淘汰，仍然可能撑爆内存。一条实用建议：纯缓存业务用 allkeys-lru，混合存储业务用 volatile-lru 并给所有缓存键设置 TTL。
还有一个容易混淆的配置是 maxmemory-samples，它控制 LRU 和 LFU 算法的近似精度。Redis 并不维护一个精确的 LRU 链表，而是随机取 5 个键（默认值）淘汰其中最久未使用的那个。增加这个值会提高淘汰准确度，但消耗更多 CPU。一般没有必要改，除非你观察到缓存命中率明显低于预期，可以把它调到 10。
持久化配置：RDB 与 AOF 的取舍和参数细节
持久化是 Redis 配置中另一块需要重点决策的部分。RDB 通过快照方式把某个时间点的数据写入磁盘，优点是文件紧凑、恢复速度快、对性能影响小；缺点是两次快照之间的数据会丢失。AOF 则记录每一次写命令，数据安全性更高，最多丢失一秒甚至一条命令，但文件体积大、恢复慢，而且持续写入对磁盘有压力。生产环境强烈建议同时开启两种持久化，RDB 用于快速恢复，AOF 用于减少数据丢失。
RDB 的关键参数是 save，语法为 save 秒数 修改次数，表示在指定秒数内发生了指定次数的写操作就触发一次快照。默认配置是 save 900 1、save 300 10、save 60 10000。这个默认值偏保守，在写多读少的场景下会频繁生成快照，导致 fork 子进程时 CPU 和内存抖动。如果你的数据重要性一般，可以适当放宽，比如 save 3600 10，让快照频率降下来。需要注意的是，每次 RDB 保存时 Redis 会调用 fork 创建子进程，如果数据量很大（比如几十 GB），fork 本身可能耗时几百毫秒甚至更久，期间主进程会阻塞。所以大数据量情况下要合理规划快照时间点，避免在业务高峰自动触发。
AOF 的配置集中在 appendonly 和 appendfsync。appendonly yes 开启 AOF，appendfsync 有三个选项：always、everysec、no。always 每条写命令都同步到磁盘，安全性最高但性能最差，通常不用；everysec 每秒同步一次，最多丢失一秒数据，是性能和安全的平衡点，绝大多数场景推荐这个值；no 表示由操作系统决定何时刷新缓冲区，性能最好但可能丢失好几秒的数据，适合对数据丢失不敏感的场景。还有一个 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 控制 AOF 重写时机，保持默认值即可，但如果 AOF 文件增长过快，可以适当降低 percentage 阈值。
网络与服务配置：连接超时与安全加固
网络相关的配置项里，timeout 经常被误解。它指的是客户端空闲多少秒后 Redis 主动断开连接，默认值是 0，表示永不超时。很多人以为设置 timeout 能防止慢查询，其实它只管空闲连接，不管命令执行时间。如果你的客户端连接数很多且大部分处于空闲状态，设置一个合理的 timeout 比如 300 秒，可以有效释放文件描述符。反过来，如果业务中有长连接推送或订阅场景，长时间不发数据很正常，这时候设置 timeout 会导致客户端频繁重连，反而增加开销。总之 timeout 要根据客户端的连接模式来定，不要无脑设置。
tcp-keepalive 是另一个容易被忽略的配置，默认 300 秒，单位是秒。它控制 Redis 向空闲的 TCP 连接发送 keepalive 探测包的时间间隔。在云服务器或 NAT 环境下，网络设备可能主动断开长时间无活动的连接，导致客户端出现 Connection reset 错误。适当调小这个值（比如 60 秒）可以保持连接活性。还有一个 tcp-backlog，它决定内核中已完成三次握手但还未被 accept 的连接队列长度，高并发场景下如果客户端连接建立缓慢，可以把这个值调大，配合系统参数 somaxconn 一起调整。
安全方面有两个必须注意的配置：bind 和 protected-mode。bind 用于指定 Redis 监听的网卡地址，默认绑定 127.0.0.1。如果你需要远程访问，很多人直接注释掉 bind 或改成 0.0.0.0，同时把 protected-mode 设为 no，这会把 Redis 完全暴露在公网上。哪怕设置了密码，也扛不住暴力破解。正确的做法是：只在受信任的内网环境里监听，配合防火墙限制来源 IP；如果必须跨公网，使用 SSH 隧道或 VPN，而不是直接放开端口。protected-mode 保持 yes 即可，它会在未绑定具体地址且未设置密码时拒绝外部连接，相当于一道兜底防线。
常见配置陷阱与排查建议
配置文件中还有一个 stop-writes-on-bgsave-error，默认 yes，意思是当 RDB 后台保存失败时，Redis 会拒绝所有写请求。这个设计是为了保护数据一致性，但在实际运维中，如果磁盘满了或者权限错误，客户端会突然收到大量只读错误。如果你用的是纯缓存场景，完全可以把这项设为 no，让写操作继续，缓存失效总比业务中断好。但如果是持久化存储，最好保持 yes 并尽快修复磁盘问题。
另一个高频问题是主从复制中的 repl-backlog-size。这个参数决定复制积压缓冲区的大小，用于支持部分重同步。默认 1MB 对于数据量较大或网络不稳定的环境来说太小了，会导致频繁的全量同步，拖垮主节点。一般建议设置为 64MB 或更大，具体看写入速率和网络延迟。可以在从节点上执行 info replication 查看 master_repl_offset 的增长速度来估算合适大小。
排查配置问题时，不要只盯着 redis.conf，还要用 config get 命令查看运行时实际生效的配置。通过 redis-cli 连接后输入 config get maxmemory 就能看到当前值，很多配置支持 config set 在线修改，但不一定写入配置文件，重启后可能丢失。建议养成习惯：先在配置文件里改，然后用 config set 验证效果，最后再重启确认持久化。对于性能敏感的配置（比如 maxmemory-policy 和 appendfsync），修改前最好在测试环境用 redis-benchmark 对比一下吞吐和延迟变化。