基础面试题整理7之Redis

1.redis持久化RDB、AOF

RDB(Redis database)

在当前redis目录下生成一个dump.rdb文件,对redis数据进行备份

常用save、bgsave命令进行数据备份:

  • save命令会阻塞其他redis命令,不会消耗额外的内存,与IO线程同步;
  • bgsave命令不会阻塞其他redis命令,会耗额外内存,与IO线程异步;

基础面试题整理7之Redis_第1张图片

bgsave命令是由主线程衍生出来的一个子进程,该子进程可以获取主线程的全部内存数据。若在执行bgsave命令时,还有其他redis命令被执行(主线程数据修改),此时会对数据做个副本,然后bgsave命令执行这个副本数据写入rdb文件,此时主线程还可以继续修改数据。

配置自动生成rdb文件的后台使用bgsave命令

基础面试题整理7之Redis_第2张图片

AOF(append-only-file)

在当前redis目录下会生成aof文件,对redis修改数据的命令进行备份

基础面试题整理7之Redis_第3张图片

 开启aof方式,并配置aof文件名字

基础面试题整理7之Redis_第4张图片

redis命令与AOF文件内容

操作redis,命令如下

基础面试题整理7之Redis_第5张图片

可以看到aof文件内容,记录修改数据命令

*为一条命令的开始,*后面的数字为命令的参数个数,$及数字表示该命令的参数长度

基础面试题整理7之Redis_第6张图片

 配置redis多久将命令执行到aof文件中

  • appendfsync always:每次有新命令就会追加aof文件中
  • appendfsync everysec:每秒追加到aof文件中,所以可能会丢失一秒钟的数据(默认)
  • appendfsync no:不追加,将数据交给操作系统来负责

基础面试题整理7之Redis_第7张图片

AOF重写:定期根据内存的最新数据生成aof文件

由于一些命令一直在修改同一个key的信息,所以有时可以合并为一条命令。例如 set age 1 ->set age 2 ->set age 3,此时可以直接在aof文件写set age 3这一条命令即可。

基础面试题整理7之Redis_第8张图片

对应aof文件:

基础面试题整理7之Redis_第9张图片

手动重写命令:bgrewriteaof

对应aof文件:

基础面试题整理7之Redis_第10张图片

配置自动重写的条件:
  • auto-aof-rewrite-percentage 100: 当aof文件比上一次重写大了100%,触发重写机制
  • auto-aof-rewrite-min-size 64mb:当aof文件大小超过64M,触发重写机制

基础面试题整理7之Redis_第11张图片

RDB、AOF区别

  • 由于RDB文件体积小(二进制文件),所以恢复数据速度快;相对AOF文件体积大(命令存储),所以恢复数据速度慢
  • RDB比AOF文件可能丢失数据(RDB是通过save命令设置持久化,所以可能会丢失很多数据;而AOF可能会丢失一秒的数据),相对数据安全,所以一般数据恢复时系统默认使用AOF方式

混合持久化

redis4后可以将RDB、AOF混合使用,速度很快

  1. 混合持久化设置启用 aof-use-rdb-preamble yes,AOF也需要开启,RDB配置可去掉(save命令)
  2. redis数据重写时AOF文件以二进制形式(RDB)存储+增量AOF数据继续以命令存储
  • 考虑redis性能时,无论什么架构,一般对master节点不进行持久化,对slave节点进行AOF持久化
  • 若对master节点不进行持久化,那么不建议运维自动重启master节点,因为重启master节点,数据未做持久化,是个空实例,最后主从同步会导致数据全部丢失。所以建议哨兵模式,哨兵自己判断去重启某个节点

2.缓存击穿、缓存穿透、缓存雪崩

缓存击穿(缓存失效)

某一时刻热点key过期了,同时有大量请求过来,出现查询不到redis数据,都去查询数据库,造成数据库的压力瞬间过大问题;重点是缓存key失效(Redis不存在,数据库存在)

解决办法:

  • 对redis的过期时间设置成不一样
  • 对读取数据库后写入Redis这步骤加个锁,防止并发

缓存穿透

某一时刻大批量不存在的key请求过来,出现查询不到redis数据,都去查询数据库,造成数据库的压力瞬间过大问题;重点是不存在的数据(Redis不存在,数据库也不存在)

解决办法:

  • 参数校验
  • 当数据库也查询不到数据时,给个默认空字符串并设置过期时间,然后在查询redis时数据不为空,对空字符串数据进行判断,伪代码如下:
public String get(String pid) {
	//1.查询Redis数据
	String redisInfo = redis.get(pid);
	if (StringUtils.isNotEmpty(redisInfo)) {
		//1.1Redis数据为空字符串,读缓存延长
		if ("{}".equals(redisInfo)) {
			redis.expire(pid, 1000, TimeUnit.SECONDS);
		}
		//1.2Redis数据不为空字符串,也读缓存延长
		redis.expire(pid, 24 * 60 * 60, TimeUnit.SECONDS);
		return redisInfo;
	}
	//2.查询数据库
	String daoInfo = dao.get(pid);
	if (StringUtils.isNotEmpty(daoInfo)) {
		//2.1数据库查询到数据,并添加缓存到redis
		redis.set(pid, daoInfo, 24 * 60 * 60, TimeUnit.SECONDS);
		return redisInfo;
	} else {
		//2.2数据库查询不到数据,缓存到redis为空字符串
		redis.set(pid, "{}", 1000, TimeUnit.SECONDS);
	}
	return daoInfo;
}
  • 布隆过滤器 在访问Redis前判断

缓存雪崩

某一时刻大批量的过期key查询Redis查不到,后查询数据库,造成数据库挂掉;重点是大批量不同的过期key

解决办法:

  • Redisson分布式锁

使用分布式锁对商品ID进行控制,因为Redis的执行操作是单线程的,无论哪台服务器,最后都要执行到Redis;若不使用Redisson,而是用synchronized(this),此时会造成对服务器的加锁,若开始大量查询ID为1的商品,每台机器都会先跑一遍加个锁,然后在查询ID为2的数据,此时需要等待ID为1的锁释放,所以需要将this对象调整为全局商品ID。

使用Redis分布式锁+二级缓存(Map)解决

public String get(String pid) {
	//1.查询Redis数据
	String redisInfo = redis.get(pid);
	if (StringUtils.isNotEmpty(redisInfo)) {
		//1.1Redis数据为空字符串,读缓存延长
		if ("{}".equals(redisInfo)) {
			redis.expire(pid, 1000, TimeUnit.SECONDS);
		}
		//1.2Redis数据不为空字符串,也读缓存延长
		redis.expire(pid, 24 * 60 * 60, TimeUnit.SECONDS);
		return redisInfo;
	}
	//2.获取Redis分布式锁
	RLock hotLock = redissonClient.getLock("lock:"+pid);
	hotLock.lock();
	try {
		//3.重新查询缓存
		redisInfo = redis.get(pid);
		if (StringUtils.isNotEmpty(redisInfo)) {
			if ("{}".equals(redisInfo)) {
				redis.expire(pid, 1000, TimeUnit.SECONDS);
			}
			redis.expire(pid, 24 * 60 * 60, TimeUnit.SECONDS);
			return redisInfo;
		}
		//4.查询数据库
		String daoInfo = dao.get(pid);
		if (StringUtils.isNotEmpty(daoInfo)) {
			//4.1数据库查询到数据,并添加缓存到redis
			redis.set(pid, daoInfo, 24 * 60 * 60, TimeUnit.SECONDS);
			return redisInfo;
		} else {
			//4.2数据库查询不到数据,缓存到redis为空字符串
			redis.set(pid, "{}", 1000, TimeUnit.SECONDS);
		}
	}finally {
		hotLock.unlock(); //释放锁
	}
	return daoInfo;
}
  •  key的过期时间设置随机数,防止同时过期

3.redis分布式锁

TODO

4.redis主从同步机制 

配置文件中从节点需要记录主节点的ip及端口号信息。主从数据复制时,若是master节点下面有很多slave节点,在某一时刻同时让master节点发送RDB文件给slave节点,会造成主节点压力过大,形成主从复制风暴问题。可以调整为从节点复制从节点的树形复制。

基础面试题整理7之Redis_第12张图片

主从复制有全量复制增量复制

全量复制

  • bgsave命令,主线程衍生一个子进程,将持久化RDB文件通过网络传输给从节点
  • 从节点先删除旧数据,然后重新载入RDB文件(此过程是阻塞的)

增量复制

  • 偏移量:主从节点都存储一个偏移量,用于记录增量的offset
  • 复制积压缓冲区:复制到持久化RDB文件之前有个积压缓冲区,这样主从复制速度快些
  • 服务器运行ID:每个节点启动时自动生成一个服务器运行ID,然后主从节点都会互相发送并存储这个ID,每次增量复制会判断运行ID,若与之前存储的ID不同,则需要全量复制;否则增量复制

5.redis数据备份

数据备份模式一般都是大同小异的(无论是redis还是日志等其他文件数据)

  • 对RDB文件或AOF文件进行定时备份到另一台机器中,保留72小时的备份(时间以项目情况为准)
  • 每天保留一份数据进行备份到另一个目录,保留一个月的备份(时间以项目情况为准)
  • 每次备份时需要将之前的旧数据删除掉

6.redis在电商的使用

  • 一般数据量电商项目中,新增/修改接口都会先入数据库,后将该数据放到redis缓存中[set(key,value)];在查询该商品时,先去redis缓存中读取,若未查询到再去数据库中获取,否则直接返回缓存数据;
  • 海量数据的电商项目中,新增/修改接口在操作redis缓存时,需要给个过期时间[set(key,value,time,unit)];在查询该商品时,从redis缓存读取后,需要将该商品的redis缓存过期时间延长。这样可以实现缓存数据的冷热分离。因为数据的访问量不同,加个过期时间可提高效率
  • 查询接口中当查询数据库时有写操作(修改接口)进来,导致数据库与Redis数据不一致,此时Redis分布式锁有读写锁,需要在读数据库前补充读锁,修改操作补充写锁
  • 布隆过滤器:int[10]共4*8*10=320个字节的位图,用于在查询Redis判断是否存在该数据,若不存在,则直接返回不存在该数据;存在则继续查询Redis; 

你可能感兴趣的:(面试专用,redis,数据库)