文章目录
一共包括七个内容，
Redis与Memcache对比 + 两种持久化 + 三种失效删除 + 六种淘汰策略 + 线程模型 + 集群 +其他特性
2.1 Redis加快速度的六个设计
关系型数据库跟Redis本质上的区别：
解释上图：
左边为mysql的介绍，mysql中的innodb存储引擎，分为内存部分和硬盘部分两层结构
内存部分存放索引，如a b c，磁盘部分中存放具体的值Apple banana China
右边为redis的介绍，redis只有内存一层结构
为什么没有磁盘？因为Redis是纯粹在内存里的，不涉及磁盘，除非RDB持久化和AOF持久化
所以，从这个图上上面，我们可以知道redis为什么比mysql快的第一个理由，因为redis是完全基于内存的。
金手指：Redis加快速度的六个设计
1、Redis由C语言编写，采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。
2、丰富的数据结构，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
4、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
5、多路I/O复用模型，非阻塞IO：使用多路I/O复用模型，非阻塞IO；
6、Redis自己构建了VM 机制代替系统调用系统函数：使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制代替系统调用系统函数，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
2.2 为什么选择Redis？对比两种缓存：Memcache(简称MC)和redis（技术选型问题）
| Memcache | redis | |
|---|---|---|
| 数据类型（Redis速度快的第二个原因） | 数据结构：只支持 K-V 结构，不提供持久化和主从同步功能。且在k-v结构：key 不能超过 250 个字节；value 不能超过 1M 字节；key 的最大失效时间是 30 天（数据类型是Memcache的最大劣势，是大家选择Redis、MongoDB的重要原因） | 数据类型：相比 MC，Redis 还有一个非常大的优势，就是除了 K-V 之外，还支持多种数据格式，例如 list、set、sorted set、hash 等。 |
| 基于内存（Redis速度快的第三个原因） | 基于内存：MC 功能简单，基于内存存储数据，注意MC的内存结构以及钙化问题； | 基于内存：Redis 支持持久化，所以 Redis 不仅仅可以用作缓存，也可以用作 NoSQL 数据库（解释：redis基于内存可以作为缓存，但是持久化到磁盘就可以成为NoSQL数据库了，然后，RDB作为全量复制的冷备份，slave第一次接入集群的时候master发送，AOF作为热备份，slave每次接收master的同步）。 |
| 多线程or单线程（Redis速度快的第四个原因） | 多线程：MC 处理请求时使用多线程异步 IO 的方式，可以合理利用 CPU 多核的优势，性能非常优秀； | 单线程：Redis 采用单线程模式处理请求。 |
| 缓存失效 | 缓存失效时间：MC 对缓存的数据可以设置失效期，过期后的数据会被清除；失效的策略采用延迟失效，即当再次使用数据时检查是否失效；当容量存满时，会对缓存中的数据进行剔除，剔除时除了会对过期 key 进行清理，还会按 LRU 策略对数据进行剔除。 | key 失效机制：Redis 的 key 可以设置过期时间，过期后 Redis 采用主动和被动结合的失效机制，一个是和 MC 一样在访问时触发被动删除，另一种是定期的主动删除。 |
| 集群（Redsi集群优势） | 无 | 集群：Redis 提供主从同步机制，以及 Cluster 集群部署能力，能够提供高可用服务。 |
Redis相对于Mencached的优点（数据结构优势+集群优势）
第一，数据结构，Redis 支持复杂的数据结构：
Redis 相比 Memcached 来说，拥有更多的数据结构，能支持更丰富的数据操作。如果需要缓存能够支持更复杂的结构和操作， Redis 会是不错的选择。
第二，集群，Redis 原生支持集群模式：
在 redis3.x 版本中，便能支持 Cluster 模式，而 Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。
第三，性能对比：redis单核100k以下数据好，Memcached 多核100k以上数据好：
解释：由于 Redis 只使用单核，而 Memcached 可以使用多核，所以平均每一个核上 Redis 在存储小数据时比 Memcached 性能更高。而在 100k 以上的数据中，Memcached 性能要高于 Redis，虽然 Redis 最近也在存储大数据的性能上进行优化，但是比起 Remcached，还是稍有逊色。
3.1 Redis持久化引入：Redis数据都在内存中，一断电或者重启丢失了嘛？
是的，持久化的话是Redis 高可用 中比较重要的一个环节，因为Redis数据在内存的特性，持久化必须得有，通过持久化，redis这个基于内存的缓存，变成了一个NoSQL非关系型数据库。
3.2 RDB持久化的定义+AOF持久化的定义
RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化， 把整个 Redis 的数据保存在单一文件中。RDB 是把内存中的数据集以快照形式写入磁盘，实际操作是通过 fork 子进程执行，采用二进制压缩存储。
AOF：AOF 是以文本日志的形式记录 Redis 处理的每一个写入或删除操作，AOF 机制对每条写入命令作为日志，对日志文件的写入操作使用的追加模式，以 append-only 的模式写入一个日志文件中。因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。
tip：两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。
附：RDB的原理是什么？
回答：fork和cow。
fork是指redis通过创建子进程来进行RDB操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。
3.3 RDB持久化优缺点+AOF持久化优缺点
3.3.1 RDB持久化优点
第一，RDB持久化生成的每个数据文件中存放的都是完整的Redis中的信息，很适合做冷备
RDB持久化会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据，这种方式，每一个数据文件中存放的都是完整的Redis中的信息，很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。
第二，RDB持久化，在同步数据的时候，对Redis的性能影响非常小，在恢复数据的时候，速度比AOF持久化快
RDB持久化对Redis的性能影响非常小，因为RDB持久化，在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快。
3.3.2 RDB持久化缺点：
第一，RDB持久化数据完整性不如AOF持久化
RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据，数据完整性上高下立判。
第二，RDB持久化，在同步数据的时候，如果文件很大，会使前端客户端停顿几毫秒或几秒
RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，因为这个时候它fork了一个子进程去生成一个大快照，如果你公司在做秒杀的时候， 就出大问题。
3.3.3 AOF持久化优点：
第一，AOF持久化数据完整性更好
相比RDB五分钟一次生成快照，AOF是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。
第二，AOF持久化，同步数据的时候，追加写文件，不用寻址，非常快，一定不会产生停顿
AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。
第三，AOF持久化适合做适合做灾难性数据误删除的紧急恢复
AOF的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了，然后重新导入热备就好了。
3.3.4 AOF持久化缺点：
第一，一个的数据，空间占用大，一样的数据，AOF文件比RDB还要大。
第二，写QPS效率低，AOF开启后，AOF写的QPS会比RDB支持写的要低。如果AOF持久化是每秒都要去异步刷新一次日志fsync，这样性能还是很高，我记得ElasticSearch也是这样的，异步刷新缓存区的数据去持久化，为啥这么做呢，不直接来一条怼一条呢，那我会告诉你这样性能可能低到没办法用的。
3.5 最后，RDB持久化和AOF持久化的应用
两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去（比如用户数据，备份一份到我广州的节点，再备份一个到深圳的节点），RDB更适合做冷备，AOF更适合做热备。
单独用RDB你会丢失很多数据，你单独用AOF，你数据恢复没RDB来的快。
应用：一旦宕机，先用RDB恢复，然后AOF做数据补全，冷备热备一起上，才是互联网时代一个高健壮性系统的王道。
金手指：Redis持久化具体实现：AOF热备增量数据，类似binlog，RDB冷备全量数据
第一，Redis是怎么持久化的？（两种持久化方式以对比方式来说，拉高逼格）服务主从数据怎么交互的？
1、原因：因为RDB会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。
2、起手式：RDB做镜像全量持久化，AOF做增量持久化。
3、具体流程：在redis实例重启或启动时，会使用RDB持久化文件重新构建内存，再redis运行时，使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。
4、具体流程：把RDB理解为一整个表全量的数据，AOF理解为每次操作的日志就好了，服务器重启的时候先把表的数据全部搞进去（即做一次RDB持久化），但是他可能不完整，你再回放一下日志（即做一次AOF持久化），数据就完整了。
5、Redis持久化机制： AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件后，Redis启动成功；AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。
第二，如果持久化的时候，突然机器掉电会怎样？
取决于AOF日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。
3.6 面试金手指（两种持久化优缺点 + 做热备冷备 + 应用）
| RDB持久化 | AOF持久化 | |
|---|---|---|
| 优点 | 1、空间：一样的数据，空间占用小；2、写操作QPS效率高：写操作QPS效率高；3、恢复数据速度快：在恢复数据的时候，速度比AOF持久化快； | 1、AOF持久化数据完整性更好；2、AOF持久化，同步数据的时候，追加写文件，不用寻址，非常快，一定不会产生停顿 |
| 缺点 | 1、持久化的数据完整性：RDB持久化数据完整性不如AOF持久化；2、持久化数据时候的停顿：在同步数据的时候，如果文件很大，会使前端客户端停顿几毫秒或几秒 | 1、一样的数据，空间占用大；2、写操作QPS效率低；3、在恢复数据的时候，速度比RDB持久化慢； |
好记，优缺点相互互补
1、RDB持久化生成的每个数据文件中存放的都是完整的Redis中的信息，全量数据 + 空间占用小 + 写QPS效率高 + 恢复数据快，很适合做冷备；
2、AOF持久化每次只是追加的方式写数据，增量数据 + 数据完整性好 + 同步数据写入快，很适合热备；
金手指：Redis持久化具体实现：AOF热备增量数据，类似binlog，RDB冷备全量数据
第一，Redis是怎么持久化的？（两种持久化方式以对比方式来说，拉高逼格）服务主从数据怎么交互的？
1、原因：因为RDB会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。
2、起手式：RDB做镜像全量持久化，AOF做增量持久化。
3、具体流程：在redis实例重启或启动时，会使用RDB持久化文件重新构建内存，再redis运行时，使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。
4、具体流程：把RDB理解为一整个表全量的数据，AOF理解为每次操作的日志就好了，服务器重启的时候先把表的数据全部搞进去（即做一次RDB持久化），但是他可能不完整，你再回放一下日志（即做一次AOF持久化），数据就完整了。
5、Redis持久化机制： AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件后，Redis启动成功；AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。
第二，如果持久化的时候，突然机器掉电会怎样？
取决于AOF日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。
4.1 生存时间的底层保存（过期字典）
我们知道，redis是基于key-value存储的一个非关系型数据库，对于每一个记录的key，都有一个生存时间TTL，上面介绍了指定key的生存时间的读写，那么，redis中每一个key的生存时间是底层是如何存储的呢？答案是使用“过期字典”存储。
过期字典引入：redisDB结构的expires字典保存了数据库中所有键的过期时间，这个expires字典就是过期字典。
过期字典的键：是一个指针,这个指针指向键空间中的某个键对象(也即是某个数据库键)。
过期字典的值：是一个long long类型的整数 ,这个整数保存了键所指向的数据库键的过期时间，即—个毫秒精度的UNIX时间戳。
展示了一个带有过期字典的数据库例子,在这个例子中,键空间保存了数据库中的所有键值对，而过期时间则保存了数据库中所有按键值对的过期时间。
生存时间（过期时间）的添加和删除略过。
4.2 过期字典如何处理过期key（即过期key的删除）：定时删除 惰性删除 定期删除
一表总结（用表格比对清晰）：
| 删除方式（过期key删除） | 解释名称 | 含义 | 删除类型 | 优点 | 缺点 | 备注 |
|---|---|---|---|---|---|---|
| 定时删除 | 内部含有定时器，故称为定时删除 | 在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作。 | 主动删除 | 对内存友好，过期key尽快被删除，被释放过期key的内存 | 对CPU时间不友好，较快删除key,占用CPU时间 | 该方式redis服务器中需要创建大量定时器，不现实，舍去。 |
| 惰性删除 | 一定要等到使用该键的时候才删除过期key，比较懒惰，故称为惰性删除 | 放任键不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。 | 被动删除 | 对CPU时间友好，过期key尽可能慢地删除，取出时才检查是否过期，尽可能少的占用CPU时间 | 对内存不友好，过期地key删除不及时，一定要等到再次取出时才检查删除，这段时间内占用内存 | 由于存在着很多过期的key没有及时被删除，容易造成内存泄露 |
| 定期删除 | 均衡定时删除和惰性删除，得到一个合适的时间段删除，故称为定期删除 | 每隔一段时间，程序就会对数据库进行一个检查，删除里面的过期键。至于要删除多少个过期键，以及要检查多少个数据库，则由算法决定。 | 主动删除 | 定时删除和惰性删除的综合，合理使用CPU和内存 | 难以确定删除操作执行的时长和频率 | 若删除频繁，则接近定时删除，消耗太多CPU时间；若删除太少，则接近惰性删除，消耗内存。 |
问题1：【过期时间 两种删除】为啥不扫描全部设置了过期时间的key呢？
假如Redis里面所有的key都有过期时间，都扫描一遍？那太恐怖了，而且我们线上基本上也都是会设置一定的过期时间的。全扫描跟你去查数据库不带where条件不走索引全表扫描一样，100ms一次，Redis累都累死了。
问题2：【过期时间 两种删除】如果一直没随机到很多key，里面不就存在大量的无效key了，如何处理？
回答2：惰性删除，不主动删，我等你来查询了我看看你过期没，过期就删去redis中这个key，没过期该怎么样就怎么样。
问题3：【定期删除没有删，内存满了，就要走淘汰算法】最后就是如果的如果，定期没删，我也没查询，那可咋整？
内存淘汰机制！
官网上给到的内存淘汰机制是以下几个：
noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）
allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。
volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。
allkeys-random: 回收随机的键使得新添加的数据有空间存放。、
volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。
volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。
小结：如果没有键满足回收的前提条件的话，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。
6.1 文件事件处理器
Redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。文件事件处理器 file event handler ，采用 IO 多路复用机制同时监听多个 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。
文件事件处理器的结构包含 4 个部分：
多个 Socket
IO 多路复用程序
文件事件分派器
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）
多个 Socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 Socket，会将 Socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。如下图：
解释上图：文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答(accept)、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。
1）关于套接字队列：尽管多个文件事件可能会并发地出现,但I/O多路复用程序总是会将所有产生事件的套接字都放到一个队列里面,然后通过这个队列,以有序(sequentially),同步(synchronously)、每次一个套接字的方式向文件事件分派器传送套接字。当上一个套接字产生的事件被处理完毕之后(该套接字为事件所关联的事件处理器执行完毕),I/O多路复用程序才会继续向文件事件分派器传送下一个套接字。
2）关于I/O多路复用程序：I/O多路复用程序负责监听多个套接字，并向文件事件分派器传送那些产生了事件的套接字。
3）关于文件事件分派器：文件事件分派器接收I/O多路复用程序传来的套接字,并根据套接字产生的事件的类型,调用相应的事件处理器。
4）关于事件处理器：服务器会为执行不同任务的套接字关联不同的事件处理器,这些处理器是一个个函数,它们定义了某个事件发生时,服务器应该执行的动作。
问题1：【单线程】为什么redis是单线程的？考点：redis底层原理
底层原因：Redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。
业务原因一：redis采用了非阻塞的异步事件处理机制，没有必要用多线程
业务原因二：一般缓存数据都是内存操作 IO 时间不会太长，单线程可以避免线程上下文切换产生的代价。
业务原因三：redis确实是单线程，但是可以搭建多个redis实例构成redis集群。
问题2：【单线程】Redis使用单线程，我们现在服务器都是多核的，那不是很浪费？
是的他是单线程的，但是，我们可以通过在单机开多个Redis实例嘛。
问题3：【文件事件处理器】redis单线程如何处理多个事件？
第一，redis单线程，但是可以部署多个redis实例，实现redis集群。
第二，对于单个redis，它采用 IO 多路复用机制同时监听多个 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。
6.2 Redis使用单线程，避免了上下文切换，什么是上下文切换？为什么上下文切换不安全？
好比你看一本英文书，你看到第十页发现有个单词不会读，你加了个书签，然后去查字典，过了一会你又回来继续从书签那里读，ok到目前为止没啥问题。
如果是你一个人读肯定没啥问题，但是你去查的时候，别的小伙伴好奇你在看啥他就翻了一下你的书，然后溜了，哦豁，你再看的时候就发现书不是你看的那一页了。不知道到这里为止我有没有解释清楚，以及为啥会线程不安全，就是因为你一个人怎么看都没事，但是人多了换来换去的操作一本书数据就乱了。可能我的解释很粗糙，但是道理应该是一样的。
七、redis集群（Sentinel哨兵 + 主从同步 + master选举）7.1 Redis集群引入：单机Redis会有瓶颈，那你们是怎么解决这个瓶颈的？
起手式：永远的永远，处理单机的性能瓶颈就是分布式集群架构，Redis也是这样。
在Redis中，使用的集群的部署方式也就是Redis cluster，并且是主从同步读写分离，类似Mysql的主从同步，Redis cluster 支撑 N 个 Redis master node，每个master node都可以挂载多个 slave node。
这样整个 Redis 就可以横向扩容了。如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master 节点就能存放更多的数据了。
Redis的同步机制了解么？
Redis可以使用主从同步，从从同步。
第一，第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将RDB文件全量同步到复制节点，复制节点接受完成后将RDB镜像加载到内存。
第二，加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
第三，后续的增量数据通过AOF日志同步即可，有点类似数据库的binlog。
集群的高可用怎么保证，集群的高并发如何保证？
第一，Redis Sentinal 着眼于高可用，支持主从同步，通过 Sentinal 哨兵来监控 Redis 主服务器的状态，在master宕机时会自动将slave提升为master，继续提供服务。
1.1 在 Redis 集群中，sentinel 也会进行多个redis实例部署，sentinel 之间通过 Raft 协议来保证自身的高可用。
第二，Redis Cluster 着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。
2.1 Redis Cluster 的分片机制，在内部分为 16384 个 slot 插槽，这 16384 个slot 插槽，分布在所有 master 节点上，每个 master 节点负责一部分 slot。数据读写的时候，按 key 做 CRC16 来计算在哪个 slot，由哪个 master 进行处理。数据的冗余是通过 slave 节点来保障。
2.2 注意：分布式集群是解决高并发的手段，这是一条通用准则，后端微服务架构、redis集群、mysql集群都是这样
7.2 Redis集群选主
问题1：什么情况下要选主？
回答1：当主节点挂掉之后要选主。
当主挂掉时，在从节点中根据一定策略选出新主，并调整其他从 slaveof 到新主。
问题2：如何选主，到底选哪个slave从节点作为master主节点？
回答2：Redis选主的策略简单来说有三个：
（1）相同条件下，slave 的 priority 设置的越低，优先级越高；
（2）相同条件下，slave 复制的数据越多，优先级越高；
（3）相同条件下，slave 的 runid 越小，优先级越高；
7.3 哨兵集群Sentinel
解释“哨兵集群Sentinel”
哨兵是一个一个的，通过哨兵来完成四个功能：集群监控（master宕机了就要选主）、消息通知、故障转移、配置中心；
囊括所有哨兵的集群就是Sentinel。
哨兵必须用三个实例去保证自己的健壮性的，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。
为什么必须要三个实例呢？我们先看看两个哨兵会咋样。
master宕机了 s1和s2两个哨兵只要有一个认为你宕机了就切换了，并且会选举出一个哨兵去执行故障，但是这个时候也需要大多数哨兵都是运行的。
那这样有啥问题呢？M1宕机了，S1没挂那其实是OK的，但是整个机器都挂了呢？哨兵就只剩下S2个裸屌了，没有哨兵去允许故障转移了，虽然另外一个机器上还有R1，但是故障转移就是不执行。
经典的哨兵集群是这样的：
M1所在的机器挂了，哨兵还有两个，两个人一看他不是挂了嘛，那我们就选举一个出来执行故障转移不就好了。
哨兵组件的四个功能：
集群监控：负责监控 Redis master 和 slave 进程是否正常工作。
消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
7.4 redis主从复制
提到这个，就跟我前面提到的数据持久化的RDB和AOF有着比密切的关系了。
八、Redis其他特性问题1：为什么需要Redis集群主从架构、读写分离？
因为单机QPS是有上限的，而且Redis的特性就是必须支撑读高并发的，那你一台机器又读又写，无法承受住，但是你让这个master机器去写，数据同步给别的slave机器，他们都拿去读，分发掉大量的请求那是不是好很多，而且扩容的时候还可以轻松实现水平扩容。
问题2：主从复制怎样进行（先全量再增量）
回答2：你启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。
回答2（另外一种）：redis主从同步的时候，新的slaver进来的时候用RDB冷备份做全量复制，之后，有新的数据进入master同步到slaver，使用AOF热备份做增量复制，这个AOF持久化增量复制就像MySQL的Binlog一样，把日志增量同步给从服务就好了。
问题3：数据传输的时候断网了或者服务器挂了怎么办啊？
回答3：传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的。
大家需要记得的就是，RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，你在同步期间的增量数据咋办？是吧？
8.1 keys scan 匹配指令
俄罗斯套娃式问题： keys scan 匹配指令
第一，假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？
使用keys指令可以扫出指定模式的key列表。
第二，如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
Redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到keys指令执行完毕，服务才能恢复。因为使用keys指令会阻塞服务，所以这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。
不过，scan这种增量式迭代命令也不是没有缺点的：举个例子， 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素， 但是对于 SCAN 这类增量式迭代命令来说， 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。
8.2 Redis做异步队列
俄罗斯套娃式问题：Redis做异步队列
第一，Redis做异步队列怎么用的？
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
第二，可不可以不用sleep呢？
list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。
第三，能不能生产一次消费多次呢？
使用pub/sub主题订阅者模式，可以实现 1:N 的消息队列。
第四，如果对方继续追问 pub/su b有什么缺点？
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如RocketMQ等。
第五，Redis如何实现延时队列？
使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。
8.3 Stream：支持多播的可持久化消息队列 Stream
8.4 Module：通过 Module 系统来进行定制功能扩展
九、小结Redis与Memcache对比 + 两种持久化 + 三种失效删除 + 六种淘汰策略 + 线程模型 + 集群 +其他特性，完成了。
天天打码，天天进步！
