Redis中面试常见的问题整理

1、Redis中数据结构与使用场景

A、string（字符串）
是key-value结构
value可以是字符串，整数，浮点型
主要应用与常规的key-value的缓存（这也是redis常见的使用）
B、list（链表）
链表中每一个节点都可以是一个字符串，并且节点中的内容可以重复，从链表的两端进行出队或入队操作
主要应用：
a、消息队列
b、关注队列，粉丝队列等
C、hash（散列）
包含键值对的散列表，键值不能重复
应用场景：
由于自身的特点，可以用于存储拥有多个特征的实体类型（如用户），可以用于修改某一个属性
D、set（集合）
是一个无序集合，集合中每一个元素都是唯一的
主要应用：
a、共同好友，共同喜好等玩家信息的存储
b、统计网站访问ip或者防止重复登陆等
c、好友推荐（好友推荐时，根据tag求交集，大于某个阈值就可以推荐）
主要应用于与好友相关的内容
E、zset（有序集合）
是一个有序集合，字符串成员(member)与浮点数分值(score)之间的有序映射，元素的排列顺序由分值的大小决定。元素带有权值
主要应用：
a、排行榜
b、带有权重的消息队列（可以处理优先级高的消息）

2、redis的持久化机制

redis主要有两种持久化化机制：快照和AOF机制
快照：对一段时间的内存中的redis数据快照到磁盘中，不会影响现有redis对外提供服务
主要问题：
a、由于是每隔一段时间启动一次持久化，因此在时间间隔中的数据有可能会丢失；
b、在某个时间间隔中数据量过大的时候可能会影响服务器对外服务的性能
AOF：redis的每一个写命令都会被追加写到文件中，当redis重启时根据文件中的内容将redis的数据从新构建
主要的问题：
a、AOF产生的文件过大，有可能会出现就只是从文件中读取数据恢复redis的工程就会非常长，导致服务重启过程非常耗时

目前redis中的持久化方案：
二者共同使用，使用快照持久化之前的数据，AOF持久化的时两次快照之间的数据

3、redis是否能做为专门的持久化数据库

首先redis是对内存操作，有天生的速度优势，在更多的时候是作为缓存。但是相对于准备的数据库（mysql， mongodb）等是使用磁盘的来说，redis的空间太小了。
原因：
a、内存空间和磁盘空间的问题（大小，成本）
b、不利于扩展，redis是key-value结构，不能像mysql那样可以设置联合主键等（关联查询）
c、没有像mysql那样的事务
d、redis服务如果断电后很有可能会丢失数据（致命）
主要有三点：性能，成本，可靠性

4、redis中的hash的实现方式

redis本身就是key-value，redis中的hash可以理解为value中又是一个key-value
redis中的基础数据结构dict：dict是维护了key和value的映射
dict的本质就是解决算法中的查找问题，两种解决方式：哈希表和平衡树
dict使用的哈希表的算法：采用拉链法解决冲突，并在装载因子（load factor）超过预定值时自动扩展内存，引发重哈希（rehashing）。
redis中的dict的重哈希（增量式重哈希）：在需要扩展内存时避免一次性对所有key进行重哈希，而是将重哈希操作分散到对于dict的各个增删改查的操作中去。每次都只会操作一小部分。