Redis面试题

https://www.cnblogs.com/jianzh5/p/14499325.html

通过面试多家大型互联网企业，总结了如下的高频面试题目： 

1、redis 过期键的删除策略？

（1）定时删除:在设置键的过期时间的同时，创建一个定时器 timer). 让定时器在键的过期时间来临时，立即执行对键的删除操作。

（2）惰性删除:放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键;如果没有过期，就返回该键。

（3）定期删除:每隔一段时间程序就对数据库进行一次检查，删除里面的过期键。

2、Redus的淘汰策略

redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供6种数据淘汰策略：  

通过淘汰策略也能保证Redis中缓存的都是热点数据。 

一个客户端运行了新的命令，添加了新的数据。Redi 检查内存使用情况，如果大于 maxmemory 的限制, 则根据设定好的策略进行回收。

注意这里的 6 种机制，volatile 和 allkeys 规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的 lru、ttl 以及 random 是三种不同的淘汰策略，再加上一种 no-enviction 永不回收的策略。

使用策略规则：如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用 allkeys-lru；如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用

allkeys-random

 

3、Redis分布式锁的实现

Redis的分布式缓存特性使其成为了分布式锁的一种基础实现。通过Redis中是否存在某个锁ID，则可以判断是否上锁。为了保证判断锁是否存在的原子性，保证只有一个线程获取同一把锁，Redis有SETNX（即SET if Note Exists）和GETSET（先写新值，返回旧值，原子性操作，可以用于分辨是不是首次操作）操作。

（1）关于setnx：

将key的值设为value，当且仅当key不存在，返回值为1。

若给定的key已经存在，则setnx不做任何动作，返回值为0。 

（2）关于set：一般操作

• ex seconds - seconds：设置失效时长，单位秒
• px - milliseconds：设置失效时长，单位毫秒
• nx - key不存在时设置value，成功返回OK，失败返回(nil)
• xx - key存在时设置value，成功返回OK，失败返回(nil) 

为了防止主机宕机或网络断开之后的死锁，Redis没有ZK那种天然的实现方式，只能依赖设置超时时间来规避。所以如果使用setnx来实现分布式锁，则实现步骤如下：

• 先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。
• 如果在setnx之后，执行expire之前进程意外crash 或重启维护, 那么就需要把setnx和expire合成一条指令来用。

Redis的setnx命令是当key不存在时设置key，但setnx不能同时完成expire设置失效时长，不能保证setnx和expire的原子性。我们可以使用set命令完成setnx和expire的操作，并且这种操作是原子操作。举个例子如下：

案例：设置name=p7+，失效时长100s，不存在时设置
1.1.1.1:6379> set name p7+ ex 100 nx
OK
1.1.1.1:6379> get name
"p7+"
1.1.1.1:6379> ttl name
(integer) 94

从上面可以看出，多个命令放在同一个redis连接中并且redis是单线程的，因此上面的操作可以看成setnx和expire的结合体，是原子性的。

4、Redis的Reactor模式 

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。
因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

 

  

5、redis支持事务回滚吗？

“不支持回滚动作，redis是支持简单事务模式，只能discard，不能rollback” 

Redis在执行事务命令的时候，在命令入队的时候，Redis 就会检测事务的命令是否正确，如果不正确则会产生错误。无论之前和之后的命令都会被事务所回滚，就变为什么都没有执行。

当命令格式正确，而因为操作数据结构引起的错误，则该命令执行出现错误，而其之前和之后的命令都会被正常执行。这点和数据库很不一样，这是需注意的地方。

对于一些重要的操作，我们必须通过程序去检测数据的正确性，以保证 Redis 事务的正确执行，避免出现数据不一致的情况。 Redis 之所以保持这样简易的事务，完全是为了保证移动互联网的核心问题一性能。

6、Redis的事务机制及CAS 

watch指令在redis事物中提供了CAS的行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突，这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改，整个事物将会回滚，不执行任何动作，从而保证原子性操作，并且执行exec会得到null的回复。

7、Redis和Memcached的区别  

Redis的特性： 

(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)  

(2) 支持丰富数据类型，支持字符串、链表、哈希、集合和有序集合  

(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 

(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除 

与Memcached的区别在于： 

（1)、存储方式 Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis有部分存在硬盘上，这样能保证数据的持久性。  

（2)、数据支持类型 Memcache对数据类型支持相对简单。Redis有复杂的数据类型。  

（3)、使用底层模型不同 它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。 

Redis直接自己构建了VM(Virtual Memory)机制 ，因为一般的系统调用系统函数的话（例如java调用自己的API），会浪费一定的时间去移动和请求。  

8、缓存穿透、缓存击穿和缓存雪崩

（1）缓存穿透 

查询不存在的数据，缓存中没有数据，数据库也没有数据。因此所有的请求都访问到了数据库，给数据库造成了压力。解决方法如下：

• 采用布隆过滤器，将所有可能存在的数据，哈希到一个很大的 bitmap 中，一个一定不存在的数据会被 bitmap 拦截调，从而避免了对数据库的查询压力。
• 如果查询的数据为空，那么直接将空数据也缓存起来并设置较短的过期时间。这样下次访问的时候，就直接返回空值。

（2）缓存击穿

缓存击穿是指缓存过期之后，瞬时间并发客户端特别多查询同一条数据的情况下，导致数据库压力过大。业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，

而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，

再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。类似下面的代码： 

public String get(String key) {
    String value = redis.get(key);
    if (value == null) { // 代表缓存值过期
        // 设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { // 代表设置成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        }
        // 这个时候代表同时候的其他线程已经load db并回设到缓存了，
        // 这时候重试获取缓存值即可
        else {
            sleep(50);
            get(key); // 重试
        }
    } else {
        return value;
    }
}

（3）缓存雪崩

雪崩就是指缓存中大批量热点数据过期后系统涌入大量查询请求，因为大部分数据在Redis层已经失效，请求渗透到数据库层，大批量请求犹如洪水一般涌入，引起数据库压力造成查询堵塞甚至宕机。 

解决办法：

• 将缓存失效时间分散开，比如每个key的过期时间是随机，防止同一时间大量数据过期现象发生，这样不会出现同一时间全部请求都落在数据库层，如果缓存数据库是分布式部署，将热点数据均匀分布在不同Redis和数据库中，有效分担压力，别一个人扛。
• 让Redis数据永不过期（如果业务准许）。

9、Redis数据倾斜

1：存在bigkey：业务层避免创建bigkey，把集合类型的bigkey拆分成多个小集合，分散保存bigkey 保存了大量集合元素（集合类型），会导致这个实例的数据量增加，内存资源消耗也相应增加。bigkey 的操作一般都会造成实例 IO 线程阻塞，如果 bigkey 的访问量比较大，就会影响到这个实例上的其它请求被处理的速度。

2：slot手工分配不均匀：避免把较多的slot分配到一个实例上，进行槽的迁移

3、存在热点数据：采用带有不同key前缀的多副本方法。我们把热点数据复制多份，在每一个数据副本的 key 中增加一个随机前缀，让它和其它副本数据不会被映射到同一个 Slot 中。这样一来，热点数据既有多个副本可以同时服务请求，同时，这些副本数据的 key 又不一样，会被映射到不同的 Slot 中。在给这些 Slot 分配实例时，我们也要注意把它们分配到不同的实例上，那么，热点数据的访问压力就被分散到不同的实例上了。热点数据多副本方法只能针对只读的热点数据。如果热点数据是有读有写的话，就不适合采用多副本方法了，因为要保证多副本间的数据一致性，会带来额外的开销。 

10、为什么Redis单线程模型也能效率这么高? 

• 纯内存操作；
• 核心是基于非阻塞的IO多路复用机制；
• 底层使用C语言实现,一般来说，C 语言实现的程序"距离"操作系统更近，执行速度相对会更快；
• 单线程同时也避免了多线程的上下文频繁切换问题,预防了多线程可能产生的竞争问题。

11、Redis做异步和延时队列？ 

一般使用 list 结构作为队列，rpush 生产消息，lpop 消费消息。当 lpop 没有消息的时候，要适当 sleep 一会再重试。如果对方追问可不可以不用 sleep 呢？list 还有个指令叫 blpop，在没有消息的时候，它会阻塞住直到消息到来。如果对方追问能不能生产一次消费多次呢？使用 pub/sub 主题订阅者模式，可以实现1:N 的消息队列。 

zset是带排序的set集合，其中score属性是zset的排序字段；本文将延迟的时间+系统当前时间，作为元素的score属性的值，在while循环中，每次取zset集合中排在最前面的一个元素，通过判断该元素的score值是否大于或等于当前系统时间，来判定队列中该元素是否已达到延迟的时间。消息内容作为 key 调用 zadd 来生产消息，消费者用 zrangebyscore 指令获取 N 秒之前的数据轮询进行处理。 

12、Redis的集群策略

（1）Redis主从同步Redis的主从结构一主一从，一主多从或级联结构，复制类型可以根据是否是全量而分为全量同步和增量同步。

 （2）Redis哨兵 在主从复制实现之后，如果想对master进行监控，Redis提供了一种哨兵机制，哨兵的含义就是监控Redis系统的运行状态，并做相应的响应。Redis Sentinal 着眼于高可用，在 master 宕机时会自动将 slave 提升为master，继续提供服务。 

（3）Redis Cluster 着眼于扩展性，在单个 redis 内存不足时，使用 Cluster 进行分片存储。在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。

哨兵模式归根节点还是主从模式，在主从模式下我们可以通过增加salve节点来扩展读并发能力，但是没办法扩展写能力和存储能力，存储能力只能是master节点能够承载的上限。所以为了扩展写能力和存储能力，我们就需要引入集群模式。

 

13、Redis 的同步机制 

Redis 可以使用主从同步，从从同步。第一次同步时，主节点做一次 bgsave，并同时将后续修改操作记录到内存 buffer，待完成后将 rdb 文件全量同步到复制节点，复制节点接受完成后将 rdb 镜像加载到内存。加载完成后，再通知主节点

将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

如果出现网络闪断或者命令丢失等异常情况时，当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参数发送给主节点，要求进行部分复制操作，格式为psync {runId} {offset}。
主节点接到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+continue响应，表示可以进行部分复制；否则进行全量复制。
主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。
可以参考：https://blog.csdn.net/ioteye/article/details/90736630

14、Redis并发竞争key问题的解决

乐观锁适用于大家一起抢着改同一个key，对修改顺序没有要求的场景。

watch命令可以方便的实现乐观锁。需要注意的是，如果你的 redis 使用了数据分片（也就是使用了Redis集群）的方式，那么这个方法就不适用了。

watch命令会监视给定的每一个key，当 exec 时如果监视的任一个key自从调用watch后发生过变化，则整个事务会回滚，不执行任何动作。

 

还可以使用分布式锁。在并发量很大的情况下，可以通过消息队列进行串行化处理。这在高并发场景中是一种很常见的解决方案。 

SETEX key seconds value 将值 value 关联到 key ，并将 key 的生存时间设为 seconds (以秒为单位)。如果 key 已经存在， SETEX 命令将覆写旧值。

SETNX key value 将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。

GETSET key value。将给定 key 的值设为 value ，并返回 key 的旧值(old value)。记录每小时的网站访问数（每小时需要清零），这样就可以用getset命令来完成。

分布式锁的步骤如下： 

1. setnx(lockkey, 当前时间+过期超时时间) ，如果返回1，则获取锁成功；如果返回0则没有获取到锁，转向2。
2. get(lockkey)获取值oldExpireTime ，并将这个value值与当前的系统时间进行比较，如果小于当前系统时间，则认为这个锁已经超时，可以允许别的请求重新获取，转向3。
3. 计算newExpireTime=当前时间+过期超时时间，然后getset(lockkey, newExpireTime) 会返回当前lockkey的值currentExpireTime。
4. 判断currentExpireTime与oldExpireTime 是否相等，如果相等，说明当前getset设置成功，获取到了锁。如果不相等，说明这个锁又被别的请求获取走了，那么当前请求可以直接返回失败，或者继续重试。
5. 在获取到锁之后，当前线程可以开始自己的业务处理，当处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行delete释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理。  

15、如果事务执行一半的时候Redis宕机怎么办？

Redis有持久化机制，因为可靠性问题，我们一般使用AOF持久化。事务的所有命令也会写入AOF文件，但是如果在执行EXEC命令之前，Redis已经宕机，则AOF文件中事务不完整。使用 redis-check-aof 程序可以移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

16、Redis在项目中的哪些地方有用到?

（1）共享session在分布式系统下，服务会部署在不同的tomcat，因此多个tomcat的session无法共享，以前存储在session中的数据无法实现共享，可以用redis代替session，解决分布式系统间数据共享问题。

（2）数据缓存Redis采用内存存储，读写效率较高。我们可以把数据库的访问频率高的热点数据存储到redis中，这样用户请求时优先从redis中读取，减少数据库压力，提高并发能力。

（3）异步队列Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。而且Redis中还有pub/sub这样的专用结构，用于1对N的消息通信模式。

（4）分布式锁Redis中的乐观锁机制，可以帮助我们实现分布式锁的效果，用于解决分布式系统下的多线程安全问题

17、Redis是如何实现数据不丢失的呢？ 

Redis数据是存储在内存中的，为了保证Redis数据不丢失，那就要把数据从内存存储到磁盘上，以便在服务器重启后还能够从磁盘中恢复原有数据，这就是Redis的数据持久化。Redis数据持久化有三种方式。

• AOF 日志（Append Only File，文件追加方式）：记录所有的操作命令，并以文本的形式追加到文件中。
• RDB 快照（Redis DataBase）：将某一个时刻的内存数据，以二进制的方式写入磁盘。
• 混合持久化方式：Redis 4.0 新增了混合持久化的方式，集成了 RDB 和 AOF 的优点。 把数据以 RDB 的方式写入文件，再将后续的操作命令以 AOF 的格式存入文件，既保证了 Redis 重启速度，又降低数据丢失风险。

 AOF采用的是写后日志的方式，Redis先执行命令把数据写入内存，然后再记录日志到文件中。AOF日志记录的是操作命令，不是实际的数据，如果采用AOF方法做故障恢复时需要将全量日志都执行一遍。

  

RDB采用的是内存快照的方式，它记录的是某一时刻的数据，而不是操作，所以采用RDB方法做故障恢复时只需要直接把RDB文件读入内存即可，实现快速恢复

18、AOF采用的是 “写后日志” 的方式，我们平时用的MySQL则采用的是 “写前日志”，那 Redis为什么要先执行命令，再把数据写入日志呢？

 这个主要是由于Redis在写入日志之前，不对命令进行语法检查，所以只记录执行成功的命令，避免出现记录错误命令的情况，而且在命令执行后再写日志不会阻塞当前的写操作。 

后写日志主要有两个风险可能会发生：

• 数据可能会丢失： 如果 Redis 刚执行完命令，此时发生故障宕机，会导致这条命令存在丢失的风险。
• 可能阻塞其他操作： AOF 日志其实也是在主线程中执行，所以当 Redis 把日志文件写入磁盘的时候，还是会阻塞后续的操作无法执行。 

RDB做快照时会阻塞线程吗？

Redis 提供了两个命令来生成 RDB 快照文件，分别是 save 和 bgsave。save 命令在主线程中执行，会导致阻塞。而 bgsave 命令则会创建一个子进程，用于写入 RDB 文件的操作，避免了对主线程的阻塞，这也是 Redis RDB 的默认配置。

RDB 做快照的时候数据能修改吗？

save是同步的会阻塞客户端命令，bgsave的时候是可以修改的。

19、为什么bgsave要创建一个子进程，而不是线程？

(1)Redis RDB持久化机制会阻塞主进程，这样主进程就无法响应客户端请求。

(2)我们知道Redis对客户端响应请求的工作模型是单进程和单线程的，如果在主进程内启动一个线程，这样会造成对数据的竞争条件，为了避免使用锁降低性能。

19、Redis怎么预热

Redis的预热主要还是找到热Key。

• Redis-cli --hotkyes 查询热点key，只适用于缓存淘汰策略是lru的时候。redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。
• 实时监控Redis热key，如写一个后台线程，每个一段时间，比如一分钟，将排名前1000的热数据list
• 通过大数据的方式筛选

找出了热点key之后，再根据自己的业务逻辑，到DB中查询数据填充到Redis中去。不过既然考虑预热，那么访问量、数据量都会很大，因此要考虑并行（提高预热速度）+ 限速（并发量太大的话，DB也处理不过来）。

20、redis管道用过么，用来做什么，它的原理是，保证原子性么，和事务的区别，redis事务保证原子性么  

pipeline机制，原理还是一样，将命令集整合起来通过。一条request请求一起送过去，由redis内部fake出一个client做批量执行操作。非原子性

对于命令格式有原子性，但是数据结构有问题时是不能回滚的，所以没有原子性。

21、redis数据结构，排行榜的实现 

使用ZSet结构，其实的score可以用double类型，但是要注意是从小到大排序，如果要从大到小排序，则需要取反。

22、缓存高可用:缓存如何保证高可用？

redis sentinel模式来解决主从redis部署时的高可用问题，它可以在主节点挂了以后自动将从节点提升为主节点，保证整体集群的可用性。

redis sentinel也是集群部署的，这样可以避免sentinel节点挂掉后造成无法自动故障恢复的问题，每一个sentinel节点都是无状态的。在sentinel会配置master的地址，sentinel会时刻监控master的状态，当发现master在配置的时间间隔内无响应，就认为master已经挂了，sentinel会从从节点中选取一个提升为主节点，并且把所有其他的从节点作为新主的从节点。sentinel集群内部在仲裁的时候，会根据配置的值来决定当有几个sentinel节点认为主挂掉可以做主从切换的操作，也就是集群内部需要对缓存节点的状态达成一致才行。

23、redis 集群模式的工作原理能说一下么？

采用redis-cluster架构正是满足这种分布式存储要求的集群的一种体现。redis-cluster架构中，被设计成共有16384个hash slot。每个master分得一部分slot，其算法为：hash_slot = crc16(key) mod 16384 ，这就找到对应slot。采用hash slot的算法，实际上是解决了redis-cluster架构下，有多个master节点的时候，数据如何分布到这些节点上去。key是可用key，如果有{}则取{}内的作为可用key，否则整个可以是可用key。群集至少需要3主3从，且每个实例使用不同的配置文件。
在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。
在redis的官方文档中，对redis-cluster架构上，有这样的说明：在cluster架构下，默认的，一般redis-master用于接收读写，而redis-slave则用于备份，当有请求是在向slave发起时，会直接重定向到对应key所在的master来处理。但如果不介意读取的是redis-cluster中有可能过期的数据并且对写请求不感兴趣时，则亦可通过readonly命令，将slave设置成可读，然后通过slave获取相关的key，达到读写分离。

24、在集群模式下，redis 的 key 是如何寻址的？

redis cluster 的 hash slot 算法
redis cluster 有固定的 16384 个 hash slot，对每个 key 计算 CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。
redis cluster 中每个 master 都会持有部分 slot，比如有 3 个 master，那么可能每个 master 持有 5000 多个 hash slot。hash slot 让 node 的增加和移除很简单，增加一个 master，就将其他 master 的 hash slot 移动部分过去，减少一个 master，就将它的 hash slot 移动到其他 master 上去。移动 hash slot 的成本是非常低的。客户端的 api，可以对指定的数据，让他们走同一个 hash slot，通过 hash tag 来实现。

25、分布式寻址都有哪些算法？了解一致性 hash 算法吗？

hash算法、一致性hash算法和hash slot

hash slot即hash槽。redis cluster采用的正式这种hash槽算法实现的寻址。以redis cluster为例。
在redis cluster中固定的存在16384个hash slot。

hash slot = CRC16（key）%16384； 

 #CRC16算法可以简单的理解为一种hash算法。详见度娘。
这样我们就能找到key对应的hash slot。其实按照我的理解，hash slot就是在寻址和节点间加了一层映射关系。当节点动态变化，只需要改变hash slot ==> 节点的映射，然后只需要迁移指定slot到新添加的节点即可。既减少了hash寻址带来的数据全量迁移问题，相对一致性hash也使得负载均衡效果更加明显。

可参考文章：https://www.cnblogs.com/hello-shf/p/12079986.html

27、那redis是单线程的，为什么6.0版本还要引入多线程呢？ 

Redis6.0引入的多线程部分，实际上只是用来处理网络数据的读写和协议解析，执行命令仍然是单一工作线程。开启多线程除了可以减少由于网络I/O等待造成的影响，还可以充分利用CPU的多核优势。Redis6.0也不例外，在此处增加了多线程来处理网络数据，以此来提高Redis的吞吐量。当然相关的命令处理还是单线程运行，不存在多线程下并发访问带来的种种问题。

Redis可以使用del命令删除一个元素，如果这个元素非常大，可能占据了几十兆或者是几百兆，那么在短时间内是不能完成的，这样一来就需要多线程的异步支持。 

28、Redis的字典扩容（相当于hashmap，采用数组加链表的结构）

在扩容和收缩的时候，如果哈希字典中有很多元素，一次性将这些键全部rehash到ht[1]的话，可能会导致服务器在一段时间内停止服务。所以，采用渐进式rehash的方式，

大致过程是这样的： 

ht[0]，是存放数据的table，作为非扩容时容器。

ht[1]，只有正在进行扩容时才会使用，它也是存放数据的table，长度为ht[0]的两倍。

扩容时，单线程A负责把数据从ht[0] copy到ht[1] 中。如果这时有其他线程

进行读操作：会先去ht[0]中找，找不到再去ht[1]中找。

进行写操作：直接写在ht[1]中。

进行删除操作：与读类似。

当然这过程中会设计到一系列的锁来保证同步性，不过这并不是本文的重点。

渐进式rehash采用的是一种分而治之的方式，将rehash的操作分摊在每一个的访问中，避免集中式rehash而带来的庞大计算量。

需要注意的是在渐进式rehash的过程，如果有增删改查操作时，如果index大于rehashindex，访问ht[0]，否则访问ht[1]。 

扩缩容的条件
正常情况下，当 hash 表中 元素的个数等于第一维数组的长度时，就会开始扩容，扩容的新数组是 原数组大小的 2 倍。不过如果 Redis 正在做 bgsave(持久化命令)，为了减少内存也得过多分离，Redis 尽量不去扩容，但是如果 hash 表非常满了，达到了第一维数组长度的 5 倍了，这个时候就会 强制扩容。 

当 hash 表因为元素逐渐被删除变得越来越稀疏时，Redis 会对 hash 表进行缩容来减少 hash 表的第一维数组空间占用。所用的条件是 元素个数低于数组长度的 10%，缩容不会考虑 Redis 是否在做 bgsave。 

 29、string、zset等的底层实现

在C语言中，字符串是通过字符数组实现的，即char[]，那么Redis对于字符串的实现是不是也是基于字符数组吗？不是的，Redis对字符串的处理是通过SDS(Simple Dynamic String)实现的。SDS的结构如下： 

struct sdshdr{
    //记录buf数组已使用字节的数量
    //等于SDS所保存字符串的长度
    int length; 
    //记录buf数组未使用字节的数量
    int free;
    //buf数组
    char[] buf;
};

与C字符串的区别如下：

  

zset底层实现为双向链表+跳跃表，当元素数量小于128个且所有member的长度都小于64字节时使用双向链表。 

Redis使用跳跃表作为有序集合键的底层实现之一,如果一个有序集合包含的元素数量比较多,又或者有序集合中元素的成员是比较长的字符串时, Redis就会使用跳跃表来作为有序集合健的底层实现。跳跃表在链表的基础上增加了多级索引以提升查找的效率，但其是一个空间换时间的方案，必然会带来一个问题——索引是占内存的。原始链表中存储的有可能是很大的对象，而索引结点只需要存储关键值值和几个指针，并不需要存储对象，因此当节点本身比较大或者元素数量比较多的时候，其优势必然会被放大，而缺点则可以忽略。 

在跳表中，要查找区间的元素，我们只要定位到两个区间端点在最低层级的位置，然后按顺序遍历元素就可以了，非常高效。而红黑树只能定位到端点后，再从首位置开始每次都要查找后继节点，相对来说是比较耗时的。此外，跳表实现起来很容易且易读，红黑树实现起来相对困难，所以Redis选择使用跳表来实现有序集合。 

ziplist 编码的 Zset 使用紧挨在一起的压缩列表节点来保存，第一个节点保存 member，第二个保存 score。ziplist 内的集合元素按 score 从小到大排序，其实质是一个双向链表。

可参考：https://www.cnblogs.com/hunternet/p/9989771.html