1.Redis有哪些用途
2.Redis几种模式
Redis有四种常见的运行模式，分别为：
单机模式
主从模式
哨兵模式
集群模式1.单机模式
单机模式是指在单台服务器中运行的Redis程序，是最原始最基本的模式。单机模式的优势在于部署简单只要安装好Redis，并进行简单配置即可，因为没有其他Redis节点，因此费用低廉。单机模式的缺点在于可靠性差，如果Redis宕机，那么服务也就会直接失效。同时因为Redis是单线程的，所以在单机上运行时受CPU的影响很大。单机模式通常适合于在不需要很高的性能以及可靠性的小型业务场景。
2.主从模式
主从模式是指将一个Redis节点设置为主节点，其他Redis节点设置为从节点，通过将主节点的数据复制到其他的Redis服务器中（单向），此时请求会按规则访问所有的Redis节点，因此主节点的访问压力也就被从节点所分担了。并且当主节点宕机时，会将一个从节点提升为主节点，因此系统的可靠性也有所提高。同Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。主从模式扩展了主节点的读能力，但存储和写都受主节点的性能限制，并且该模式下数据存在大量冗余情况。优点：1、解决数据备份问题2、做到读写分离，提高服务器性能缺点：1、每个客户端连接redis实例的时候都是指定了ip和端口号的，如果所连接的redis实例因为故障下线了，而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接2、主从模式下，如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作3、无法实现动态扩容
3.哨兵模式
哨兵模式是在主从模式的基础上，增加了哨兵节点这一个概念。在哨兵模式中，节点分为哨兵节点和数据节点两种：哨兵节点可以是一个或多个，每个节点都是一种特殊的Redis节点，该节点并不存储数据。数据节点则由主节点和从节点组成，和之前的主从节点类似。其中由哨兵节点负责监视数据节点，其原理是通过Ping方式判断数据节点是否存活，如果Ping超时，则将该节点标记为主观下线状态，当有指定数量以上的哨兵节点也发现该数据节点处于主观下线状态，就将其标记为客观下线状态。
哨兵模式的优点是：
具备所有主从模式的优点（是主从模式的升级）
主从节点可以自动切换，增强了系统的可用性缺点是哨兵节点也有几率会发生宕机，从而引起集群的故障Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
3.集群模式
集群模式是通过数据分片的方式来将数据分配到不同的分片上，因此其数据冗余较小，其故障转移也和哨兵模式类似。在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。一般集群建议搭建三主三从架构，三主提供服务，三从提供备份功能。每一个节点都存有这个集群所有主节点以及从节点的信息。它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入fail状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入fail状态。这就是我们的redis的投票机制，具体原理如下图所示：
(1)投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉.(2):什么时候整个集群不可用(cluster_state:fail)?
a:如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
b:如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.3.Redis为什么快
(1)基于内存实现
Redis 是基于内存的数据库，那不可避免的就要与磁盘数据库做对比。对于磁盘数据库来说，是需要将数据读取到内存里的，这个过程会受到磁盘 I/O 的限制。而对于内存数据库来说，本身数据就存在于内存里，也就没有了这方面的开销。
(2)高效的数据结构
Redis 中有多种数据类型，每种数据类型的底层都由一种或多种数据结构来支持。正是因为有了这些数据结构，Redis 在存储与读取上的速度才不受阻碍。这些数据结构有什么特别的地方，各位看官接着往下看：
链表里每个节点都带有两个指针，prev 指向前节点，next 指向后节点。这样在时间复杂度为 O(1) 内就能获取到前后节点。
（2）头尾节点
你可能注意到了，头节点里有 head 和 tail 两个参数，分别指向头节点和尾节点。这样的设计能够对双端节点的处理时间复杂度降至 O(1) ，对于队列和栈来说再适合不过。同时链表迭代时从两端都可以进行。
它是经过特殊编码，专门为了提升内存使用效率设计的。所有的操作都是通过指针与解码出来的偏移量进行的。并且压缩列表的内存是连续分配的，遍历的速度很快。
4、字典
Redis 作为 K-V 型数据库，所有的键值都是用字典来存储的。日常学习中使用的字典你应该不会陌生，想查找某个词通过某个字就可以直接定位到，速度非常快。这里所说的字典原理上是一样的，通过某个 key 可以直接获取到对应的value。字典又称为哈希表，这点没什么可说的。哈希表的特性大家都很清楚，能够在 O(1) 时间复杂度内取出和插入关联的值。
5、跳跃表
作为 Redis 中特有的数据结构-跳跃表，其在链表的基础上增加了多级索引来提升查找效率。
这是跳跃表的简单原理图，每一层都有一条有序的链表，最底层的链表包含了所有的元素。这样跳跃表就可以支持在 O(logN) 的时间复杂度里查找到对应的节点。下面这张是跳表真实的存储结构，和其它数据结构一样，都在头节点里记录了相应的信息，减少了一些不必要的系统开销。
合适的线程模型
Redis 快的原因还有一个是因为使用了合适的线程模型：
应对大量的请求，Redis 中使用 I/O 多路复用程序同时监听多个套接字，并将这些事件推送到一个队列里，然后逐个被执行。最终将结果返回给客户端。
2、避免上下文切换
你一定听说过，Redis 是单线程的。那么单线程的 Redis 为什么会快呢？因为多线程在执行过程中需要进行 CPU 的上下文切换，这个操作比较耗时。Redis 又是基于内存实现的，对于内存来说，没有上下文切换效率就是最高的。多次读写都在一个CPU 上，对于内存来说就是最佳方案。
3、单线程模型
顺便提一下，为什么 Redis 是单线程的.Redis 中使用了 Reactor 单线程模型，你可能对它并不熟悉。没关系，只需要大概了解一下即可。
这张图里，接收到用户的请求后，全部推送到一个队列里，然后交给文件事件分派器，而它是单线程的工作方式。Redis 又是基于它工作的，所以说 Redis 是单线程的。
总结
基于内存实现
数据都存储在内存里，减少了一些不必要的 I/O 操作，操作速率很快。
高效的数据结构
底层多种数据结构支持不同的数据类型，支持 Redis 存储不同的数据；
不同数据结构的设计，使得数据存储时间复杂度降到最低。
合理的数据编码
根据字符串的长度及元素的个数适配不同的编码格式。
合适的线程模型
I/O 多路复用模型同时监听客户端连接；
单线程在执行过程中不需要进行上下文切换，减少了耗时。
4.Redis的操作熟悉吗？
5.Redis有哪些数据类型
二、五大数据类型
1、String
String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。常规key-value缓存应用： 常规计数：微博数，粉丝数等
2、List列表
1、它是一个字符串链表，left，right 都可以插入添加
2、如果键不存在，创建新的链表 如果键已存在，新增内容
3、如果值全移除，对应的键也就消失了
4、链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。
list就是链表使用Lists结构，我们可以轻松地实现最新消息排队等功能。List的另一个应用就是消息队列，可以利用List的PUSH操作，将任务存在List中，然后工 作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段的api，你可以直接查询，删 除List中某一段的元素。 Redis的list是每个子元素都是String类型的双向链表，可以通过push和pop操作从列表的头部或者尾部 添加或者删除元素，这样List即可以作为栈，也可以作为队.3、Set不能重复的，是string类型的无序集合
4、Hash hash是一个键值对集合，是一个string类型的field和value的映射表，hash适合存储对象。类似于java中的Map<String,Object>
5、Zset有序集合
和普通集合类似，并发zset的每个成员都关联了一个score，这个score被用来从低到高排序成员。
三、三种特殊数据类型
1、geospatial地理位置
2、hyperloglog
一般来说，pv或者uv的统计，可以自己来做，也可以借助一些第三方的工具，比如cnzz，友盟等。如果自己实现，pv比较简单，可以直接通过Redis计数器就能实现。但是uv就不一样，uv设计到另外一个问题，去重。我们首先需要在前端给每一个用户生成一个唯一Id，无论是登录用户还是未登录用户，都要有一个唯一id，这个id伴随着请求一起到达后端，在后端我们通过set集合中sadd命令来存储这个id，最后通过scard统计集合大小，进而得到uv数据。如果是千万级别的uv，需要的存储空间就非常惊人。而且，像uv统计这种，一般也不需要特别精确，800w的uv和803w的uv，其实差别不大。而HyperLogLog可以很好的满足这个要求。Redis中提供的HperLogLog就是专门用来解决这个问题的，HyperLogLog提供了一套不怎么精确但是够用的去重方案，会有误差，官方给出的误差数据是0.81%，这个精确度，统计UV够用了。
3、bitmaps
6.为什么要使用redis
7.主从复制原理
一、什么是Redis主从复制1、主从复制的架构：Redis Replication是一种 master-slave 模式的复制机制，这种机制使得 slave 节点可以成为与 master 节点完全相同的副本，可以采用一主多从或者级联结构。架构如下：
主从复制的配置要点：
（1）配从库不配主，从库配置：slaveof 主库IP 主库端口
（2）查看redis的配置信息：info replication2、Redis为什么需要主从复制？使用Redis主从复制的原因主要是单台Redis节点存在以下的局限性：
（1）Redis虽然读写的速度都很快，单节点的Redis能够支撑QPS大概在5w左右，如果上千万的用户访问，Redis就承载不了，成为了高并发的瓶颈。
（2）单节点的Redis不能保证高可用，当Redis因为某些原因意外宕机时，会导致缓存不可用
（3）CPU的利用率上，单台Redis实例只能利用单个核心，这单个核心在面临海量数据的存取和管理工作时压力会非常大。3、主从复制的好处：（1）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。（2）故障恢复：如果master宕掉了，使用哨兵模式，可以提升一个 slave 作为新的 master，进而实现故障转移，实现高可用（3）负载均衡：可以轻易地实现横向扩展，实现读写分离，一个 master 用于写，多个 slave 用于分摊读的压力，从而实现高并发；4、主从复制的缺点：由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重
二、主从复制的原理从总体上来说，Redis主从复制的策略就是：当主从服务器刚建立连接的时候，进行全量同步；全量复制结束后，进行增量复制。当然，如果有需要，slave 在任何时候都可以发起全量同步。1、主从全量复制的流程：Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份，具体步骤如下：（1）slave服务器连接到master服务器，便开始进行数据同步，发送psync命令（Redis2.8之前是sync命令）（2）master服务器收到psync命令之后，开始执行bgsave命令生成RDB快照文件并使用缓存区记录此后执行的所有写命令
如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是每个连接都执行一次，然后再把这一份持久化的数据发送给多个并发连接的slave。
如果RDB复制时间超过60秒（repl-timeout），那么slave服务器就会认为复制失败，可以适当调节大这个参数（3）master服务器bgsave执行完之后，就会向所有Slava服务器发送快照文件，并在发送期间继续在缓冲区内记录被执行的写命令
client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败（4）slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据，在从本地磁盘载入收到的快照到内存中，同时基于旧的数据版本对外提供服务。（5）master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令（6）slave服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
2、增量复制：
Redis的增量复制是指在初始化的全量复制并开始正常工作之后，master服务器将发生的写操作同步到slave服务器的过程，增量复制的过程主要是master服务器每执行一个写命令就会向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令。
三、主从复制的其他问题1、主从复制的特点：（1）Redis使用异步复制，每次接收到写命令之后，先在内部写入数据，然后异步发送给slave服务器。但从Redis 2.8开始，从服务器会周期性的应答从复制流中处理的数据量。（2）Redis主从复制不阻塞master服务器。也就是说当若干个从服务器在进行初始同步时，主服务器仍然可以处理外界请求。（3）主从复制不阻塞slave服务器。当master服务器进行初始同步时，slave服务器返回的是以前旧版本的数据，如果你不想这样，那么在启动redis配置文件中进行设置，那么从redis在同步过程中来自外界的查询请求都会返回错误给客户端；
虽然说主从复制过程中对于从redis是非阻塞的，它会用旧的数据集来提供服务，但是当初始同步完成后，需删除旧数据集和加载新的数据集，在这个短暂时间内，从服务器会阻塞连接进来的请求，对于大数据集，加载到内存的时间也是比较多的（4）主从复制提高了redis服务的扩展性，避免单个redis服务器的读写访问压力过大的问题，同时也可以给为数据备份及冗余提供一种解决方案；（5）使用主从复制可以为master服务器免除把数据写入磁盘的消耗，可以配置让master服务器不再将数据持久化到磁盘，而是通过连接让一个配置的slave类型的Redis服务器及时将相关数据持久化到磁盘。不过这种做法存在master类型的Redis服务器一旦重启，因为此时master服务器不进行持久化，所以数据为空，这时候通过主从同步可能导致slave类型的Redis服务器上的数据也被清空，所以这个配置要确保主服务器不会自动重启（详见第2点的“master开启持久化对主从架构的安全意义”）2、master开启持久化对主从架构的安全意义：使用主从架构，必须开启master服务器的持久化机制，不建议用slave服务器作为master服务器的数据热备。当不能这么做时，比如考虑到延迟的问题，应该将master服务器配置为避免自动重启。否则，在关闭master服务器持久化机制并开始自动重启的情况下，会造成主从服务器数据被清空的情况。也就是master的持久化关闭，可能在master宕机重启的时候数据是空的（RDB和AOF都关闭了），此时就会将空数据复制到slave ，导致slave服务器的数据也丢了。
为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了：
设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。3、过期key的处理：对于slave服务器上过期键的处理，主要是有master服务器负责。如果master过期了一个key，则由master服务器负责键的过期删除处理，然后将相关删除命令以数据同步的方式同步给slave服务器，slave服务器根据删除命令删除本地的key。
四、Redis的高可用:前面说过，通过主从复制，如果master服务器宕机了，可以提升一个slave服务器作为新的master服务器，实现故障的转移，实现高可用。也就是说，当master宕掉之后，可以手动执行“SLAVEOF no one”命令，重新选择一台服务器作为master服务器。但是呢，我们总不能保证每次master宕掉之后，都可以及时察觉并手动执行该命令，这时就可以使用“哨兵模式sentinel”，哨兵模式其实就是“SLAVEOF no one”命令的自动版，能够后台监控master是否故障，如果故障了，则根据投票数自动将slave转换为master，如果之前的master重启回来，不会造成双master冲突，因为原本的master会变成slave。
8.全量和增量对应哪两个文件,有哪两种持久化方式。以及对应哪两个文件
1.RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB**的缺点是最后一次持久化后的数据可能丢失**。
在redis.conf中配置文件名称，默认为dump.rdb
优势
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快
劣势
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
2.AOF：以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内；（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
AOF和RDB同时开启，redis**听谁的？AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）
优势
备份机制更稳健，丢失数据概率更低。可读的日志文本，通过操作AOF稳健，可以处理误操作。
劣势
比起RDB占用更多的磁盘空间。恢复备份速度要慢。每次读写都同步的话，有一定的性能压力。存在个别Bug，造成恢复不能。
用哪个好？
官方推荐两个都启用。如果对数据不敏感，可以选单独用RDB。不建议单独用 AOF，因为可能会出现Bug。如果只是做纯内存缓存，可以都不用。
官网建议
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾. Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.同时开启两种持久化方式： 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？ 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。性能建议：因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
9.线程切换损耗的是什么资源: cpu
10.redis集群了解吗？key是如何分发到不同redis中的？
什么是 Redis 集群?Redis 集群是 Redis 提供的分布式数据库方案，集群通过分片( sharding )来实现数据共享，并提供复制和故障转移。可以说上面这句话是对 redis 集群的高度概括了，redis 集群提供分布式数据库方案，前面我们将的主从复制和哨兵模式可以知道，只会有一个主服务器( master )。主从复制，只会有一个 master ，可以有多个 slave。而哨兵模式是在主从复制的基础上，发现 master 挂掉，会自动的将其中一个 salve 升级成 master 。但是最终结果还是只有一个 master。所以如果系统很大，对Redis 写操作的压力就会很大，所以才出现的集群的模式。集群模式可以有多个 master 。来看下面集群模式的图(下面的图不是最终版，便于理解的。后文有最终版的)：
单个节点就是我们之前了解的主从复制的一主多从(图中是一主两从)，加上哨兵模式，来监听节点的 master 是否正常。那集群就是多个节点组成的，多个节点的 master 数据共享，横向分担单个节点 master 的压力。那从上图可以看出 哨兵模式 其实是 集群模式的一个子集，集群模式是哨兵模式的一个拓展。
Redis 集群有什么好处，用在哪些场景上面讲了什么是 Reids 集群，那为什么要使用 Redis 集群呢，不直接使用哨兵模式呢？使用 Redis 集群有什么好处呢？要回答上面这个问题，其实在上一节已经差不多介绍了，集群模式是哨兵模式的一种拓展，既然是拓展，当时是因为哨兵模式不能满足需求才会产生的。在没有Redis 集群的时候，人们使用哨兵模式，所有的数据都存在 master 上面，master 的压力越来越大，垂直扩容再多的 salve 已经不能分担 master 的压力的，因为所有的写操作集中都集中在 master 上。所以人们就想到了水平扩容，就是搭建多个 master 节点。客户端进行分片，手动的控制访问其中某个节点。但是这几个节点之间的数据是不共享的。并且如果增加一个节点，需要手动的将数据进行迁移，维护起来很麻烦。所以才产生了 Redis 集群。所以 Redis 集群有什么好处，就是进一步提升 Redis 性能，分布式部署实现高可用性，更加的稳定。当然还包含主从复制的数据热备份以及哨兵模式的故障转移等有点啦。那 Redis 集群用在哪些场景呢？其实我感觉一般较大的项目使用了 redis 的话，都会使用 redis 集群。毕竟在部署的时候先做好充分的拓展准备，比到时候项目出现瓶颈再去拓展成本就要小太多了。并且 Redis 是轻量级的，采用 redis 集群，也许在项目初期根本就用不上多个节点，单个节点就够用，多节点造成浪费。但是其实我们启动多个节点没有用到的话，节点所占用的内存和CPU 是非常小的。所以建议一般项目使用 Redis的话，尽量使用 Redis 集群吧。
集群的主从复制和故障转移Redis 集群的主从复制，其实和单机的主从复制是一样的。前面 Redis 集群结构图可以看到。单个节点中有一个 master 和多个 slave 。这些 slave 会自动的同步 master中的数据。注意的是，这些 salve 只会同步 所属的 master 中的数据，集群中其他的 master 数据是不会同步的。同样的 ，当个节点中可以配置多个哨兵，来监控这个节点中的master 是否下线了，如果下线了就会将这个节点的slave 选择一个升级成 master 并继承之前 master 的分片，继续工作。但是其实啊，在集群模式中，并没有配置哨兵，我们也能实现故障的自动转移。其实真正的集群的图是这样的：
如图可以看到并没有为每个节点配置 sentinel 。那怎么实现对 master 的监听，实现故障的自动转移呢？我们在讲哨兵模式的时候说过，其实哨兵也是一种特殊的 redis 服务对吧。我们master 是通过 redis-serverredis-sentinel启动的。然后哨兵的作用就是定期的给 master 发送 ping检测 master 是否下线，然后通过选举的方式选择 slave 升级成 master 那放在集群中可以发现，哨兵的这些工作，完全可以交给master 来做。之前单个节点，master 做不了才交给 sentinel 的。现在有多个 master ，当然就可以用 master 来代替salve 的工作啦 在集群中，每个节点的master 定期的向其他节点 master 发送 ping命令，如果没有收到pong 响应，则会认为主观下线，并将这个消息发送给其他的 master。其他的 master 在接收到这个消息后就保存起来。当某个节点的 master 收到 半数以上的消息认为这个节点主观下线后，就会判定这个节点客观下线。并将这个节点客观下线的消息通知给其他的master。 这个客观节点下线后，其他的 master 节点 就会选举 下线的master中的 slave 一个变成 新的master 继续工作。从而实现故障自动转移。这个选举过程和哨兵模式中是一样的，只不过是 master 代替了 sentinel 的工作。
13.为什么要用redis作为缓存，其他的用过吗⭐(项目中的)
14.信号量为什么要用redis，用mysql不行吗？redis为什么更快？(项目中的)
15.redis压测时有没有保证redis压到瓶颈？(项目中的)
16.整个系统的性能瓶颈在哪（redis）(项目中的)
