为什么要使用Redis？
Redis是目前开发中非常好用的中间件，他有丰富的缓存结构，具有高性能、高可用、高扩展的特性；
Redis这么好用，有哪几种数据类型，他们的数据结构分别是什么？
string：简单动态字符串；【满足大部分需求】；
hash：压缩列表+哈希表
set：哈希表+整数数组
list：压缩数组+双向链表
sortedSet：压缩列表+跳表
压缩列表：
是一种内存用到极致的数据结构，高效利用内存，利用CPU缓存机制。
跳表
其实就是链表的形式存储数据，然后会从每个节点，抽取一部分节点作为索引。
查询的时候，经过一层层索引的方式，最终找到想要的数据，他的时间复制度是O（logn）。
Redis吞吐量这么高，说说他的线程模型？
Redis实现的线程模型主要是IO多路复用技术。他是通过单线程的方式，维护每个客户端的连接和获取事件，当客户端发送事件的时候，该线程就会将对应的事件发送到事件处理器中（事件队列），然后通过处理事件后，通过回调的方式，返回给对应的处理事件的结果。
这种方式的好处是避免了线程切换带来的开销，也避免了数据竞争的情况。
Redis的持久化是怎么回事，你能说说吗?
Redis的持久化，就是为了容灾，避免因为重启以后，数据会大面积的丢失。Redis提供给了我们两套持久化的机制。AOF和RDB。如果系统中同时有AOF日志和RDB日志，会优先用AOF日志进行恢复。
AOF
AOF（append only file）。是一种增量的持久化方式，会记录Redis对数据的操作指令，因此数据量会比较全，适合作为热备份的数据。一般会有三种方式:
1.每次操作都记录日志；
2.将每s生成的操作记录都记录；
3.让操作系统去决定啥时候记录日志；
AOF的限制和解决方式
我们知道AOF是不断的写文件的，那么就会有问题，文件不可能无限膨胀。因此，需要出一套机制，去将我们的日志进行缩身。这就是AOF的重写机制。
控制AOF重写的参数：
auto-aof-rewrite-percentage 100 #AOF文件大小较上次重写超过100%时进行重写
auto-aof-rewrite-min-size 64mb #aof文件大小超过64m时重写
AOF的重写机制记住一句话“一份拷贝，两处日志”：
1.首先会从主线程fork一个子线程，复制一份当前内存中的值；
2.两处日志指的是：会继续往AOF日志文件写日志，同时也会往AOF重写日志中写日志；
3.最后生成对应的日志文件会去代替旧的日志文件。
RDB
RDB其实内存快照，Redis也提供给我们参数去调整，什么时候生成一份当前的内存快照。这种方式适合作为冷备份。他的工作原理是：
1.使用bgsave指令fork一个子进程，然后获取当前的全量数据；
2.生成一份二进制文件；
RDB VS AOF
1.AOF的数据全，但是由于保存的是指令，恢复起来比较慢；
2.RDB因为是快照，因此如果宕机了，数据的完整度没有AOF高；
3.一般是AOF+RDB的方式。比如说T1时刻，RDB生成了快照，那么再T2的时刻这段时间对key值得修改，则用AOF记录。到了T2时刻RDB生成快照的时刻，则清除AOF日志（因为这个时候RDB已经是最新的数据了）
说说你们公司用的Redis是什么架构
Redis的架构主要有以下几种：
1.单机：单点故障，风险极大，挂了就没了；
2.主从架构：主从架构可以读写分离，不断的增加从库，从而提供吞吐量。但是master如果挂了，那就没办法对外提供写服务了。
3.哨兵模式：哨兵模式，其实就是另外一个进程复制监控主从架构，如果主库的master挂了，那就从slave中选出新的master，然后继续对外提供服务。但是哨兵也有一个缺点，就是写的话只有一个master写，会出现写瓶颈。
4.Redis Cluster模式：集群模式，支持横向扩展，去中心化，每一个实例都是master。每个master都可以进行读写，因此扩展性非常高，可用性非常好。
主从架构
主从架构的工作模式是，先确定主库，从库，从库通过
replicaof xxxxx设置。master 向slave开始的时候传输一份全量的RDB快照文件，后面的话是通过指令的方式同步。
ps
Redis提供了网络连接断开，断点续传的功能。会有一个佳作repl_backlog的日志文件，复制记录传输的进度。如果是网络断开了，那么后续的传输，就会基于master-node和slave-node之间的offerset进行后续的传输。
哨兵机制
哨兵其实就是一个监控Redis主从架构的一个进程。哨兵的互相之间的通信只要是通过pub/sub订阅的机制，大家都订阅再master上的频道__sentinel__:hello。然后互通信息，通过info指令，从master上知道从库的信息。哨兵的主要功能是：监控、选举，通知。
监控
监控的话，是监控主库是是否下线，这个是由多个哨兵投票去决定的。哨兵首先会觉得主库主观下线，如果通过N/2+1投票决定都认为这个主库主观下线，那么该主库就会客观下线，从而进行下一步的选举工作；
选举
选举工作主要是重新选举一个新的主库。这个时候主要是涉及两方面，一个是哪个哨兵来执行切换，一个是确定新的主库。
如何确定新的主库？
1.剔除网络不好的；
2.优先级高的，先作为主库【可能不同从库间的内存配置是不一样的，可以为不同从库设置优先级】
3.数据同步最大的。通过比较每种从库中的slave_repl_offset。
4.如果前两项都相同，那么就取从库中runId最小的。
如何确定哪个哨兵去执行主从切换？
首先哨兵集群会通过quorum的参数大小，比如说有5台机器，然后quorum的大小为3。如果为3的话，那么该主库就会被客观下线。
然后选举哨兵复制主从切换，这个时候如果有
1.>=quorum值，
2.并且获得半数以上的赞成票。
才可以确定哪个哨兵进行主从切换。
通知
选出新主库后，通知客户端和从库。
Redis Cluster
RedisCluster的出现是为了解决master无法支撑高并发的写。因为上述的两种架构始终存在一个问题就是只有一个主库，后续如果体量上去了，那么还是无法存储大量的数据，因此Redis 的集群模式是靠谱的。
redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。
并且，对于每一个实例，都可以建立对应的slave，已达到高可用的目的（和哨兵差不多）。
