Java面试点汇总

所有 Redis 对象都具有对象头

Redis 对象头的总大小为16 bytes

底层结构为动态字符串（SDS）

字符串在数组空间不足时，会进行扩容操作，它会分配一个新数组，将原有旧数组的内容拷贝到新数组中，此时会产生内存分配和复制的开销

字符串长度不超过44bytes时，SDS 使用 embstr 形式存储，当字符串长度超过44bytes时，SDS 使用 raw 形式存储（44bytes临界点根据Redis对象头决定）

在列表元素较少的情况下，list底层采用压缩列表（ziplist）进行存储，当数据量比较多的时候，list底层则改用快速列表（quicklist）进行存储

ziplist 是一块连续的内存空间，元素之间紧挨着存储，没有任何冗余空隙

ziplist 在插入元素时会因为扩容时重新分配内存而导致影响性能，ziplist 在修改和删除元素时也会因为级联更新而造成性能损耗

quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段使用 ziplist 让存储紧凑，多个 ziplist 之间使用双向指针串接起来

quicklist 内部默认单个 ziplist 长度为8KB，超出这个字节数，就会另起一个 ziplist

quicklist 默认的压缩深度为0，也就是不压缩。为了支持快速的 push/pop 操作，quicklist 的首位两个 ziplist 不压缩，此时压缩深度就是1。如果压缩深度为2，就表示 quicklist 的首尾第一个 ziplist 以及首尾第二个 ziplist 都不压缩

hash 结构底层使用字典（dict）进行存储，除 hash 外，整个 Redis 数据库的所有 key 和 value 也组成了一个全局字典，还有带过期时间的 key 集合也是一个字典。zset 集合中存储 value 和 score 值的映射关系也是通过字典结构实现的

字典结构内部包含两个 hashtable，通常情况下只有一个 hashtable 是有值的，但是在字典扩容缩容时，需要分配新的 hashtable，然后进行渐进式搬迁，这时候两个 hashtable 存储的分别是旧的 hashtable 和新的 hashtable。待搬迁后，旧的 hashtable 被删除，新的 hashtable 取而代之

hashtable 结构类似 Java 语言的 HashMap，第一维是数组，第二维是链表

Redis 使用渐进式 rehash 实现字典的扩容

正常情况下，当 hash 表中元素的个数等于第一维数组的长度时，就开始扩容，扩容的新数组是原数组大小的2倍。如果 Redis 正在做 bgsave，为了减少内存页的过多分离（Copy On Write），Redis 尽量不去扩容，但是如果 hash 表元素的个数已经达到了第一维数组长度的5倍，就会进行强制扩容。

hash 表缩容的条件是元素个数低于数组长度的10%，缩容不会考虑 Redis 是否正在做 bgsave 操作

set 内部实现相当于一个特殊的字典，字典中所有的 value 都是一个值 NULL

zset 底层由一个 hash 来存储 value 和 score 的对应关系，另外，需要 skiplist 提供按照 score 进行排序

原理：使用操作系统的多进程 COW（Copy On Write），Redis 在持久化时调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进程去管理，父进程继续处理客户端请求。子进程不会修改现有内存的数据结构，只对数据结构进行遍历读取

原理：记录 Redis 的顺序指令序列

加锁：使用 setnx 指令

解锁：使用 del 指令

产生原因：加锁后，如果逻辑执行中出现异常，会导致 del 指令没有调用，产生死锁

解决方案1：在拿到锁之后，使用 expire 命令给锁加上一个过期时间

不足之处：在 setnx 命令和 expire 命令执行期间服务器突然挂掉，导致 expire 命令无法执行，仍然会产生死锁（核心问题在于 setnx 和 expire 操作不是原子操作）

解决方案2：（1）使用 set :key true ex :expiretime nx 命令，该命令是一个原子命令 （2）使用 Lua 脚本，Lua 脚本可以保证操作的原子性

产生原因：在加锁和释放锁之间的执行逻辑太长，以至于超出了锁的超时限制

解决方案：（1）分布式锁尽量不要应用于执行时间太长的事务，可以将事务进行拆分（2）可以适当将超时时间设置的长一些，保证逻辑正常执行完毕

解决方案：使用线程的 ThreadLocal 变量存储当前持有锁的计数

产生原因：在 Sentinel 集群中，当主节点挂掉时，从节点会取而代之，但客户端上却并没有感知。此时，若第一个客户端在主节点中申请成功了一把锁，但是这把锁还没有来得及同步到从节点，主节点突然挂掉了，然后从节点变为了主节点，这个新的主节点内部没有这个锁，当另一个客户端过来请求加锁时，立即就批准了，这样就会导致系统中同样一把锁被两个客户端所持有

解决方案：Redlock算法（加锁时，向过半节点发送 set(key, value, nx=True, ex=xxx) 指令，只要半数节点 set 成功，就认为加锁成功。释放锁时，需向所有节点发送 del 指令

运算均为内存级别运算

避免了CPU时间片之间的切换

使用多路复用处理客户端连接

改变读写顺序，减少网络IO请求

对小的数据结构，采用紧凑存储形式进行压缩存储（embstr、ziplist）

数据结构调整做到极致

快照同步过程

增量同步过程

当 buffer 环形数组，因为网络状况的原因，从节点短时间内无法和主节点进行同步，造成 Redis 主节点新的指令覆盖掉之前的指令，此时会再次发起快照同步

Sentinel负责持续监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。客户端来连接集群时，会首先连接Sentinel，会通过Sentinel来查询主节点的地址，然后再连接主节点进行数据交互。当主节点发生故障时，客户端会重新向Sentinel要地址，Sentinel会将最新的主节点地址告诉客户端

故障切换（failover）过程

Codis 分片原理

槽位定位

跳转