红色智慧带你慢慢摸透Redis，系统那些复杂又实用的东西讲讲

网络上流传的Redis实践经验总结与开发者社区分享）

红色智慧带你慢慢摸透Redis,系统那些复杂又实用的东西讲讲，这个“红色智慧”不是说颜色，更像是一种接地气的、在实践中摸爬滚打出来的聪明劲儿，Redis这东西，你刚学的时候觉得就是个缓存，set、get，太简单了，但真想把它用好了，用到系统里不出毛病，还能扛住大流量，里面的门道可就深了，得慢慢摸透。

最基础也最容易栽跟头的地方,就是你把Redis当成一个永远可靠的黑盒子，很多人觉得，数据往Redis里一写，就万事大吉了，结果哪天Redis服务重启了一下，或者服务器宕机了，发现数据全没了，傻眼了，这就是没摸透Redis的持久化机制。（来源：常见运维故障分析）Redis提供了两种主要的持久化方式，RDB和AOF，RDB就像是给内存里的数据拍个快照，隔一段时间拍一张，好处是恢复起来快，文件也小，但缺点是万一在两次快照之间宕机，这段时间的数据就丢了，AOF呢，更像是写日记，把你所有的写操作命令都记录下来，这样数据更安全，丢的少，但日记本会越来越厚，恢复起来也慢，最实用的策略是什么？往往是两者结合使用，用AOF来保证数据安全性，同时定期生成RDB快照用于快速恢复和备份，你得根据业务对数据丢失的容忍度，来调整拍快照的频率和写日记的策略（fsync的配置），比如订单数据，可能一秒都丢不起，那AOF的配置就要激进一些；如果是用户访问计数，丢几分钟关系不大，那就可以用RDB，性能还好点。

接着说一个听起来高级但必须懂的概念：过期键的删除策略。（来源：Redis官方文档及源码解读）你给Redis里的key设置个过期时间，比如验证码5分钟失效，你以为是时间一到，Redis就立刻把它删了？没那么简单，Redis其实是用了两种策略结合着来，一种叫“惰性删除”，就是当客户端来访问这个key的时候，Redis才检查一下它过期没，过期了就删掉，然后返回空，这很省事，但如果过期key一直没人访问，它就永远占着内存，成了垃圾，所以还有另一种叫“定期删除”，Redis会定期（默认是每秒10次）随机抽查一些设置了过期时间的key，把过期的清理掉，但这也可能清理不彻底，所以你会遇到一种情况：明明内存显示快满了，也有很多key过期了，但内存使用率就是下不来，这时候就可能需要调整定期删除的力度，或者干脆主动触发一下内存淘汰，这就引出了下一个更复杂实用的点。

内存淘汰策略。（来源：Redis配置手册及性能调优指南）Redis内存满了，新的数据写不进去了，怎么办？这时候就要靠内存淘汰策略来决定了，默认的策略可能是noeviction，就是直接报错，不让写了，这在很多场景下不行，所以Redis给了你其他选择，比如allkeys-lru，淘汰掉最近最少使用的key；volatile-lru，只从设置了过期时间的key里淘汰最近最少用的，还有随机淘汰的（random），或者用LFU（最不经常使用）算法的，选哪个？这就用到“红色智慧”了，如果你的数据访问有热点，比如总是那20%的数据被频繁访问，那用LRU效果很好，如果你的数据访问比较平均，没什么冷热区分，那随机淘汰可能更简单有效，如果你有些关键数据是永久有效的，不能丢，那就用volatile开头的策略，只淘汰那些有过期时间的，这个选择，直接关系到你的服务在内存压力下的表现，是直接挂掉，还是丢卒保帅，平稳度过高峰。

再说说集群模式下的一个实用陷阱。（来源：分布式系统踩坑案例）当你用了Redis集群，数据会分片存放在不同的节点上，有时候你会执行一些涉及多个key的操作，比如求两个集合的交集（SINTER key1 key2），如果key1和key2恰好不在同一个节点上，这个命令就会直接报错，因为Redis集群的设计是，单个命令操作的key必须属于同一个槽（slot），这就是为什么很多聪明的做法是，在设计key的时候，使用“哈希标签”（hash tag），也就是用花括号{}把key的一部分括起来，比如user:{123}:profile和user:{123}:orders，Redis会保证这两个key被分配到同一个节点上，因为你用了相同的标签“123”，这样你就能放心地对它们进行跨key操作了，这个小技巧，不在实际集群环境里折腾一下，光看文档是很难有深刻体会的。

最后讲讲缓存那些事儿,不只是简单的读缓存。（来源：高并发系统设计模式）缓存穿透，就是疯狂请求一个根本不存在的数据，每次都穿过缓存打到数据库上，可能把数据库打垮，实用解法是，即使查不到数据，也在缓存里存个空值（比如null），并设置一个短的过期时间，这样后续请求在缓存层就返回了，保护了数据库，缓存雪崩，是指大量缓存key在同一时间点过期，导致所有请求瞬间都涌向数据库，解法是给过期时间加个随机值，让失效时间分散开，缓存击穿，是指一个非常热点的key突然过期，大量请求同时发现缓存失效，都去数据库加载数据，解法可以用互斥锁（分布式锁），只让一个请求去数据库加载，其他请求等待，这些模式，名字听起来专业，但思想很朴实，分摊压力、避免单点、快速失败”，都是红色智慧在分布式系统里的体现。

摸透Redis,就是把这些看似独立的点串联起来，从单机的持久化、内存管理，到集群的数据分布，再到应用层的缓存设计模式，每一个环节的决策，都影响着整个系统的稳定性和性能，没有银弹，只有根据自己业务的实际情况，慢慢调试、观察、优化，这才是真正的“摸透”。