Redis那些底层细节，聊聊怎么让数据存储又快又稳

主要参考自《Redis设计与实现》一书、Redis官方文档以及部分技术博客的深度解析文章）

Redis之所以能这么快，这么稳，核心在于它在内存操作的基础上，精心设计了一套高效的底层数据结构和一套保证稳定性的持久化与高可用机制，咱们就聊聊这些不怎么被普通使用者关注,但又至关重要的细节。

速度的秘密：不仅仅是内存，更是精巧的数据结构

大家都知道Redis快是因为数据放在内存里，但内存只是舞台，真正表演的是那些高效的数据结构，Redis不是简单地把数据扔进内存就完事了，它为不同的数据类型和场景设计了专属的“小仓库”，存取路径极短,效率极高。

1. 简单动态字符串（SDS）：Redis没有直接使用C语言自带的字符串（以空字符\0结尾的字符数组），而是自己搞了一个叫SDS的结构，它有什么好处呢？它记录了字符串的长度，获取字符串长度的时间是固定的（O(1)），而C字符串需要遍历整个字符串，它避免了缓冲区溢出，在进行字符串拼接时，会先检查空间是否足够，不够会自动扩容，它减少了内存重分配次数，采用了“预分配”策略，比如你追加一个字符串，SDS不仅会分配刚好够用的空间，还会多分配一些空闲空间，下次再追加时如果空间够就直接用，不用再申请了，这种“空间换时间”的思想在Redis里很常见。

2. 字典（Hash Table）的巧妙之处：Redis的键值对存储，以及整个Redis数据库本身，都是用字典实现的，它的字典实现用了两个核心技巧来保证高效，一是渐进式rehash：当哈希表需要扩容时，Redis不会一次性把所有数据从旧表搬到新表（那样会导致服务瞬间卡顿），而是分批进行，在rehash期间，会同时使用新旧两个哈希表，查找时会查两个表，而新增的键值对只会存到新表，这样就把一次性的巨大开销，平摊到了后续的多次请求中，保证了服务的响应速度，二是哈希算法与冲突解决：Redis使用MurmurHash2这种随机分布性很好的算法来计算键的哈希值，尽量减少冲突，万一发生冲突，它采用“链地址法”来解决,就是把哈希值相同的键通过一个链表连接起来。

   

3. 压缩列表（ziplist）和快速列表（quicklist）：对于列表（List）这种数据类型，在元素数量少、元素体积小的时候，Redis不会直接用链表（因为链表的每个节点都有前后指针，占用空间大），而是使用一种叫“压缩列表”的紧凑结构，它是一块连续的内存，把所有元素紧挨着存放，极大地节省了内存，但当数据量变大时，压缩列表插入删除的效率会变低，所以Redis后来引入了快速列表（quicklist），它是压缩列表和双向链表的结合体，将一个大的压缩列表拆分成多个小压缩列表，再用双向指针连接起来，这样既保留了压缩列表节省内存的优点，又避免了大型压缩列表性能低下的问题，这种“看菜吃饭”，根据数据大小动态选择底层结构的设计,是Redis高效的关键。

4. 跳跃表（skiplist）：有序集合（Sorted Set）的核心数据结构就是跳跃表，它可以理解为一种“多层链表”，最底层是完整的链表，上面每一层都是下面一层的“快速通道”，查找时从最上层开始，能跳就跳，不能跳再降一层，这样搜索效率可以媲美平衡树,但实现起来比平衡树简单得多。

稳定的基石：数据持久化与高可用

光快不行，万一服务器断电，内存数据就全丢了，所以Redis提供了两种持久化机制,把内存数据写到硬盘上。

1. RDB（快照）：就像给数据库拍一张全景照片，Redis会定期（可配置）将整个数据集生成一个紧凑的二进制文件（dump.rdb），优点是文件小，恢复速度快，适合做灾难恢复，缺点是可能会丢失最后一次快照之后的数据（比如5分钟备份一次，那么最多可能丢失5分钟的数据）。

2. AOF（追加日志）：更像是一本记录所有写操作的流水账，每次执行一个写命令，Redis就会把这个命令追加到AOF文件的末尾，当Redis重启时，会重新执行一遍AOF文件里的所有命令，来恢复数据，优点是数据安全性高，可以配置为每秒同步一次，甚至每条命令都同步，最多只丢失一秒的数据，缺点是文件通常比RDB大,恢复速度慢。

生产环境中，通常是两者结合使用：用AOF来保证数据不丢失，作为数据恢复的第一选择；同时定期用RDB做一个冷备，因为RDB文件更小,便于归档和快速恢复。

3. 主从复制与哨兵（Sentinel）：为了保证服务不中断，Redis提供了主从架构，一个主节点（Master）负责写，多个从节点（Slave）负责读和备份，主节点会把数据变化同步给从节点，Redis哨兵是一个独立的进程，它负责监控主节点是否活着，如果主节点挂了，哨兵会自动从从节点中选举出一个新的主节点，让应用方无缝切换过去,从而实现高可用。

Redis的“快”源于它对内存的极致利用和精巧多变的数据结构，针对不同场景选择最优解；而“稳”则依赖于其可配置的持久化策略和自动故障转移的高可用架构，理解这些底层细节，能帮助我们更好地配置和使用Redis，让它真正成为应用中又快又稳的“瑞士军刀”。