Redis面试题理解

目录

Redis简介

Redis 概述

常用数据类型

String类型小节面试分析

Hash类型小节面试分析

List类型小节面试分析

Set类型小节面试分析

单点登陆

秒杀队列

业务描述

投票系统

业务描述

购物车简易实现

业务描述

Redis持久化方式

Rdb方式持久化

概述

小节面试分析

Aof方式数据持久化

概述

Redis 事务处理实践

概述

基本指令

Redis主从复制

简介

基本架构

主从同步原理分析

小节面试分析

Redis哨兵模式简介

基本架构

哨兵工作原理分析

 Redis集群高可用

简述

基本架构

小节面试分析

Java中本地缓存

简介为什么要Cache

本地缓存的设计：

Cache接口设计

Cache默认存储设计

SynchronizedCache 设计

LoggingCache 设计

FifoCache设计

LruCache 设计

---

Redis简介

我们现在的项目架构中，基本上是Web服务器(Tomcat)和数据库独立部署，独占服务器资源，随着用户数的增长，并发读写数据库，会加大数据库访问压力，导致性能的下降，严重时直接导致系统宕机，例如：

 此时，我们可以在Tomcat同服务器上中增加本地缓存，并在外部增加分布式缓存，缓存热门数据。也就是通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。例如：

 

 基于这样的一种架构设计，于是类似redis的一些分布式数据库就诞生了。

Redis 概述

Redis是一个key-value存储系统（官网：http://redis.io），是一个分布式缓存数据库。

常用数据类型

Reids中基础数据结构包含字符串、散列，列表，集合，有序集合。工作中具体使用哪种类型要结合具体场景。

String类型小节面试分析

• 博客的字数统计如何实现？（strlen）
• 如何将审计日志不断追加到指定key?(append)
• 你如何实现一个分布式自增id？(incr-雪花算法)
• 如何实现一个博客的的点赞操作？(incr,decr)

Hash类型小节面试分析

• 发布一篇博客需要写内存吗？（需要,hmset）
• 浏览博客内容会怎么做？（hmget）
• 如何判定一篇博客是否存在？(hexists)
• 删除一篇博客如何实现？(hdel)
• 分布式系统中你登录成功以后是如何存储用户信息的？(hmset)

List类型小节面试分析

• 如何基于redis实现一个队列结构？（lpush/rpop）

• 如何基于redis实现一个栈结构？(lpush/lpop)

• 如何基于redis实现一个阻塞式队列？(lpush/brpop)

• 如何实现秒杀活动的公平性？(先进先出-FIFO

• 通过list结构实现一个消息队列(顺序)吗？（可以，FIFO->lpush,rpop）

• 用户注册时的邮件发送功能如何提高其效率？(邮件发送是要调用三方服务，底层通过队列优化其效率，队列一般是list结构)

• 如何动态更新商品的销量列表？(卖的好的排名靠前一些，linsert)

• 商家的粉丝列表使用什么结构实现呢？(list结构)

Set类型小节面试分析

• 朋友圈的点赞功能你如何实现？（sadd,srem,smembers,scard）

单点登陆

在分布式系统中,通过会有多个服务,我们登录了一个服务以后,再访问其它服务时,不想再登录,就需要有一套单独的认证系统,我们通常会称之为单点登录系统,在这套系统中提供一个认证服务器,服务完成用户身份认证,在一些中小型分布式系统中中,我们通常会借助redis存储用户的认证信息,例如:

 

秒杀队列

业务描述

在设计一个秒杀或抢购系统时,为了提高系统的响应速度,通常会将用户的秒杀或抢购请求先存储到一个redis队列,这里我们就基于redis实现一个先进先出队列,例如:

 

投票系统

业务描述

在很多系统中设计中,都会有一个活动设计,开启一个活动之前,可以对这个活动的支持力度先进行一个调查,例如基于这个活动设计一个投票系统,例如:

购物车简易实现

业务描述

简易购物车业务设计如图所示:

 

Redis持久化方式

Redis中为了保证在系统宕机(类似进程被杀死)情况下，能更快的进行故障恢复，设计了两种数据持久化方案，分别为rdb和aof方式

Rdb方式持久化

概述

Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。

小节面试分析

    Redis中的save和bgsave有什么不同？

•     Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
•     BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

RDB持久化机制有哪些优点？

第一：RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据.
第二：RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
第三：相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

RDB持久化机制有哪些缺点？

假如redis故障时，要尽可能少的丢失数据，那么RDB方式不太好，它都是每隔5分钟或更长时间做一次快照，这个时候一旦redis进程宕机，那么会丢失最近几分钟的数据。

Aof方式数据持久化

概述

Aof方式是通过记录写操作日志的方式,记录redis数据的一种持久化机制,这个机制默认是关闭的。

小节面试分析

如何理解AOF方式中的rewrite操作？

redis中的可以存储的数据是有限的，很多数据可能会自动过期，也可能会被用户删除或被redis用缓存清除的算法清理掉。也就是说redis中的数据会不断淘汰掉旧的，只有一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，最好导致文件很大。
所以,AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，但redis内存现在10万数据; 于是，基于内存中当前的10万数据构建一套最新的日志，然后到AOF文件中; 覆盖之前的老日志，从而，确保AOF日志文件不会过大，保持跟redis内存数据量一致.

AOF持久化机制有哪些优点？

第一：AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据.
第二：AOF日志文件通常以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，并且文件不容易破损，即使文件尾部破损，也很容易修复。
第三：AOF日志文件过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的日志进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
第四：AOF日志文件的命令通过易读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据.

AOF持久化机制有哪些缺点？

第一：对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
第二：AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
第三：AOF这种基于命令日志方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite（重写）过程导致的bug，因此每次rewrite（重写）并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

如何选择redis的持久化方式？

第一：不要仅仅使用RDB，因为那样会导致你丢失很多数据。
第二：也不要仅仅使用AOF，因为AOF做冷备没有RDB做冷备进行数据恢复的速度快,并且RDB简单粗暴的数据快照方式更加健壮。
第三：综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备。
 

Redis 事务处理实践

概述

Redis采用了乐观锁方式进行事务控制，它使用watch命令监视给定的key，当exec（提交事务）的时候,如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key。注意watch的key是对整个连接有效的，如果连接断开，监视和事务都会被自动清除。当然exec，discard，unwatch命令都会清除连接中的所有监视。

基本指令

redis进行事务控制时，通常是基于如下指令进行实现，例如：

    multi 开启事务
    exec 提交事务
    discard 取消事务
    watch 监控，如果监控的值发生变化，则提交事务时会失败
    unwatch 去掉监控

Redis保证一个事务中的所有命令要么都执行，要么都不执行(原子性)。如果在发送EXEC命令前客户端断线了，则Redis会清空事务队列，事务中的所有命令都不会执行。而一旦客户端发送了EXEC命令，所有的命令就都会被执行，即使此后客户端断线也没关系，因为Redis中已经记录了所有要执行的命令。
 

Redis主从复制

简介

单个Redis支持的读写能力还是有限的,此时我们可以使用多个redis来提高redis的并发处理能力,这些redis如何协同,就需要有一定的架构设计,这里我们首先从主从(Master/Slave)架构进行分析和实现.

基本架构

redis主从架构如图所示:，其中,master负责读写,并将数据同步到salve,从节点负责读操作.

 

主从同步原理分析

Redis的主从结构可以采用一主多从结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

• Redis全量同步：

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
1）从服务器连接主服务器，发送SYNC（同步）命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
 

• Redis增量同步

Redis增量复制是指Slave初始化后，开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

小节面试分析

•     如果redis要支持10万+的的并发你会怎么做？

单机的redis几乎不太可能说QPS超过10万+，除非一些特殊情况，比如你的机器性能特别好，配置特别高，物理机，维护做的特别好，而且你的整体的操作不是太复杂，一般的单机也就在几万。真正实现redis的高并发，需要读写分离。对缓存而言，一般都是用来支撑读高并发的，写的请求是比较少的，可能写请求也就一秒钟几千。读的请求相对就会比较多,例如,一秒钟二十万次读。所以redis的高并发可以基于主从架构与读写分离机制进行实现。

•     Redis的replication机制是怎样的？

（1）redis采用异步方式复制数据到slave节点。
（2）一个master node是可以配置多个slave node的。
（3）slave node也可以连接其他的slave node。
（4）slave node做复制的时候，是不会block master node的正常工作的。
（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了。
（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。
 

Redis哨兵模式
简介

哨兵（Sentinel）是Redis的主从架构模式下，实现高可用性（high availability）的一种机制。
由一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

基本架构

哨兵工作原理分析

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值(这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒)， 则这个实例会被 Sentinel 标记为主观下线。

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
8): 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
 

 Redis集群高可用

简述

Redis单机模式可靠性保证不是很好，容易出现单点故障，同时其性能也受限于CPU的处理能力，实际开发中Redis必然是高可用的，所以单机模式并不是我们的终点，我们需要对目前redis的架构模式进行升级。
Sentinel模式做到了高可用，但是实质还是只有一个master在提供服务(读写分离的情况本质也是master在提供服务)，当master节点所在的机器内存不足以支撑系统的数据时，就需要考虑集群了。
Redis集群架构实现了对redis的水平扩容，即启动N个redis节点，将整个数据分布存储在这N个redis节点中，每个节点存储总数据的1/N。redis集群通过分区提供一定程度的可用性，即使集群中有一部分节点失效或无法进行通讯，集群也可以继续处理命令请求。
 

基本架构

对于redis集群(Cluster),一般最少设置为6个节点,3个master,3个slave,其简易架构如下:

小节面试分析

• Redis的高并发跟整个系统的高并发是什么关系？

 第一:Redis需要高并发的话，要把底层的缓存做得很好。例如，mysql的高并发，是通过一系列复杂的分库分表，订单系统，事务要求的QPS到几万，就比较高了。
第二：要做一些电商的商品详情页，真正的超高并发，QPS上十万，甚至是百万，一秒钟百万的请求量，只有redis是不够的，但是redis是整个大型的缓存架构中，支撑高并发的架构里面，非常重要的一个环节。
第三：你的底层的缓存中间件，缓存系统，必须能够支撑的起我们说的那种高并发，其次，再经过良好的整体的缓存架构的设计（多级缓存架构、热点缓存），支撑真正的上十万，甚至上百万的高并发。
 

Java中本地缓存

简介
为什么要Cache

•     降低数据库的访问压力.
•     提高查询的性能,改善用户体验.

你都了解哪些Cache?

•     浏览器缓存
•     数据持久层的Cache(MyBatis中的Cache设计)
•     逻辑处理层的Cache(Spring中的Cache)
•     CPU的高速缓存

对本地缓存你会如何设计

•     数据的存储结构(散列存储)
•     数据的淘汰算法(FIFO,LRU)
•     任务调度策略(定时刷新缓存)
•     缓存日志的记录(命中率)
•     GC时会缓存数据的影响
   

本地缓存的设计：

• Cache接口设计

• Cache默认存储设计

• SynchronizedCache 设计

• LoggingCache 设计

• FifoCache设计

• LruCache 设计