面试中部分redis问题

redis问题1：为什么要使用redis？

   1、支持多种类型，可满足多种应用场景
   2、支持主从复制模型、哨兵模式、和集群；大限度实现高可用
   3、可将数据持久化至磁盘，保留数据
   4、存储在内存中，访问速度比存储在磁盘中快很多；高性能、高并发

redis问题2：redis应用场景？

string类型： 金牛中会有一些新手教程文章等，需计算阅读量，使用string类型；token、验证码；incr指令的原子性
hash类型： 恒鲜生中会有购物车的需求，就是依靠hash类型实现的，hash类型存储对象
list类型： 金牛中商品列表、文章列表等，利用lrange很方便实现数据量大的分页，任务队列（确保先后顺序）
set类型： 共同关注，共同好友等，利用set类型中的交集处理
zset类型： 金牛中的排行榜小程序、订单超时处理；利用了zset的分值进行排序，权重队列
hyperloglog类型： 今日登录ip数量，基数不重复

redis问题3：redis的持久化机制？

概念： 就是吧内存中的数据写到磁盘中，避免服务宕机导致内存数据丢失
分类： RDB 和 AOF （默认是RDB）
RDB： Redis Data Base；将内存中数据以快照的方式写到磁盘中；服务器正常关闭时，或者key变化满足条件时
   优点：快照保存和还原数据速度快；适用于灾难备份；进行数据保存时，不会影响主进程
   缺点：不适用小内存机器，因为快照保存和还原都需要占用内存；有可能造成数据丢失
AOF： Append-only file；将每个写的指令保存到.aof文件，重启redis时，就重新执行一篇指令
   优点：不会有数据丢失（最多丢失1秒的数据）；
   缺点：保存和还原数据时速度慢，指令过多时有可能有冗余指令

redis问题4：redis的数据淘汰策略？

概念： 当内存不足时，redis会根据缓存策略淘汰部分keys
最大缓存配置： 在redis中，允许用户设置的最大使用内存大小是 512G
6种淘汰策略：
   volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
   volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰
   volatile-random：从已设置过期时间的数据集中任意选择数据淘汰
   allkeys-lru：从数据集中挑选最近最少使用的数据淘汰
   allkeys-random：从数据集中任意选择数据淘汰
   no-enviction（驱逐）：禁止驱逐数据

redis问题5：redis与数据库的一致性？

   实时同步（@Cacheable等注解）；非实时同步（定时任务）；非实时同步（异步队列<延时队列>）

redis问题6：redis的缓存穿透？

概念： 查询一个不存在的数据时，每次都要去数据库查询，造成缓存穿透
解决： 通过布隆过滤器(BloomFilter)判断是否合法请求，如：关键参数进行加密；就查询不到的数据也缓存到redis中，过期时间设置得短一些

redis问题7：redis的主从复制？

概念： 一主多从；主服务（master）只负责写，从服务（slave）只负责读
目的： 实现redis服务器的高可用、高并发、高性能；解决单台服务内存容量不足、处理能力有限等问题
缺点： 主服务（master）挂了，整个服务都不可用

redis问题8：redis的哨兵模式？

概念： 监控redis服务的主从复制模式，一旦发现master服务挂了，立即从slave服务中推选一个出来当做新的master服务，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机
目的： 解决主从复制模式中的缺点
缺点： 哨兵模式进行监控也需要耗费资源
哨兵是作为独立进程，在独立运行的；心跳机制，哨兵发命令给redis服务，等待回应，正常是3秒或5秒发送一次

redis问题9：redis的缓存雪崩？

概念： redis挂掉、服务宕机、同一时间过期大量的keys、热点key，导致请求全部到数据库
解决热点key问题： 使用锁；过期时间不设置，在value值里设置，进行异步更新
解决过期时间问题： 缓存的时候，让过期时间均匀分布，大幅度的减少缓存在同一时间过期
解决服务宕机问题：
   事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。
   事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
   事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

redis问题10：redis集群与集群容错？

集群概念： 多个主多个从（至少3个主3个从），多个主之间去中心化结构
容错概念： 在与一台redis服务在同步时，出现同步不了的情况；只有在半数以上服务都与该台服务同步不了时，才会判定为服务挂了