Redis基础知识总结（面试必备）

Redis组件因其开源免费、出色的读写性能，备受广大互联网公司的热爱，许多公司用Redis作为缓存来抗住C端的请求，若没有Redis，许多公司的业务将不堪一击。Redis可以作为单机缓存（业务进程重启后，内容不会丢失，代替共享内存的使用），或者通过集群的方式作为服务后端的缓存、提供可无限扩展的读写能力（只要服务器资源足够），也有公司将Redis集群作为高可靠的KV存储（开启持久化选项）。在面试过程中，Redis的相关知识也是问的最多的，可以说是必问必会的知识点。以前在使用Redis的过程中做的学习笔记，现整理做一下分享。

1. Redis对集群的支持情况

• redis 3.0之前版本不支持集群，若要实现集群，则需要借助中间件来实现存值和取值的对应节点。

• redis3.0之后的版本（含3.0），搭建集群，集群中机器两两连接，每台机器都可以做中转，事先给每台机器分配槽点（总共16384个），对于存值和取值，根据key来映射对应槽点和机器节点，若key不属于当前节点则跳转到对应其他节点，相当于每台机器节点都是一个全局路由。

2. Redis集群投票机制

Redis集群通过Gossip通信，当某个节点发现另外一个节点失联的时候，对外广播PFail信息，当某个节点收到集群绝大多数节点都判定那个节点为PFail的时候，强制将那个节点设置为Fail、并广播出去让其他节点接受、并立即对该节点进行主从切换。cluster-node-timeout ，当某个节点持续timeout时间失联，才认为该节点故障，需要主从切换，从而避免频繁的主从切换（数据的重新复制）。

3. Redis的淘汰策略

• volatile_lru:从设置过期的key中，挑选最近最少使用的key。

• volatile_ttl:从设置过期的key中，挑选即将过期的key。

• volatile_random:从设置过期的key中，随机挑选一个key。

• allkeys_lru:从数据集中，挑选最近最少使用的key。

• allkeys_random:从数据集中，随机挑选一个key。

• no_enviction:禁止淘汰数据（还是会根据引用计数进行内存释放），当内存使用超过设置的阈值，若再有内存申请操作则会失败。

4. Redis解决并发问题的思路

• 采用单进程单线程模式，没有锁的概念

• 通过队列将并发访问串行化

• 通过setnx命令，若不存在则设置对应的key

• 多路复用，保证高并发，定时任务，小顶堆，将最近最快要执行的任务放在堆顶，距离要执行的时间为多路复用的timeout，因为redis知道这段时间是没有任务要执行的，可以安心sleep，QPS可以达到10w/s。

5. Redis内存回收

• 对于不再引用或者过期的key，采用惰性和定时任务检测的方式，用户有请求过来、同时判断此key是否过期，若过期则删除并返回空，定时任务随机选取一些key（可配置），判断是否过期，对于Redis单进程单线程的架构来说，这样可以节省CPU和内存。定时任务每个数据库随机抽检20个key，发现过期则删除，若超过检查数目的25%的key过期，则循环执行，直到不足25%或者超过执行时间。

• 当设置了最大使用内存后、并且内存使用已经超过设置阈值，则采用上述淘汰策略进行内存回收。

6. Redis的数据类型

• string：动态的字符串，可以修改，当字符串长度小于1MB的时候，扩充都是加倍现有空间，超过1MB的话，扩充一次最多增加1MB，最大512MB。

• list：类似于java的linklist，插入和删除很快，O(1)，但是查找很慢，O(n), 当弹出list的最后一个元素后，该list自动被删除，内存被回收。ziplist和双向链表结合来实现quicklist，ziplist里面是一块连续的内存，是经过压缩的，因为对于int等基础类型，额外的两个指针太耗费空间，存储方式类似于LevelDb里面的Block，最后通过双向链表将ziplist连起来，这样既满足快速插入、删除的特性，空间浪费也不多。

• hash：相当于java的HashMap，无序字典，内部实现是用数组+链表，第一维的数组出现碰撞，则存到链表里面去。Rehash的时候，为了不阻塞服务，采用的是渐进式的Rehash，保留2个Hash，逐渐在指令执行或者定时任务中，将数据从老的Hash迁移到新的Hash。

• set：相当于java的HashSet，无序的键值对，不过其值都是NULL，键不可以重复。数据量较少且是整数的时候用有序数组，较大的时候采用散列表。

• zset：最具特色的数据结构，也是面试官问的最多的知识点。通过散列表+跳表实现，一方面是一个set，保证键的唯一性，另一方面，可以给每个value赋一个score，可以根据score排序、区段查找。应用场景：value为粉丝ID，score是关注时间，可以按照关注时间顺序给出粉丝ID。value是学生ID，score是其分数，可以按照分数排序。

7. Redis的过期设置

Redis所有的数据结构都可以设置过期时间，比如hash，需要注意，只能对hash整体设置过期时间，无法对其中的单个field设置过期时间。若一个对象已经设置了过期时间，但是待会你又修改了他，那么他的过期时间就会消失，也就是需要重新设置过期时间。

8. Redis分布式锁的一些讨论

redis是单进程单线程，本身没有锁的概念，主要是应用分布在多台机器，客户端不同顺序访问引起的互斥问题，例如，A读取字段field1，然后修改设置，B也同时读取字段field1（在A修改生效前），然后也修改设置（在A修改生效后），这样B的修改就将A的修改覆盖掉了，下面是递进的几种改进思路。

• setnx key value; del key，若程序异常，del没有执行的话，则其他程序永远得不到锁了。

• setnx key value; expire key 超时时间(单位秒);del key，加一个超时命令，似乎能解决问题，但是也存在同样的问题，即在执行expire之前程序就可能core dump了。

• set key value ex 超时时间(单位秒) nx; del key，这个基本没有问题了，但是业务执行时间不能超过超时时间，否则可能也会有问题。例如，程序A获得了锁，并执行，过了设置的超时时间后，锁自动释放，程序B获得锁，这个时候程序A执行完毕，将锁删除了。这样程序C就能获得锁，B和C可能会产生冲突。

• 如果产生锁的时候随机生成一个数，删除的时候先check一下随机数是否相同，只有相同了才能删除锁（即是当时生产锁的责任人）。Redis本身没有这个机制（检测和删除不是原子的），不过可以通过lua脚本来实现。

• 若是Redis集群，主从切换期间，程序A先在主机申请获得了一把锁，这时候发生主从切换，从机还没有感知到那把锁（即还没有将对应key同步过来），然后程序B又在新的主机（原来的从机）申请获得了一把同样的锁，这样业务就会出现问题。出现这个情况，