redis面试大全

1.redis用途

数据缓存，特别是热点数据，减少数据库压力
手机验证码，失效时间来设置验证码的过期时间；
分布式锁，seNX+expire来设置，value设置uuid，unlock时要判断value值必须是自己线程设置的才可解锁，保证只有当前线程才可以解锁
计数器，INCR,DECR，单线程能保证线程安全
分布式队列，通过redis的list能保证队列的线程安全
排行榜，通过sorted set实现
限流，只能做最简单的限流，不平滑
附近的人，地址位置，通过GEO实现
共同好友，集合的交集，并集等操作
签到，使用位图实现，节省内存空间
UV，通过HyperLogLog实现，但是会存在部分误差，适用于对数量精确性不敏感的场景
位图功能实现签到，统计一年登录次数，在线用户数等，节约空间

2.缓存挂掉，穿透，击穿，雪崩

缓存挂掉：
1.redis哨兵或者集群模式保证缓存不会挂掉；
2.增加本地缓存和限流，避免缓存挂掉全部走数据库；
3.缓存恢复后通过持久化方案恢复数据

雪崩：
多个缓存同时失效，导致大量的请求会去查询数据库，导致数据库压力暴增
解决方案：
1.超时时间不要设置相同，过期时间加上个随机值，避免同时失效；
2.设置热点数据永不过期；

击穿：
热点数据的失效，导致顺时大量请求访问数据库，将数据库宕机，进而导致整个系统的崩溃，和雪崩不同的是，它是单个数据的顺时失效，雪崩是多个
解决方案：
1.热点数据设置永不过期
2.加互斥锁

互斥锁

使用互斥锁不能精确到key维度，可以通过分布式锁或者本地缓存来解决问题

穿透：
请求数据库中不存在的记录，会导致每次都无法命中缓存，每次都要去数据库获取
解决方案：
1.对于不存在的记录，缓存中设置一个空值；
2.使用布隆过滤器

3.redis缓存失效

3.1 过期删除策略：
定时扫描
首先将每个设置了过期时间的key放到一个独立的hash中，默认每秒定时遍历这个hash而不是整个空间：
并不会遍历所有的key，采用一种简单的贪心策略
1、从过期key字典中，随机找20个key。
2、删除20个key中过期的key
3、如果2中过期的key超过1/4，则重复第一步
4、每次处理的时间都不会25ms
如果有大量的key在同一时间段内过期，就会造成数据库的集中访问，就是缓存雪崩！

惰性策略
客户端访问的时候，会对这个key的过期时间进行检查，如果过期了就立即删除。惰性策略是对定时策略的补充，因为定时策略不会删除所有过期的key
3.2 内存淘汰机制
当内存不够时，触发内存淘汰机制，主要有：
1.不删除，内存不足直接报错
2.所有key:随机删除
3.所有key:删除最近最少使用
4.设置失效时间的key:随机删除
5.设置失效时间的key:删除最近最少使用
6.设置失效时间的key:优先删除剩余时间短的key

4.redis速度快原因

1.纯内存操作，内存处理速度远远大于磁盘
2.采用异步阻塞reactor模型
3.单线程，减少了线程切换和阻塞的消耗

5.redis数据类型和底层实现

string
如果value可以转化成long，使用数值存储
字符串<=44,使用embstr, redisObject和sds连续，分配一次
字符串>44，使用raw，redisObject和sds不连续，分配两次
例子：

字符串

list
底层结构:quicklist，quickList 是 zipList 和 linkedList 的混合体，它将 linkedList 按段切分，每一段使用 zipList 来紧凑存储，多个 zipList 之间使用双向指针串接起来。

// 快速列表
struct quicklist {
    quicklistNode* head;
    quicklistNode* tail;
    long count; // 元素总数
    int nodes; // ziplist 节点的个数
    int compressDepth; // LZF 算法压缩深度
    ...
}
// 快速列表节点
struct quicklistNode {
    quicklistNode* prev;
    quicklistNode* next;
    ziplist* zl; // 指向压缩列表
    int32 size; // ziplist 的字节总数
    int16 count; // ziplist 中的元素数量
    int2 encoding; // 存储形式 2bit，原生字节数组还是 LZF 压缩存储
    ...
}

struct ziplist_compressed {
    int32 size;
    byte[] compressed_data;
}

struct ziplist {
    ...
}

例子:

hash
底层结构：ziplist或者dict(字典)
和上面列表对象使用 ziplist 编码一样，当同时满足下面两个条件时，使用ziplist（压缩列表）编码：
　　1、列表保存元素个数小于512个
　　2、每个元素长度小于64字节
　　不能满足这两个条件的时候使用 hashtable 编码。第一个条件可以通过配置文件中的 set-max-intset-entries 进行修改
例子:

set
底层结构：intset(数值集合)或者dict(字典)
如果集合中元素都可转为long，则用intset，不能转则用dict
例子：

sortset
底层结构：ziplist和skiplist
为什么需要跳表而不是红黑树？
跳表实现简单，维护性好，对于范围查询时，跳表速度较好，而sortset有范围查询的场景，其他方面跳表性能比红黑树差。

6.LRU实现方式

思想：利用一个链表来实现，每次新插入数据的时候将新数据插到链表的头部；每次缓存命中（即数据被访问），则将数据移到链表头部；那么当链表满的时候，就将链表尾部的数据丢弃

    // 继承LinkedHashMap
    public class LRUCache<K, V> extends LinkedHashMap<K, V> {
        private final int MAX_CACHE_SIZE;

        public LRUCache(int cacheSize) {
            // 使用构造方法 public LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder)
            // initialCapacity、loadFactor都不重要
            // accessOrder要设置为true，按访问排序
            super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
            MAX_CACHE_SIZE = cacheSize;
        }

        @Override
        protected boolean removeEldestEntry(Map.Entry eldest) {
            // 超过阈值时返回true，进行LRU淘汰
            return size() > MAX_CACHE_SIZE;
        }

    }

7.redis分布式锁实现

SET key value EX 10086 NX
将setnx和expire结合在一个指令中，保证原子性
执行完后执行del删除key
但是会有问题：假设A线程执行，这时候拿到锁，执行时间很长，导致锁的时间过期了，这时候B线程也能拿到锁，然后执行代码，未执行完锁代码块，这时候A线程执行完执行了删除逻辑，这样会导致另外的线程又能拿到锁。为了解决这样的漏洞，一般会对value值做限制，可以用uuid生成value，在删除时校验redis的value值必须是该线程生成的，会避免上述说的问题。一般使用LUA脚本：

if redis.call('get', KEYS[1]) == ARGV[1] 
then 
return redis.call('del', KEYS[1]) 
else 
return 0 
end

参考文章：
https://www.cnblogs.com/ysocean/p/9102811.html
https://blog.csdn.net/lusic01/article/details/92001898
https://blog.csdn.net/elricboa/article/details/78847305