redis常见数据结构?
String
List
Set
Hash
Zset
redis在项目中的使用场景?
redis的key 的数据结构是如何选型的redis的key的规范是如何设计的具体业务是怎么样的如何使用redis解决的业务
redis具体如何使用?
redis的事务机制的介绍?
redis事务是基于队列实现的，创建一个事务队列，然后将事务操作都放入队列中，最后依次执行
事务处理失败有两种解决方式
1、语法错误：
此时执行事务队列，会直接报错，正确语句也不会执行
2、执行错误：
当出现网络波动或其他因素，执行失败后，业务不会回滚
SpringBoot实现redis事务操作
1）修改RedisConfig配置类，开启事务控制
//开启redis事务控制
redisTemplate.setEnableTransactionSupport(true);
2)自定义方法测试
@Test
@Transactional(rollbackFor = Exception.class)
public void multiTest(){
//开启事务
redisTemplate.multi();
try{
redisTemplate.opsForValue().set("lesson","java");
redisTemplate.opsForSet().add("lesson","eureka","feign","gateway");
redisTemplate.opsForValue().set("lesson","redis");
System.out.println(redisTemplate.opsForValue().get("lesson"));
}catch (Exception e){
//回滚
System.out.println("出现异常");
redisTemplate.discard();
}finally {
redisTemplate.exec();
}
}
redis的持久化机制?
redis有两种持久化机制：
一种是RDB快照，它是基于快照思想当符号某一条件时，redis会将这一刻的内存数据进行快照保存到硬盘上，产生一个经过压缩的二进制文件文件名为 xxx.rdb，当有服务器宕机时，只要rdb文件存在，就可以利用它还原数据。
RDB触发条件：
save "" # 不使用RDB存储 不能主从
# 记忆
save 3600 1 #表示1小时内至少1个键被更改则进行快照。
save 300 100 #表示5分钟（300秒）内至少100个键被更改则进行快照。
save 60 10000 #表示1分钟内至少10000个键被更改则进行快照。
还可以在redis客户端执行save或bgsave命令，手动触发RDB快照。
#进入客户端
bin/redis-cli
#执行save命令(同步执行)
save
#执行bgsave命令(异步子线程执行)
bgsave
save:同步处理，会阻塞redis服务进程，服务器不会处理任何命令，知道RDB文件保存结束
bfsave：会fork一个和主线程一致的子线程负责操作RDB文件，不会阻塞Redis服务进程，操作RDB文件的同时仍然可以处理命令。
注：redis默认使用的是bgsave来保存快照数据
一种是AOF。与RDB不同的是AOF保存的是操作命令而非数据，将操作命令保存到AOF文件中，这样，当redis重启后，读取AOF文件，按顺序获取到修改命令，即可完成数据恢复
AOF方式需要手动开启，修改redis.conf
# 是否开启AOF，默认为no
appendonly yes
#设置AOF文件名称
appendfilename appendonly.aof
AOF的触发方式有三种：always、everysec、no。默认使用的是everysec，可通过redis.conf中appendfsync属性进行配置。
always：每次执行写入命令都会将将命令写入AOF文件，并将AOF文件同步到磁盘，此方式效率最低，安全性最高
everysec：每一秒将写入命令写入AOF文件中，
no：每30秒一次，将写入命令写入AOF文件中
随着时间和数据的积累，AOF文件会变得越来越大，占用大量存储空间，数据还原花费的时间越多，redis提供重写功能对其优化，当AOF文件体积超过阈值时，会触发重写
RDB和AOF持久化的区别?
RDB的缺点：
基于二进制文件完成数据备份，占用空间少，便于文件传输。
能够自定义规则，根据Redis繁忙状态进行数据备份。
RDB的优点：
RDB无法无法保证数据完整性，会丢失最后一次快照后的所有数据
bgsave执行每次执行都会阻塞Redis服务进程创建子线程，频繁执行影响系统吞吐率。
1、RDB默认是开启的，AOF需要手动开启
2、RDB性能优于AOF
3、AOF的安全性优于RDB
4、AOF优先级高于RDB
5、RDB存储某个时刻的数据快照，AOF存储写命令
6、RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF默认使用everysec，每秒保存一次，最多丢失两秒以内的数据。
redis高可用(集群策略)?
主从复制
1、当从库启动时，会链接主库，并发送数据同步请求，建立主从关系
2、当主库收到从库发出的请求时，会立即执行bgsave命令，会将主库所有的数据持久化到RDB文件中
3、主库会把rdb文件发送给从库
4、从库收到rdb文件后，会删除旧数据，装在新数据
缺点：当主库宕机时，无法进行写操作，需要人工进行主从更替
哨兵模式
需要搭建哨兵集群，这里的哨兵也是redis，只不过不进行读写操作，只用来监控主节点的健康状态
当主节点宕机时，哨兵会检测到，当超过半数加一个哨兵检测到主节点宕机时，会从从节点中选择一个变
更为主节点，当之前的主节点正常时，会变为现在主节点的从节点
分片集群
前两种最大的局限是只能在一个服务器上写，有并发写的问题。
分片集群允许有多个主节点，redis准备了16384个虚拟的hashslot（哈希槽），这些哈希槽会和参与
存数据的节点有绑定关系（默认平均分配到节点上），存数据时，会根据key利用crc16的算法对16384取余
根据取余结果决定在那个节点存数据。
当某一个主节点宕机时，其他主节点超过半数检测到其宕机时，会其从节点选择一个变更为主节点。
理论上可以分16384个主节点
解决了：
海量数据存储
高可用
高可扩
redis key的过期淘汰策略?
定时删除：
它会在设置键的过期时间的同时，创建一个定时器，当键到了过期时间，定时器会立即对键进行删除
该策略对内存空间足够友好， 但对CPU非常不友好，会拉低系统性能，因此不建议使用。
惰性删除：
他不持续关注key的过期时间，而是在获取key的时候，检查key是否过期，若过期则删除，
惰性删除对CPU足够友好，但是对内存空间非常不友好，会造成大量内存空间的浪费
定期删除
折中策略，每隔一段时间进行检查，对过期的key进行删除。
默认每秒运行10次，每次获取20个key，同时删除这20个key中过期的key，如果这20个中过期的key比例在25%以上，会继续扫描
redis 内存淘汰策略?
当客户端执行命令，添加数据时，Redis会检查内存空间大小，如超过最大内存，则触发内存淘汰策略
redis缓存穿透的问题?
redis缓存击穿的问题?
redis缓存雪崩的问题?
redis实现分布式锁的原理?
若有收获，就点个赞吧
0 人点赞
