用心分享：喜欢可以关注哈

面试官：你日常开发中用到的非关系型数据库是用的哪个啊？

小白：平常开发中采用的是redis的。因为它有着丰富的数据结构，和十分给力的操作速度每秒读11万次，写8万次每秒。

面试官：那redis中常用的数据类型有哪些啊？

小白：常用的有五种：String,List,Set,ZSet,Hash,然后还有三种使用比较少的，GEO,hyperloglog,bitmap。

面试官：那你都知道他们的使用场景么，比如最常用的String？

小白：String类型常用做计数器，和分布式锁中

面试官：那你提到了分布式锁，那redis对分布式锁是怎么实现的呢？

小白：主要使用的是两个命令，一个setnx:如果key不存在在进行一个设置，还有一个expire:给一个key设置过期时间，用于如果一个线程跑的过程挂了，没有自己去释放锁，那么redis会进行一个自动释放。

面试官：如果你通过两条命令去进行一个锁的设置，是无法保证原子性的吧，这种情况你怎么处理？

小白：setnx和expire命令是可以当作set命令的参数进行整合的，那样整合成一条命令就能保证原子性了,格式如下：

 set key value [ex seconds] [px milliseconds] [nx|xx]

ex seconds： 为键设置秒级过期时间。
px milliseconds： 为键设置毫秒级过期时间。
nx： 键必须不存在， 才可以设置成功， 用于添加。
xx： 与nx相反， 键必须存在， 才可以设置成功， 用于更新。

面试官：那这样还是会存在一个问题，假如你业务代码没有执行完，然后你的redis又把锁自动释放了，然后其他线程又可以获取到锁，那样不就还是又线程安全问题了？

小白：是的，但是针对这种问题redis官网也帮我们想了一种解决方案，也就是redis的红锁

面试官：那你可以和我说说redis的红锁是怎么回事么？

小白：sorry,i don’t no

面试官：你应该还记得怎么进来的把？我就不送了

小白：这个红锁有兴趣可以看看官网，给大家来一个传送门：redis红锁

面试官：那看你还知道在哪看api就再问一个问题好啦，redis的击穿，雪崩，穿透，都了解没，然后怎么解决呢？

小白：先从雪崩开始说好啦，雪崩就是指再某一个时间点，很多热点key同一时间失效了，那样就会导致之前查redis的请求都去查mysql了，那样就会导致mysql扛不住，然后直接挂了，解决方法就是redis再给这些热点key设置过期时间的时候不要都设置一个时间点，可以加一个随机数。再说击穿好啦，击穿就是我很多请求，一直请求一个热点key，如果这个热点key设置了过期时间，那么它过期那一瞬间，所有请求就全都打到mysql上了，那样也可能导致数据库挂了，解决方案就是给这样的热点key设置永不过期。也就是不设置过期时间就好啦。然后还有穿透，穿透就是我发起的请求再redis中不存在，那样肯定会去请求mysql了的，但是实际上再mysql重也是没有的，比如我查id=-1这样类似的数据。这个解决方案的话就是增加一个布隆过滤器进行处理的。

面试官：那看你答得还行，说说redis得持久化机制把

小白：redis得持久化机制有两种，一种是RDB就是多长时间内多少key发生了变化，就使用一次快照得方式进行一次持久化，还有就是AOF持久化，有三个取值，一个是不开启，一个是每一次对key得修改都以记录日志得方式进行一个记录，还有就是一秒钟记录一次，一半采用最后最后一种。

面试官：那你再和我说说这两种得使用场景，和优劣

小白：直接看官网不会？

RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.
  RDB的缺点
• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你-
• 可以调节重写日志文件的频率来提高数据集的耐久度.
  AOF 优点
• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
  AOF 缺点
• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

面试官：那你再跟我说说redis得哨兵模式好了

• Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。