Redis面试总结

最新推荐文章于 2024-10-02 05:39:15 发布

promise4

最新推荐文章于 2024-10-02 05:39:15 发布

阅读量101

点赞数

分类专栏：面试总结文章标签： redis 面试 java

本文链接：https://blog.csdn.net/promise4/article/details/128816188

版权

面试总结专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Redis数据结构以及使用场景

1.String

Redis中String类型的数据最大只能是512M
1、计数器功能，我们可以使用incr命令实现自增操作,来计数。例如我们可以统计文章的阅读量、粉丝数量等
2、系统中的一些配置值、Token令牌信息等
3、session共享, 在分布式系统中，由于有多台服务器，请求分发，每次分发到的目标服务器可能都不一样,那么这时候我们就需要利用一个中间件来保存session的状态，我们就可以把session保存在redis中
4、限流，就是有时候我们需要对某些用户、某些接口、某些IP地址进行限流，即比如每分钟只能访问多少次等

2.List

字符串列表，按照插入顺序排序。
1、消息队列，可以使用lpush + brpop命令实现阻塞队列
2、像一些分页查询的功能，如果数据保存在缓存中，也可以使用list,对应的命令: lrangkey 0 19分页获取

3.Hash

哈希是一个String类型的field以及value的映射表,类似Java的Map

{
 hash1 : { name: "zhangsan", age: 20 },
 hash2 :{ name: "lisi", age: 30 },
}

1、可以存储一些对象信息,如用户信息、订单信息等
2、购物车功能
    使用用户ID作为缓存Key
    使用商品编码skuCode作为hashKey
    使用商品信息作为hashValue

4.Set

无序集合，集合里面的元素都是唯一的，也就是说集合里面不会出现重复元素
1.社交软件的共同好友，共同爱好等。如微博的共同好友
2.统计访问我们网站的ip地址
3.抽奖功能，返回随机数功能

5.ZSet

sorted set,和set一样也是不允许重复的，不同的是每个元素都会关联一个score分数，内部是基于score进行排序的（从小到大）
zset里面元素不会重复，但里面的score分数是可以重复的
排行榜功能，如游戏的用户得分排行榜，学生的成绩排行等。

Redis的持久化机制有哪些?有哪些优缺点?

1、RDB

RDB (redis database)持久化，是指在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它是Redis默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。
配置（redis.conf）
 默认提供了三种会触发rdb持久化的条件
    save 900 1 900秒之内至少有一个key被改变
    save 300 10 300秒之内至少有十个key被改变
    save 60 10000
    save " "关闭rdb持久化功能

触发机制
    手动触发
        save（同步）
            save时只管保存，其他不管，save是一个阻塞式命令，即当服务器接收了一条save命令之后就会开始拍摄快照，在此期间不会再去处理其他的请求，其他请求会被挂起直到备份结束，应该避免使用。

        bgsave（异步）
            redis会在后台异步进行快照操作，快照操作同时还可以响应客户端请求，与save命令区别就在于bgsave不会阻塞主进程处理的操作。Redis会单独创建(Fork) 一 个子进程来进行持久化，先将数据写入到一个临时文件中，待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。


    自动触发
        save  m n m秒内数据集存在n次修改时，自动触发bgsave


优点
    1、如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比A0F方式更加的高效
    2、与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些
    3、RDB很适合用于灾备，单文件很方便就能传输到远程的服务器上;
    4、可以定期备份rdb文件，直接写个脚本就好了，很方便

缺点
    1、没办法做到实时持久化/秒级持久化
    2、最后一次持久化后的数据可能丢失
    3、rdb需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能导致redis在一些毫秒级不能响应客户端请求

2、AOF

全称叫" append only file", aof是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录) ,只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，redis重启的话根据日志文件的内容将写指令从头到尾执行一次以完成数据的恢复。AOF方式持久化默认保存的是appendonly.aof文件。它主要解决数据持久化的实时性问题。默认是不开启的。
配置
    aof持久化开关默认是关闭的 appendonly no
    aof备份的文件名 appendfilename "appendonly.aof"
    appendsync everysec  持久化策略
    默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发重写。
    auto-aof-rewrite -min-size 64mb
    auto-aof-rewrite-percentage 100

原理
    aof仿式持久化通过保存redis执行时候的所有写操作命令，注意，读操作命令不追加，将写命令追加到appendonly.aof文件中，理论上只要保存了所有写操作命令，那么恢复时将这些命令从头到尾再执行一次就可以从正常恢复数据。

AOF持久化策略
    appendfsync always: Always: 同步持久化，每次发生数据变更会立即记录到磁盘，性能较差但数据完整性比较好，always会严重影响服务器的性能;
    appendfsync everysec: Everysec:默认就是此方式，异步操作，每秒记录，如果一秒内宕机，有数据丢失;
    appendfsync no:从不同步

重写机制
    aof采用文件追加方式，文件会越来越大，为避免出现此种情况，redis新增了重写机制，当aof文件的大小超过所设定的阈值时，Redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集。当然我们也可以使用命令bgrewriteaof手动告诉redis进行aof文件的重写，这样可以有效减小aof文件的体积。
        重写原理
            redis会fork出一个子进程来对aof文件进行重写，原理跟快照持久化命令bgsave的工作原理类似，值得注意的是，进行aof文件重写时，如果原来的aof文件体积已经非常大，那么重写aof并删除旧aof文件的过程将会对Redis的性能造成较大的影响。
            auto-aof-rewrite-percentage:配置当aof文件需要比旧aof文件增大多少时才进行重写
            auto-aof-rewrite-min-size:配置当aof文件需要达到多大体积时才进行重写
            只有这两配置都达到时，才会进行重写



优点
    1、数据的一致性和完整性更高
    2、使用默认的持久化策略:每秒同步一次，Redis 最多只会丢失1秒的数据;
    3、aof文件的格式可读性较强，同时还可以检查aof文件中的错误并进行修复;

缺点
    1、对相同的数据集来说，aof文件的体积通常要大于rdb文件的体积，恢复速度慢于rdb;

加载流程
在这里插入图片描述

如果存在dump.rdb文件和aof文件的话，会先加载aof文件

3、总结

redis允许同时存在rdb和aof两种持久化方式，但是重启时会优先加载aof文件;
如果在项目中只是将redis作为缓存服务器的话，我们其实可以不用进行持久化，因为缓存对数据敏感性没那么强;
aof持久化方式最多只会丢失一秒的数据，但是这带来了很多额外的I0操作，其次就是重写造成的阻塞不可避免，所以应该尽量减少aof重写的频率，建议将参数auto aof-rewrite-min-size修改为5G或者更大;