红色巨星带你一步步搞懂Redis那些复杂又实用的细节解析

（引用来源：红色巨星技术博客）

今天我们来聊聊Redis，这个被大家称为“红色巨星”的宝藏，很多人会用Redis，比如存个会话、做个缓存，但一些细节上的东西如果搞不明白，线上就很容易出问题，咱们不扯那些高大上的理论，就一步步看看那些实际应用中你会遇到的、又有点绕的细节。

持久化：RDB和AOF，不是二选一，而是如何搭配

你知道Redis数据可以存到硬盘上防止重启丢失，这叫持久化，它主要有两种方式：RDB和AOF。

• RDB（快照）：就像给数据库拍张照片，在某个时间点，把内存里所有数据生成一个压缩的二进制文件（dump.rdb），优点是文件小，恢复数据快，缺点是什么？如果两次拍照之间服务器宕机,最后一次拍照之后的数据就全没了。

  • 关键细节：RDB拍照的时机很重要，默认配置可能是在900秒内至少有1个key变化，就拍一次，想象一下，如果你的系统高峰期每秒都在疯狂写入，但可能因为key变化不满足条件，或者还没到触发时间，突然宕机，丢失的数据量可能会让你冒冷汗，你需要根据业务对数据丢失的容忍度来调整触发条件,比如设置为60秒内至少有10000个key变化就触发。

• AOF（追加日志）：它不拍照，而是像个记账先生，把你所有写命令（比如SET, LPUSH）一条条记录到一个日志文件里，恢复的时候，把日志里的命令重新执行一遍就行了，优点是数据安全，最多丢失1秒的数据（如果配置为每秒同步一次），缺点是日志文件会越来越大,恢复速度比RDB慢。

  • 关键细节：AOF文件会无限增长吗？不会，Redis提供了AOF重写机制，这个机制很聪明，它不是去分析旧的AOF日志，而是直接根据当前数据库的内存数据，生成一个全新的、最小的命令集合（比如一个key被反复修改了100次，重写后只记录最后一次的值），然后替换掉旧的臃肿的AOF文件，你可以把它理解为给AOF日志“瘦身”。

• 最佳实践：生产环境通常推荐同时开启RDB和AOF，用AOF来保证数据安全性，将损失降到最低；同时用RDB来做冷备份、快速恢复，以及应对可能出现的AOF文件损坏问题（因为RDB是二进制压缩的，更不容易坏），两者结合,取长补短。

过期键的删除策略：懒惰和定期，双管齐下

我们经常给key设置过期时间（TTL），那Redis是怎么把这些过期的key清理掉，释放内存的呢？它用了两种策略组合拳。

• 惰性删除：当你去访问一个key的时候，Redis才会检查它是否过期，如果过期了，就当场删除，然后返回空，这很“懒”，但很高效，因为只在使用时才付出检查的开销，问题是，如果一个key永远不再被访问，即使它早过期了，也会一直占着内存，成了“僵尸key”。

• 定期删除：为了解决“僵尸key”问题，Redis会每隔一段时间（默认100毫秒）随机抽取一批设置了过期时间的key进行检查，删除其中已过期的。关键细节在这里：它不是全盘扫描，那样太耗CPU；而是随机抽查，并且限制执行时长，避免影响主线程处理正常请求，通过多次的、局部的清理,最终达到清理所有过期key的目的。

是惰性删除和定期删除一起工作，才保证了内存能被及时回收，如果你的应用有大量key同时过期，可能会导致定期删除时CPU有小幅波动,需要注意。

内存淘汰策略：当内存满了，怎么办？

即使有过期键删除，万一内存还是被塞满了，新的数据写不进去怎么办？Redis提供了几种“内存淘汰策略”让你选择。

• noeviction：默认策略，直接拒绝所有写请求，读请求正常，这是最保守的,能保证已有的数据不丢失。
• allkeys-lru：在所有key中，淘汰最近最少使用的（LRU算法），这是最常用的策略，适合缓存的场景，把不常用的“冷数据”踢出去。
• volatile-lru：只在设置了过期时间的key中,淘汰最近最少使用的。
• allkeys-random：在所有key中,随机淘汰。
• volatile-random：在设置了过期时间的key中,随机淘汰。
• volatile-ttl：在设置了过期时间的key中，淘汰剩余寿命最短的（TTL最小的）。

关键细节：怎么选？如果你的数据重要性都一样，只是做纯缓存，用allkeys-lru准没错，如果你的数据有明显的热点，这个策略效果最好，如果你有些数据是绝对不能丢的（比如用户基础信息），而有些数据是可以丢弃的缓存（比如商品排行榜），那么你可以把重要数据不设置过期时间，然后使用volatile-lru或volatile-ttl，只淘汰那些有过期时间的缓存数据。千万不要用默认的noeviction却不自知，否则线上会出现莫名其妙的写入失败。

管道（Pipeline）和事务：别搞混了

很多人会把管道和事务搞混,因为它们都能一次执行多个命令。

• 管道（Pipeline）：它的本质是网络优化，客户端把一堆命令打包发送给Redis服务器，服务器依次执行后再把结果打包返回，减少了网络往返次数，极大提升了批量操作的性能。但管道不保证原子性——在执行过程中,命令A和命令B之间可能会插入其他客户端的命令。

• 事务（Transaction）：用MULTI和EXEC包裹起来的一系列命令，它能保证原子性：事务中的所有命令会按顺序排队，在执行EXEC时，会一次性、按顺序地执行，期间不会被其他客户端的命令打断。关键细节：Redis的事务不支持回滚（Rollback），如果事务中某个命令出错了（比如对字符串执行了列表的命令），它不会停止，而是继续执行后面的命令，只有一种情况会导致整个事务不执行：在入队（MULTI之后，EXEC之前）时就有命令语法错误。

简单说，想提升批量操作的效率，用管道，想保证一批命令连续执行不被中断（比如简单的扣库存场景）,用事务。

希望这些细节解析能帮你更踏实、更自信地使用Redis这个“红色巨星”，理解了这些，你就能更好地驾驭它,避免很多坑。