Redis高频问题突击(附答案)

刺骨的言语ヽ痛彻心扉 2022-09-09 02:08 125阅读 0赞

### 一、Redis持久化机制(AOF和RDB)？ ###

**1.1 RDB(Redis DataBase)**  
按照指定时间间隔(比如x秒内y次修改操作)，将内存中的数据集快照写入硬盘，术语称为snapshot。恢复时，将快照文件直接读入内存

RDB优缺点：

*  高性能：创建一个子进程来执行持久化，先将数据写入临时文件，持久化结束后，再用这个临时文件替换上场持久化好的文件；过程中主进程不做任何IO操作。
 *  速度快：二进制文件，比较适合大规模数据恢复，且对数据完整性要求不是非常高的场合
 *  安全低：发生宕机最多丢失最后一`次`数据

**1.2 AOF(Append Only FIle)**  
只做追加操(写操作)作的文件，类似于mysql服务的binlog日志文件。  
拥有rewrite机制，定期对aof重写来压缩文件  
有三种同步策略：从不记录，每秒记录，有记录立即记录

AOF优缺点：

*  安全高：发生宕机最多丢失最后一`条`的数据。
 *  速度慢：文件通常大于rdb方式，执行同步策略时的速度可能比rdb方式慢

**1.3 其他**  
若同时启用两种持久化，会先加载aof文件；一旦启用AOF，之前未启用aof时的rdb数据将被清除(因为启用aof后，aof文件为空，redis读取aof后写入rdb文件，所以数据就被清除了)

如何恢复一个有问题的aof文件(aof文件写一半时宕机)？  
使用自带命令恢复到最后一次的正确状态

src/redis-check-aof --fix appendonly.aof

### 二、Redis单线程为什么这么快？ ###

Redis基于Reactor模式开发了网络事件处理器，也称文件事件处理器。它是单线程的，所以才叫单线程模型。

Redis线程模型

*  IO多路复用：同时监听多个Socket，根据Socket的事件类型来选择对应的事件处理器来处理这个事件。
 *  文件事件处理器：包含4个部分，多个Socket、IO多路复用程序、文件事件分派器以及事件处理器(命令请求处理器、命令回复处理器、连接应答处理器等)

Redis处理过程：

*  多个Socket可能并发产生不同的事件，IO多路复用程序会监听多个Socket，会将Socket放入一个队列里排队
 *  每次从队列里有序、同步取出一个Socket给事件分派器，事件分派器把Socket给对应的事件处理器。
 *  等待Socket的事件处理完后，IO多路复用程序才会将队列下一个Socket给事件分派器。文件事件分派器会根据Socket产生的事件来选择对应的事件处理器来处理。

为什么这么快(为什么使用单线程)？

*  纯内存操作，业务简洁，没有高耗时IO业务
 *  使用单线程可以独享CPU分配的时间片。若使用多线程，CPU切换时间消耗+内核保存线程上下文+并发锁等额外消耗。
 *  采用IO多路复用机制

### 三、Redis过期键的删除策略(缓存过期策略) ###

设置key过期时间：expire、setex  
过期删除策略(缓存过期策略)：

*  惰性过期：只有当访问一个key时，才会判断该key是否过期并清除
 *  定期过期：每隔一定时间，会随机扫描部分数据库中部分key，并清除  
    redis同时使用上述两种过期策略

### 四、常见缓存淘汰算法 ###

FIFO(first in first out先进先出)：根据缓存被存放时间，离当前时间越远的数据优先被淘汰  
LRU(least recently used最近最少)：根据最近被使用的时间，离得远优先的数据优先被淘汰  
LFU(least frequency used最不经常使用)：在一段时间内，缓存数据被使用次数最少的优先被淘汰

### 五、内存清除策略 ###

volatile-lru                                !最近最少使用(设置了ttl)
    allkeys-lru                                 !删除最少使用的key(不管是否设置ttl)
    volatile-random                             !随机删除过期的key(设置了ttl)
    allkeys-random                              !随机删除(不管是否设置ttl)
    volatile-ttl                                !删除最近过期的key(设置了ttl)
    noeviction                                  !不删除，写满时报错(默认)

### 六、Redis和Mysql如何保证数据一致 ###

1、先更新Mysql，再更新Redis，若redis失败则数据不一致  
2、先删除Redis缓存数据，再更新Mysql，再次查询Mysql时将数据添加到Redis缓存。这样可以解决上面问题，但是并发性能低，而且也会出现数据不一致问题：比如线程1删除了Redis缓存数据，正在更新Mysql，此时线程2进行查询，那么又会把老数据添加到Redis缓存了。  
3、延时双删：

*  先删除redis数据，再更新mysql，延迟几百毫秒再删除redis数据。这样就算在更新Mysql时，其他线程读了mysql写入redis后，也会被删除掉，从而保持数据一致性

### 七、Redis有哪些数据结构及应用场景 ###

1、字符串：可以存储json等字符串。redis分布式锁使用了这种数据结构，还包括计数器、Session共享、分布式ID  
2、哈希表：可以存储key-value键值对。适合存储对象。  
3、列表：redis的列表通过命令的组合，既可以当做栈，也可以当做队列。可以缓存微博等消息流数据  
4、集合：和列表相识，但是元素唯一且无序，可以进行交、并、差集。可以实现共同关注的人、朋友圈点赞  
5、有序集合(sorted set)：元素唯一且有序。可以实现排行榜功能  
6、bitmap：布隆过滤器  
7、GeoHash：借助sorted set实现，通过zset的score排序得到的坐标附件的元素，通过socre还原成坐标值就可得到原始坐标。  
8、Streams：内存版kafka(消息发布与订阅)  
9、HyperLogLog：统计不重复数据，用于大数据基数统计

### 八、缓存穿透、缓存击穿、缓存雪崩分别是什么？ ###

缓存雪崩：高并发场景下，当大批热点数据同时过期，所有请求将打到Mysql。  
解决办法：

*  随机设置热点数据过期时间(内存不够)
 *  搭建redis集群，设置热点数据不过期(内存够)
 *  搭建mysql读写分离集群，分摊读压力

缓存击穿：高并发场景下，某个热点数据失效，所有请求打到Mysql  
解决办法：

*  设置热点不过期
 *  业务加锁，但是影响性能
 *  业务快速失败，同时加锁查mysql数据缓存到redis(每次拿到锁再次判断是否缓存了)

缓存穿透：请求的记录不存在，每次查询都跳过缓存打到Mysql  
解决办法：

*  不存在的记录也缓存到redis(会造成key太多)
 *  布隆过滤器，它认为key不存在就是不存在

### 九、布隆过滤器(bitmap) ###

使用位图int\[10\]。每个int类型的整数时4\*8=32个bit，则int\[10\]共有320bit，每个bit非0即1，初始化为0。  
添加数据时，将数据进行hash得到hash值，将对应的bit改为1，hash函数可定义多个，则一个数据添加会将多个(hash函数个数)bit改为1，多个hash函数的目的就是减少hash碰撞概率。  
查询数据时，hash函数计算得到hash值，对应到bit中，若有一个为0，则数据不存在；若为1，数据可能存在。

优点：

*  无需存储元素值，占用空间小，适合大数据集的数据过滤
 *  增加和查询元素的时间复杂度为：O(K)，K为哈希函数个数，与数据量无关

缺点：

*  存在误判：若布隆过滤器判断不存在，则数据肯定不存在；若布隆过滤器判断存在，则数据可能存在
 *  只能往布隆过滤器增加元素，不能删除元素

### 十、简述Redis事务实现 ###

*  1、事务开始：Multi命令的执行标识着事务的开始。Multi命令会根据客户端状态的flags属性中打开redis\_multi标志完成的。
 *  2、命令入队：当客户端切换事务状态后，若客户端的命令为multi、exec、watch、discard会立即执行，否则放进队列里，若命令语法没有问题则返回queued回复，否则会将客户端的flags属性关闭redis\_multi，并返回错误。(若非语法问题，其他问题一并执行，不支持回滚，例如类型不匹配赋值，需要在自己业务上控制)
 *  3、事务执行：若客户端发送的时exec命令，redis会立即执行事务，遍历队列执行命令。(若客户端的flags不含redis\_multi或含redis\_dirty\_cas或含redis\_dirty\_exec则立即取消事务执行)

涉及名词：  
【watch】是一个乐观锁，为redis事务提供check-and-set(CAS)行为，可监控多个键，键被更改时事务停止执行，从事务开始监控到exec命令执行开始  
【discard】是清空事务并放弃，客户端从事务状态退出

### 十一、Redis分布式锁底层如何实现？ ###

1、首先利用setnx+setex来保证：若key不存在可获取锁，若key存在不可获取锁  
2、set(key,value,nx,px)：将setnx+setex变成原子操作  
3、利用lua脚本保证多个redis操作的原子性  
4、同时考虑锁过期，所以需要额外的定时任务监听锁是否需要续期  
5、为避免有节点宕机，采用红锁的方式来同时向N/2+1个节点申请锁，都申请到了才算获取成功。

### 十二、Redis主从复制原理 ###

通过执行slaveof命令或者设置slaveof选项，让一个服务器取复制另一个服务器的数据。  
主库可读写，从库仅只读，主库数据变更会自动将数据同步给从库。

全量复制：

*  主库通过bgsave命令fork子进程进行RDB数据持久化。
 *  主库通过网络将RDB发送给从库
 *  从库清空老数据、载入新RDB文件过程是阻塞，此时无法响应客户端请求。

增量复制：

*  复制偏移量：主从都会维护一个复制偏移量offset
 *  复制积压缓冲区：主库维护了一个定长的先进先出(FIFO)队列作为复制积压缓冲区，当主库offset超过队列长度，将无法执行部分复制，只能全量复制。
 *  服务器运行ID：每个从库都有runid，主库会将主库runid发送给从库，从库储存主库ID，当从库宕机重连，主库会根据从库ID来判断同步进度：
 *  若从库runid与主库runid相同，说明之前同步过，主节点会尝试使用增量复制(能不能复制还需要看offset和积压缓冲区情况)
 *  若从库runid和主库runid不同，说明主从未同步过或者中断过，此时进行全量复制