用Redis的时候那些容易忽略但又挺重要的细节和坑你得知道

数据持久化：你以为安全了其实可能丢了

很多人以为只要开了Redis的持久化功能,比如RDB（快照）或者AOF（记录所有写命令），数据就万无一失了，但其实这里坑很多。

RDB是定时快照,默认配置下，如果5分钟内至少有1万个键被改动，或者15分钟内至少有10个键被改动，或者1小时内至少有1个键被改动，Redis才会触发一次快照保存，这意味着，如果你的服务器在最后一次成功快照后、下一次触发条件满足前突然宕机，那么这期间的所有数据改动就全部丢失了，这个时间窗口内的数据是非常脆弱的。

AOF虽然更安全（可以配置为每秒钟同步一次到磁盘），但它记录的是操作日志，文件会无限增长，为了解决这个问题，Redis提供了AOF重写机制来压缩文件，但重写的过程是fork一个子进程来完成的，如果你的Redis实例内存占用非常大，比如有20个G，那么fork操作可能会非常耗时，甚至达到秒级，在这个过程中，主进程如果还在高并发地写入，就可能导致服务器短暂停顿，影响性能，监控AOF重写的进度和频率很重要。

最要命的是,很多人会同时开启RDB和AOF，以为双保险，但Redis重启恢复数据时，默认会优先加载AOF文件，如果你的AOF文件在某个时刻损坏了（比如磁盘错误），那么Redis会启动失败，你连服务都起不来，这时候你可能需要用到Redis自带的redis-check-aof工具来修复AOF文件，但这个修复过程可能并不完美。

内存管理：你以为没满其实可能炸了

Redis是基于内存的,内存满了会是个大问题，虽然你可以设置最大内存限制和淘汰策略（比如LRU，删除最近最少使用的键），但有几个细节容易被忽略。

一个是,你设置的最大内存限制，Redis实际使用内存可能会略微超过这个值，因为Redis需要额外内存来维护自身的数据结构、客户端缓冲区等，如果内存增长太快，可能还没来得及触发淘汰机制，就已经因为轻微超限而被操作系统强制杀掉了。

另一个更大的坑是,当内存快满时，频繁的键淘汰操作本身会严重影响性能，因为每次写入新数据可能都需要先执行一个删除旧数据的操作，这会增加请求的响应时间，更可怕的是，如果淘汰策略设置的是allkeys-lru之类的，Redis需要近似LRU算法去采样和淘汰，这个计算过程在数据量大的时候也是有开销的，不要等到内存快用尽才去扩容，需要设置一个警戒水位线并做好监控。

删除大量大的键（比如一个包含百万元素的Hash键）也可能导致服务器短暂卡顿，因为Redis是单线程的，删除工作会阻塞其他所有命令，建议用SCAN命令加DEL分批删除。

主从复制：你以为同步了其实可能有延迟

用了主从复制做高可用,但主从之间的数据同步是异步的，这意味着，当客户端向主节点写入数据后，主节点会立即返回成功，然后再异步地将写命令发送给从节点。

如果在数据还没同步到从节点的时候,主节点突然宕机了，这时即使你通过哨兵（Sentinel）或者集群模式快速切换到了从节点，那个还没来得及同步的数据就永久丢失了，这对于要求数据强一致性的场景是致命的。

在主节点压力大的时候,从节点可能会因为网络带宽或者自身处理能力不足，导致复制延迟（Replication Lag）变得很大，从节点上的数据会远远落后于主节点，如果你的应用不小心从这样的从节点上读取了数据，读到的就是过时的旧数据，监控主从延迟是关键。

键的过期删除：你以为到期就没了其实可能还在

Redis有两种删除过期键的策略：惰性删除和定期删除。

• 惰性删除：只有当客户端尝试访问一个键时，Redis才会检查它是否过期，如果过期就删除，这意味着，如果一个键已经过期了，但一直没人来读它，那么这个键及其占用的内存就会一直存在，成了“垃圾”。
• 定期删除：Redis会每隔一段时间随机抽查一些设置了过期时间的键，并删除其中已过期的。

这带来的问题是,过期键的清理不是实时的，如果你的系统中有大量键在同一时刻过期，并且之后再也没有被访问过，那么定期删除可能一时半会儿清理不完，这会导致内存中堆积大量本应被释放的空间，造成内存浪费，甚至可能让你误以为内存泄漏了。

性能陷阱：你以为快的命令可能很慢

Redis以快著称,但使用不当也会慢，最经典的例子是KEYS命令，这个命令会遍历数据库中的所有键来匹配模式，当键的数量达到百万、千万级别时，这个操作会阻塞Redis服务器好几秒钟，导致所有其他请求全部超时，生产环境绝对禁止使用KEYS，应该用SCAN命令代替，它虽然慢，但是非阻塞的、分批返回。

类似地,对于大的集合（Set）、列表（List）、哈希（Hash）进行操作，比如获取一个包含十万个元素的整个List（LRANGE key 0 -1），或者计算一个大集合的交集（SINTER），都会非常耗时，因为它们需要一次性处理大量数据，在设计数据结构时，要尽量避免单个键对应的值过大。

网络与配置：基础但容易出问题

Redis的默认配置是为了安全起见,性能上可能不是最优的。tcp-keepalive默认是300秒，这个时间有点长，如果中间的网络设备需要清理空闲连接，可能会导致连接意外断开，可以适当调小这个值。

Redis默认的最大连接数（maxclients）是10000，你需要确保这个值大于你的客户端可能创建的最大连接数总和，否则新连接会被拒绝，操作系统的最大文件描述符限制（ulimit -n）也要相应调高，因为每个TCP连接都会占用一个文件描述符。

这些细节和坑,很多都是在实际生产环境中遇到问题后才被深刻理解的，用好Redis不仅仅是会使用几个命令，更重要的是理解其内部机制和在不同场景下的表现，并配合完善的监控和告警系统。