Redis是什么
今天,“我”不自量力的面试了某大厂的Java开发岗位,迎面走来一位风尘仆仆的中年男子,手里拿着屏幕还亮着的Mac 。他冲着我礼貌的笑了笑,然后说了句“不好意思,让你久等了”,然后示意我坐下,说:“我们开始吧,看了你的简历,觉得你对Redis应该掌握的不错,我们今天就来讨论下Redis……” 。我想:“来就来,兵来将挡水来土掩” 。
Redis是什么
面试官:你先来说下Redis是什么吧!
我:(这不就是总结下Redis的定义和特点嘛)Redis是C语言开发的一个开源的(遵从BSD协议)高性能键值对(key-value)的内存数据库,可以用作数据库、缓存、消息中间件等 。
它是一种NoSQL(not-onlysql,泛指非关系型数据库)的数据库 。
我顿了一下,接着说,Redis作为一个内存数据库:
性能优秀,数据在内存中,读写速度非常快,支持并发10WQPS 。
单进程单线程,是线程安全的,采用IO多路复用机制 。
丰富的数据类型,支持字符串(strings)、散列(hashes)、列表(lists)、集合(sets)、有序集合(sortedsets)等 。
支持数据持久化 。
可以将内存中数据保存在磁盘中,重启时加载 。
主从复制,哨兵,高可用 。
可以用作分布式锁 。
可以作为消息中间件使用,支持发布订阅 。
五种数据类型
面试官:总结的不错,看来是早有准备啊 。刚来听你提到Redis支持五种数据类型,那你能简单说下这五种数据类型吗?
我:当然可以,但是在说之前,我觉得有必要先来了解下Redis内部内存管理是如何描述这5种数据类型的 。
说着,我拿着笔给面试官画了一张图:
文章插图
使用SpringCache集成Redis
SpringCache具备很好的灵活性,不仅能够使用SPEL(springexpressionlanguage)来定义缓存的Key和各种Condition,还提供了开箱即用的缓存临时存储方案,也支持和主流的专业缓存如EhCache、Redis、Guava的集成 。定义接口UserService.java:
publicinterfaceUserService{Usersave(Useruser);voiddelete(intid);Userget(Integerid);}
接口实现类UserServiceImpl.java:
@ServicepublicclassUserServiceImplimplementsUserService{publicstaticLoggerlogger=LogManager.getLogger(UserServiceImpl.class);privatestaticMap
为了方便演示数据库的操作,这里直接定义了一个Map
@Cachable
@CachePut
@CacheEvict
测试类:UserController
@RestController@RequestMapping("/user")publicclassUserController{publicstaticLoggerlogger=LogManager.getLogger(UserController.class);@AutowiredprivateStringRedisTemplatestringRedisTemplate;@AutowiredprivateRedisTemplateredisCacheTemplate;@AutowiredprivateUserServiceuserService;@RequestMapping("/test")publicvoidtest(){redisCacheTemplate.opsForValue().set("userkey",newUser(1,"张三",25));Useruser=(User)redisCacheTemplate.opsForValue().get("userkey");logger.info("当前获取对象:{}",user.toString());}@RequestMapping("/add")publicvoidadd(){Useruser=userService.save(newUser(4,"李现",30));logger.info("添加的用户信息:{}",user.toString());}@RequestMapping("/delete")publicvoiddelete(){userService.delete(4);}@RequestMapping("/get/{id}")publicvoidget(@PathVariable("id")StringidStr)throwsException{if(StringUtils.isBlank(idStr)){thrownewException("id为空");}Integerid=Integer.parseInt(idStr);Useruser=userService.get(id);logger.info("获取的用户信息:{}",user.toString());}}
用缓存要注意,启动类要加上一个注解开启缓存:
@SpringBootApplication(exclude=DataSourceAutoConfiguration.class)@EnableCachingpublicclassApplication{publicstaticvoidmain(String[]args){SpringApplication.run(Application.class,args);}}
①先调用添加接口:http://localhost:8082/user/add
文章插图
补充一下:Redis4.0加入了LFU(leastfrequencyuse)淘汰策略,包括volatile-lfu和allkeys-lfu,通过统计访问频率,将访问频率最少,即最不经常使用的KV淘汰 。
持久化
面试官:你对Redis的持久化机制了解吗?能讲一下吗?
我:Redis为了保证效率,数据缓存在了内存中,但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中,以保证数据的持久化 。
Redis的持久化策略有两种:
RDB:快照形式是直接把内存中的数据保存到一个dump的文件中,定时保存,保存策略 。
AOF:把所有的对Redis的服务器进行修改的命令都存到一个文件里,命令的集合 。Redis默认是快照RDB的持久化方式 。
当Redis重启的时候,它会优先使用AOF文件来还原数据集,因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整 。你甚至可以关闭持久化功能,让数据只在服务器运行时存 。
面试官:那你再说下RDB是怎么工作的?我:默认Redis是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件dump.rdb 。工作原理简单说一下:当Redis需要做持久化时,Redis会fork一个子进程,子进程将数据写到磁盘上一个临时RDB文件中 。
当子进程完成写临时文件后,将原来的RDB替换掉,这样的好处是可以copy-on-write 。
我:RDB的优点是:这种文件非常适合用于备份:比如,你可以在最近的24小时内,每小时备份一次,并且在每个月的每一天也备份一个RDB文件 。
这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本 。RDB非常适合灾难恢复 。
RDB的缺点是:如果你需要尽量避免在服务器故障时丢失数据,那么RDB不合适你 。
面试官:那你要不再说下AOF?
我:(说就一起说下吧)使用AOF做持久化,每一个写命令都通过write函数追加到appendonly.aof中,配置方式如下:
appendfsyncyesappendfsyncalways#每次有数据修改发生时都会写入AOF文件 。appendfsynceverysec#每秒钟同步一次,该策略为AOF的缺省策略 。
AOF可以做到全程持久化,只需要在配置中开启appendonlyyes 。这样Redis每执行一个修改数据的命令,都会把它添加到AOF文件中,当Redis重启时,将会读取AOF文件进行重放,恢复到Redis关闭前的最后时刻 。
我顿了一下,继续说:使用AOF的优点是会让Redis变得非常耐久 。可以设置不同的Fsync策略,AOF的默认策略是每秒钟Fsync一次,在这种配置下,就算发生故障停机,也最多丢失一秒钟的数据 。
缺点是对于相同的数据集来说,AOF的文件体积通常要大于RDB文件的体积 。根据所使用的Fsync策略,AOF的速度可能会慢于RDB 。
面试官又问:你说了这么多,那我该用哪一个呢?
我:如果你非常关心你的数据,但仍然可以承受数分钟内的数据丢失,那么可以额只使用RDB持久 。
AOF将Redis执行的每一条命令追加到磁盘中,处理巨大的写入会降低Redis的性能,不知道你是否可以接受 。
数据库备份和灾难恢复:定时生成RDB快照非常便于进行数据库备份,并且RDB恢复数据集的速度也要比AOF恢复的速度快 。
当然了,Redis支持同时开启RDB和AOF,系统重启后,Redis会优先使用AOF来恢复数据,这样丢失的数据会最少 。
主从复制
面试官:Redis单节点存在单点故障问题,为了解决单点问题,一般都需要对Redis配置从节点,然后使用哨兵来监听主节点的存活状态,如果主节点挂掉,从节点能继续提供缓存功能,你能说说Redis主从复制的过程和原理吗?我有点懵,这个说来就话长了 。但幸好提前准备了:主从配置结合哨兵模式能解决单点故障问题,提高Redis可用性 。
从节点仅提供读操作,主节点提供写操作 。对于读多写少的状况,可给主节点配置多个从节点,从而提高响应效率 。
我顿了一下,接着说:关于复制过程,是这样的:
从节点执行slaveof[masterIP][masterPort],保存主节点信息 。
从节点中的定时任务发现主节点信息,建立和主节点的Socket连接 。
从节点发送Ping信号,主节点返回Pong,两边能互相通信 。
连接建立后,主节点将所有数据发送给从节点(数据同步) 。
主节点把当前的数据同步给从节点后,便完成了复制的建立过程 。接下来,主节点就会持续的把写命令发送给从节点,保证主从数据一致性 。
面试官:那你能详细说下数据同步的过程吗?
(我心想:这也问的太细了吧)我:可以 。Redis2.8之前使用sync[runId][offset]同步命令,Redis2.8之后使用psync[runId][offset]命令 。
两者不同在于,Sync命令仅支持全量复制过程,Psync支持全量和部分复制 。
介绍同步之前,先介绍几个概念:
runId:每个Redis节点启动都会生成唯一的uuid,每次Redis重启后,runId都会发生变化 。
offset:主节点和从节点都各自维护自己的主从复制偏移量offset,当主节点有写入命令时,offset=offset+命令的字节长度 。
从节点在收到主节点发送的命令后,也会增加自己的offset,并把自己的offset发送给主节点 。
这样,主节点同时保存自己的offset和从节点的offset,通过对比offset来判断主从节点数据是否一致 。
repl_backlog_size:保存在主节点上的一个固定长度的先进先出队列,默认大小是1MB 。
主节点发送数据给从节点过程中,主节点还会进行一些写操作,这时候的数据存储在复制缓冲区中 。
从节点同步主节点数据完成后,主节点将缓冲区的数据继续发送给从节点,用于部分复制 。
主节点响应写命令时,不但会把命名发送给从节点,还会写入复制积压缓冲区,用于复制命令丢失的数据补救 。
文章插图
上面是Psync的执行流程,从节点发送psync[runId][offset]命令,主节点有三种响应:
FULLRESYNC:第一次连接,进行全量复制
CONTINUE:进行部分复制
ERR:不支持psync命令,进行全量复制
面试官:很好,那你能具体说下全量复制和部分复制的过程吗?
我:可以!
文章插图
上面是全量复制的流程 。主要有以下几步:
从节点发送psync?-1命令(因为第一次发送,不知道主节点的runId,所以为?,因为是第一次复制,所以offset=-1) 。
主节点发现从节点是第一次复制,返回FULLRESYNC{runId}{offset},runId是主节点的runId,offset是主节点目前的offset 。
从节点接收主节点信息后,保存到info中 。
主节点在发送FULLRESYNC后,启动bgsave命令,生成RDB文件(数据持久化) 。
主节点发送RDB文件给从节点 。到从节点加载数据完成这段期间主节点的写命令放入缓冲区 。
从节点清理自己的数据库数据 。
从节点加载RDB文件,将数据保存到自己的数据库中 。如果从节点开启了AOF,从节点会异步重写AOF文件 。
关于部分复制有以下几点说明:
①部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施,使用psync[runId][offset]命令实现 。
当从节点正在复制主节点时,如果出现网络闪断或者命令丢失等异常情况时,从节点会向主节点要求补发丢失的命令数据,主节点的复制积压缓冲区将这部分数据直接发送给从节点 。
这样就可以保持主从节点复制的一致性 。补发的这部分数据一般远远小于全量数据 。
②主从连接中断期间主节点依然响应命令,但因复制连接中断命令无法发送给从节点,不过主节点内的复制积压缓冲区依然可以保存最近一段时间的写命令数据 。
③当主从连接恢复后,由于从节点之前保存了自身已复制的偏移量和主节点的运行ID 。因此会把它们当做psync参数发送给主节点,要求进行部分复制 。④主节点接收到psync命令后首先核对参数runId是否与自身一致,如果一致,说明之前复制的是当前主节点 。
之后根据参数offset在复制积压缓冲区中查找,如果offset之后的数据存在,则对从节点发送+COUTINUE命令,表示可以进行部分复制 。因为缓冲区大小固定,若发生缓冲溢出,则进行全量复制 。
⑤主节点根据偏移量把复制积压缓冲区里的数据发送给从节点,保证主从复制进入正常状态 。
哨兵
面试官:那主从复制会存在哪些问题呢?
我:主从复制会存在以下问题:
一旦主节点宕机,从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预 。
主节点的写能力受到单机的限制 。
主节点的存储能力受到单机的限制 。
原生复制的弊端在早期的版本中也会比较突出,比如:Redis复制中断后,从节点会发起psync 。
此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时,可能会造成毫秒或秒级的卡顿 。
面试官:那比较主流的解决方案是什么呢?
我:当然是哨兵啊 。
面试官:那么问题又来了 。那你说下哨兵有哪些功能?
文章插图
我:如图,是RedisSentinel(哨兵)的架构图 。RedisSentinel(哨兵)主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换 。
RedisSentinel最小配置是一主一从 。Redis的Sentinel系统可以用来管理多个Redis服务器 。
该系统可以执行以下四个任务:
监控:不断检查主服务器和从服务器是否正常运行 。
通知:当被监控的某个Redis服务器出现问题,Sentinel通过API脚本向管理员或者其他应用程序发出通知 。
自动故障转移:当主节点不能正常工作时,Sentinel会开始一次自动的故障转移操作,它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点,并且将其他的从节点指向新的主节点,这样人工干预就可以免了 。
配置提供者:在RedisSentinel模式下,客户端应用在初始化时连接的是Sentinel节点集合,从中获取主节点的信息 。
面试官:那你能说下哨兵的工作原理吗?
我:话不多说,直接上图:
文章插图
①每个Sentinel节点都需要定期执行以下任务:每个Sentinel以每秒一次的频率,向它所知的主服务器、从服务器以及其他的Sentinel实例发送一个PING命令 。(如上图)
文章插图
②如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值,那么这个实例会被Sentinel标记为主观下线 。(如上图)
文章插图
③如果一个主服务器被标记为主观下线,那么正在监视这个服务器的所有Sentinel节点,要以每秒一次的频率确认主服务器的确进入了主观下线状态 。
文章插图
④如果一个主服务器被标记为主观下线,并且有足够数量的Sentinel(至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断,那么这个主服务器被标记为客观下线 。
文章插图
⑤一般情况下,每个Sentinel会以每10秒一次的频率向它已知的所有主服务器和从服务器发送INFO命令 。
当一个主服务器被标记为客观下线时,Sentinel向下线主服务器的所有从服务器发送INFO命令的频率,会从10秒一次改为每秒一次 。
文章插图
⑥Sentinel和其他Sentinel协商客观下线的主节点的状态,如果处于SDOWN状态,则投票自动选出新的主节点,将剩余从节点指向新的主节点进行数据复制 。
文章插图
⑦当没有足够数量的Sentinel同意主服务器下线时,主服务器的客观下线状态就会被移除 。
当主服务器重新向Sentinel的PING命令返回有效回复时,主服务器的主观下线状态就会被移除 。
面试官:不错,面试前没少下工夫啊,今天Redis这关你过了,明天找个时间我们再聊聊其他的 。(露出欣慰的微笑)
我:没问题 。
总结
本文在一次面试的过程中讲述了Redis是什么,Redis的特点和功能,Redis缓存的使用,Redis为什么能这么快,Redis缓存的淘汰策略,持久化的两种方式,Redis高可用部分的主从复制和哨兵的基本原理 。
只要功夫深,铁杵磨成针,平时准备好,面试不用慌 。虽然面试不一定是这样问的,但万变不离其“宗” 。
责任编辑:lq
.dfma {position: relative;width: 1000px;margin: 0 auto;}.dfma a::after {position: absolute;left: 0;bottom: 0;width: 30px;line-height: 1.4;text-align: center;background-color: rgba(0, 0, 0, .5);color: #fff;font-size: 12px;content: "广告";}.dfma img {display: block;}
文章插图
推荐阅读
- 香槟玫瑰花语是什么?
- 山地玫瑰的花语是什么?
- 绿玫瑰花语是什么?
- 金玫瑰花语是什么?
- 数字经济是什么意思通俗_数字经济的本质和特征详解
- 花卉柳芽是什么?
- 冰灯玉露的花语是什么?
- 阮籍的诗歌代表作是什么_简述阮籍诗歌的艺术成就
- 百合花的花期是什么时候?
- 凤仙花的花语是什么?