Redis深度探秘，火力全开剖析那些你没注意的细节和原理

Redis深度探秘，火力全开剖析那些你没注意的细节和原理

很多人用Redis，觉得就是个简单的键值对缓存，set和get就完事了，但真要把它用得好、用得稳，水面下的冰山才是关键，今天我们就抛开那些基础操作,直接钻到那些容易被忽略的细节和核心原理里去。

内存都去哪儿了？不只是你的数据那么简单

你以为你存一个10字节的字符串，Redis就只占10字节？太天真了，根据Redis官方文档（《Redis持久化与内存优化》）中的解释，Redis每个键值对都是一个“对象”，比如你set一个字符串键，Redis不仅会存你的字符串值，还会创建两个对象：一个键对象（key object）和一个值对象（value object），每个对象都有复杂的结构头信息，比如类型、编码方式、引用计数、最后一次访问时间等等，这些元数据本身就要占不少内存，当你存海量小键值对时，这些额外的开销甚至会超过数据本身的大小，这就是为什么有时候你算着数据量不大,但Redis内存却蹭蹭往上涨的原因之一。

持久化的“默契”与“纠结”：RDB和AOF的深层博弈

大家都知道Redis有RDB快照和AOF日志两种持久化方式，但它们的内部协同和潜在风险,才是精髓。

• RDB的快照，并不是“秒拍”：当你执行bgsave，Redis会fork出一个子进程来干这个活，fork的瞬间，操作系统会使用写时复制（Copy-on-Write）机制，这时候，如果父进程（主进程）有大量数据写入，操作系统就需要为子进程复制需要修改的内存页，这会导致父子进程共同占用大量内存，如果你的机器内存本来就紧张，这个瞬间可能会触发系统OOM（内存耗尽），直接把Redis给kill掉，这不是Redis的bug，而是Linux内存管理机制下的一个“坑”。
• AOF的日志，写入的“障眼法”：我们常听说AOF配置为appendfsync everysec时，是每秒刷一次盘，性能和数据安全兼顾，但这里有个细节（在《Redis设计与实现》一书中有深入描述）：主线程只是把写命令写到AOF缓冲区，然后由一个专门的线程每秒一次将缓冲区内容写入到AOF文件，并调用fsync强制刷盘，问题是，这“一秒”内积累的写命令如果非常多，这个同步操作可能会阻塞主线程，因为主线程需要等待文件同步完成才能清空缓冲区继续写入，虽然概率低，但在写入峰值时,这可能导致短暂的服务停顿。

管道（Pipeline）不是万能药，用不好会“中毒”

用管道（pipeline）打包命令能极大提升性能，因为它减少了网络往返时间,但很多人忽略了它的两个副作用：

1. 缓冲区背压（Backpressure）：你一次性通过管道塞给Redis十万个命令，Redis会一口气把这些命令全部读进内存的缓冲区，然后逐个执行，这会瞬间占用大量内存，Redis是单线程执行命令的，它处理这十万个命令期间，无法处理任何新来的请求，导致客户端感觉Redis“卡住”了,这会给网络和Redis内部缓冲区带来巨大压力。
2. 原子性的幻觉：管道内的命令不是原子执行的，它只是打包发送，但执行过程中，可能会被其他客户端的命令插队，如果你有一组需要原子性执行的命令，应该使用Lua脚本,而不是管道。

惰性删除和内存驱逐的“后知后觉”

你给一个键设置了过期时间（TTL），时间一到，这个键是不是立刻就被删除了？大部分情况下，不是的，Redis采用的是惰性删除和定期删除相结合的策略。

• 惰性删除：意思是，只有当某个客户端尝试访问这个已经过期的键时，Redis才会检查它是否过期，如果过期就当场删除并返回空，这意味着，如果永远没人来访问这个过期的键，它就会一直占着内存，直到天荒地老，成为一个“幽灵键”。
• 定期删除：Redis会每隔一段时间（默认100毫秒）随机抽查一批设置了过期时间的键，删除其中已过期的，但这只是抽样,不可能全部检查。

这就导致一个问题：如果你的系统里有海量的键同时过期，而之后又没有人访问它们，这些键就不会被及时清理，当内存不足触发淘汰机制时（如LRU），Redis可能是在一堆本该过期却被“惰性”留下的键中做淘汰，这会影响淘汰策略的准确性,可能导致更重要的数据被误删。

主从复制，增量同步的“神之一手”

主从复制时，如果从库断开时间不长，重新连接后可以进行部分重同步（PSYNC），而不需要全量同步，这个功能的灵魂在于主节点维护的一个复制积压缓冲区（Replication Backlog）。

这个缓冲区是一个固定大小的队列，主节点不仅把写命令发给从库，还会在这个缓冲区里存一份，当从库断线重连后，会把自己的复制偏移量发给主库，主库一看，这个偏移量之后的数据还在我的积压缓冲区里躺着呢,就直接把从偏移量到当前偏移量之间的命令发给从库就行了。

但这里有个关键细节：这个缓冲区大小是固定的，如果从库断开太久，它需要的偏移量对应的数据已经从缓冲区里被挤出去了，那就对不起，只能进行耗时的全量同步了，根据你的网络情况和可容忍的从库下线时间，合理设置repl-backlog-size参数至关重要。

Redis的简单只是表象，其内部在内存管理、持久化、网络通信、数据淘汰等方面充满了各种权衡和精妙的设计，不了解这些细节，你可能会长期处于“能用但不知道为什么出问题”的状态，只有深入这些原理，才能真正驾驭Redis，让它在你手中发挥出最大的威力,同时避免掉入各种意想不到的陷阱。