Redis面试题

文章探讨了Redis在缓存、计数和分布式锁等场景的应用,以及如何通过幂等性设计防止重复提交。提到了高并发下使用Redis+UUID的token机制来确保幂等性,并介绍了Mybatis的批量删除和添加方法。此外,讨论了Redis的持久化机制(RDB和AOF)以及内存管理的淘汰策略。文章还涉及NoSQL数据库的特点,Redis集群的特性及其在节点失效情况下的行为。
摘要由CSDN通过智能技术生成

1.Redis应用场景

缓存、排行榜、计数器、分布式会话、分布式锁、社交网络、最新列表、消息系统

3.如何解决幂等性(重复提交)?

  • 1.前端js提交禁止按钮可以禁用一些js组件
    弊端:1、可被模拟浏览器访问绕过
    2、后退后仍可使用
    3、网络丢包,用户请求成功,但服务器未接收到,导致用户卡死当前操作
    4、建议后台校验

  • 2.使用Post/Redirect/Get模式
    在提交后执行页面重定向,这就是所谓的Post-Redirect-Get (PRG)模式。简言之,当用户提交了表单后,你去执行一个客户端的重定向,转到提交成功信息页面。这能避免用户按F5导致的重复提交,而其也不会出现浏览器表单重复提交的警告,也能消除按浏览器前进和后退按钮导致的同样问题。

  • 3.借助数据库操作(unique key)
    insert唯一索引;保证插入的数据只有一条;
    悲观锁或者乐观锁;
    先查询后判断,首先通过查询数据库是否存在数据,如果存在证明已经请求过了,直接拒绝该请求,如果没有存在,就证明是第一次进来,直接放行;

  • 4.session机制(后台服务端)
    在服务器端,生成一个唯一的标识符,将它存入session,同时将它写入表单的隐藏字段中,然后将表单页面发给浏览器,用户录入信息后点击提交,在服务器端,获取表单中隐藏字段的值,与session中的唯一标识符比较,相等说明是首次提交,就处理本次请求,然后将session中的唯一标识符移除;不相等即重复提交。

  • 5.(Redis+UUID)token机制(高并发)
    每次接口请求前先获取一个token,然后再下次请求的时候在请求的header体中加上这个token,后台进行验证,如果验证通过删除token,下次请求再次判断token是否相等,如果不相等即重复提交。

3.如何解决高并发幂等性(重复提交)?

采用(Redis+UUID)方式的 token 校验

​ 核心方法:

​ 1、生成 token

​ 使用 UUID 生成 token 存在redis中,并设置过期时间(30min)

​ 将 token 存在request域中

​ 2、token 校验

​ 请求时将token与redisKey的值进行比较,如果重复则操作成功并删除redisKey,如果不重复则拒绝操作

​ 基本流程:

​ 1、用户发送请求

​ 2、后端生成唯一标识返给前端

​ 3、前端将唯一标识与后端进行比较

​ 4、若重复,请求成功,删除标识,执行业务逻辑;若不重复,则该请求已被响应,请求失败

4.描述Mybatis如何进行批量删除、批量添加?

批量删除: <foreach collection="list" item="uId" separator="," open="(" close=")"> #{uId} </foreach>
批量添加:<foreach collection="list" item="u" separator=","> (#{u.userName},#{u.createTime}) </foreach>
5.### 什么是Redis,Redis优缺点

Redis 是完全开源免费的,是一个高性能(NOSQL)的key-value数据库,Redis使用ANSIC语言编写、支持网络、支持多种数据类型、支持master-slave 模式的数据备份、可基于内存亦可持久化的日志型的Key-Value数据库,并提供多种语言的API。

  • 优点

由于是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作;支持丰富的数据类型 Redis 单个操作是原子性的;多个操作支持事务(通过 MULTI 和 EXEC指令包起来); 可以对存入的Key-Value设置过期时间

  • 缺点
    1、Redis的数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上;
    2、在主节点宕机前有部分数据不能及时同步到从节点上;

6.什么是NoSQL,有哪些特点

NoSQL,泛指非关系型的数据库,NoSQL即Not-Only SQL,它可以作为关系型数据库的良好补充。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的纯动态网站已经显得力不从心,暴露了很多难以克服的问题

NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题

NoSQL的特点:

1、数据模型比较简单;
2、需要灵活性更强的IT系统;
3、对数据库性能要求较高;
4、不需要高度的数据一致性;
5、对于给定key,比较容易映射复杂值的环境

7. Redis内存开发管理(淘汰策略机制)

redis作为优秀的中间缓存件,时常会存储大量的数据,即使采取了集群部署来动态扩容,也应该即时的整理内存,维持系统性能。

在redis中有两种解决方案

一 为数据设置超时时间
expire key time(以秒为单位)--这是最常用的方式
setex(String key, int seconds, String value)--字符串独有的方式

二 采用LRU算法动态将不用的数据删除

内存管理的一种页面置换算法,对于在内存中但又不用的数据块(内存块)叫做LRU,

操作系统会根据哪些数据属于LRU而将其移出内存而腾出空间来加载另外的数据。

1.volatile-lru:设定超时时间的数据中,删除最不常使用的数据.
2.allkeys-lru:查询所有的key中最近最不常使用的数据进行删除,这是应用最广泛的策略.
3.volatile-random:在已经设定了超时的数据中随机删除.
4.allkeys-random:查询所有的key,之后随机删除.
5.volatile-ttl:查询全部设定超时时间的数据,之后排序,将马上将要过期的数据进行删除操作.
6.noeviction:如果设置为该属性,则不会进行删除操作,如果内存溢出则报错返回.
7.volatile-lfu:从所有配置了过期时间的键中驱逐使用频率最少的键
8.allkeys-lfu:从所有键中驱逐使用频率最少的键

8. Redis持久化机制( RDB和AOF区别)

持久化就是把内存的数据写到磁盘中去,防止服务宕机了内存数据丢失。
Redis 提供了两种持久化方式: RDB(默认)和AOF

RDB:是redis的默认持久化机制。
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

快照条件:

1、服务器正常关闭时  ./bin/redis-cli shutdown
2、key满足一定条件,会进行快照 
 vim redis.conf搜索save
       :/save
      save 900 1     //每900秒(15分钟)至少1个key发生变化,产生快照
      save 300 10   //每300秒(5分钟)至少10个key发生变化,产生快照
      save 60 10000   //每60秒(1分钟)至少10000个key发生变化,产生快照

AOF

由于快照方式是在一定间隔时间做一次的,所以如果redis意外down 掉的话,就会丢失最后一次快照后的所有修改。如果应用要求不能丢失 任何修改的话,可以采用aof持久化方式。

Append-only file:aof 比快照方式有更好的持久化性,是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write 函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

9.Redis和MYSQL如何保持一致性(同步)

一致性
  强一致性
  弱一致性
  最终一至性
实时同步:对强一致要求比较高的,应采用实时同步方案,即查询缓存查询不到再从DB查询,保存到缓存;更新缓存时,先更新数据库,再将缓存的设置过期(建议不要去更新缓存内容,直接设置缓存过期)。

异步对队:对于并发程度较高的,可采用异步队列的方式同步,可采用MQ等消息中间件处理消息生产和消费或者通过定时任务定期处理数据同步。

10.什么是缓存穿透,解决方案、如何避免缓存穿透

缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时需要从数据库查询,查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,造成缓存穿透;
解决办法

持久层查询不到就缓存空结果,查询时先判断缓存中是否exists(key) ,如果有直接返回空,没有则查询后返回,
注意insert时需清除查询的key,否则即便DB中有值也查询不到(当然也可以设置空缓存的过期时间)

  • 1、不管数据实际上存不存在,我们都把这个键存到缓存中(有效期设置的短一些,比如一分钟到三分钟),然后值设置为一个特定值,业务中如果获取到的结果是这个特定值,则报错返回。

  • 2、是使用 redis 的布隆过滤器(Bloom Filter),将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。

可尝试通过对请求地址参数拼接进行加密的方式完成。

11.什么是缓存雪崩,解决方案

雪崩:缓存大量失效的时候,引发大量查询数据库。
如果缓存集中在一段时间内失效,发生大量的缓存穿透,所有的查询都落在数据库上,造成了缓存雪崩。
这个没有完美解决办法,但可以分析用户行为,尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。

  • 加锁排队. 限流 – 限流算法.
    在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。

  • 数据预热
    可以通过缓存reload机制,预先去更新缓存,再即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀

12.什么是Redis集群、Redis集群特点(Cluster)

Redis Cluster是Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。

Redis集群搭建至少需要3(Master)+3(Slave)才能建立集群,其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用
Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有
节点连接。

1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
2、节点的fail是通过集群中超过半数的节点检测失效时才生效。
3、客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
4、redis-cluster把所有的物理节点映射到[0-16383]slot上(不一定是平均分配),cluster 负责维护
5、Redis集群预分好16384个哈希槽,当需要在 Redis 集群中放置一个 key-value 时, redis 先对key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节

13.什么情况下集群单个master不可用?什么情况下整个集群不可用?

投票机制。投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉。
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. 如果集群超过半数以上master挂掉,无论是否有slave,集群进入fail状态.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值