最完整的关于redis缓存面试相关的内容(一)

用缓存，主要是俩用途，高性能和高并发

1）高性能

假设这么个场景，你有个操做，一个请求过来，吭哧吭哧你各类乱七八糟操做mysql，半天查出来一个结果，耗时600ms。可是这个结果可能接下来几个小时都不会变了，或者变了也能够不用当即反馈给用户。那么此时咋办？

缓存啊，折腾600ms查出来的结果，扔缓存里，一个key对应一个value，下次再有人查，别走mysql折腾600ms了。直接从缓存里，经过一个key查出来一个value，2ms搞定。性能提高300倍。

2）高并发

mysql这么重的数据库，压根儿设计不是让你玩儿高并发的，虽然也能够玩儿，可是自然支持很差。mysql单机支撑到2000qps也开始容易报警了。

因此要是你有个系统，高峰期一秒钟过来的请求有1万，那一个mysql单机绝对会死掉。你这个时候就只能上缓存，把不少数据放缓存，别放mysql。缓存功能简单，说白了就是key-value式操做，单机支撑的并发量轻松一秒几万十几万，支撑高并发so easy。单机承载并发量是mysql单机的几十倍。

redis和memcached有啥区别

这个事儿吧，你能够比较出N多个区别来，可是我仍是采起redis做者给出的几个比较吧

1）Redis支持服务器端的数据操做：Redis相比Memcached来讲，拥有更多的数据结构和并支持更丰富的数据操做，一般在Memcached里，你须要将数据拿到客户端来进行相似的修改再set回去。这大大增长了网络IO的次数和数据体积。在Redis中，这些复杂的操做一般和通常的GET/SET同样高效。因此，若是须要缓存可以支持更复杂的结构和操做，那么Redis会是不错的选择。

2）集群模式：memcached没有原生的集群模式，须要依靠客户端来实现往集群中分片写入数据；可是redis目前是原生支持cluster模式的，redis官方就是支持redis cluster集群模式的，比memcached来讲要更好

为啥redis单线程模型也能效率这么高？

1）纯内存操做 2）核心是基于非阻塞的IO多路复用机制 3）单线程反而避免了多线程的频繁上下文切换问题

redis数据类型

（1）string

这是最基本的类型了，没啥可说的，就是普通的set和get，作简单的kv缓存

（2）hash

这个是相似map的一种结构，这个通常就是能够将结构化的数据，好比一个对象（前提是这个对象没嵌套其余的对象）给缓存在redis里，而后每次读写缓存的时候，能够就操做hash里的某个字段。

key=150

value={ “id”: 150, “name”: “zhangsan”, “age”: 20 }

hash类的数据结构，主要是用来存放一些对象，把一些简单的对象给缓存起来，后续操做的时候，你能够直接仅仅修改这个对象中的某个字段的值

value={ “id”: 150, “name”: “zhangsan”, “age”: 21 }

（3）list

有序列表，这个是能够玩儿出不少花样的

微博，某个大v的粉丝，就能够以list的格式放在redis里去缓存

key=某大v

value=[zhangsan, lisi, wangwu]

好比能够经过list存储一些列表型的数据结构，相似粉丝列表了、文章的评论列表了之类的东西

好比能够经过lrange命令，就是从某个元素开始读取多少个元素，能够基于list实现分页查询，这个很棒的一个功能，基于redis实现简单的高性能分页，能够作相似微博那种下拉不断分页的东西，性能高，就一页一页走

好比能够搞个简单的消息队列，从list头怼进去，从list尾巴那里弄出来

（4）set

无序集合，自动去重

直接基于set将系统里须要去重的数据扔进去，自动就给去重了，若是你须要对一些数据进行快速的全局去重，你固然也能够基于jvm内存里的HashSet进行去重，可是若是你的某个系统部署在多台机器上呢？

得基于redis进行全局的set去重

能够基于set玩儿交集、并集、差集的操做，好比交集吧，能够把两我的的粉丝列表整一个交集，看看俩人的共同好友是谁？对吧

把两个大v的粉丝都放在两个set中，对两个set作交集

（5）sorted set

排序的set，去重可是能够排序，写进去的时候给一个分数，自动根据分数排序，这个能够玩儿不少的花样，最大的特色是有个分数能够自定义排序规则

如何保证redis高可用和高并发

若是redis要支撑超过10万+的并发，那应该怎么作？

单机的redis几乎不太可能说QPS超过10万+，除非一些特殊状况，好比你的机器性能特别好，配置特别高，物理机，维护作的特别好，并且你的总体的操做不是太复杂

单机在几万

读写分离，通常来讲，对缓存，通常都是用来支撑读高并发的，写的请求是比较少的，可能写请求也就一秒钟几千，一两千

大量的请求都是读，一秒钟二十万次读

读写分离

主从架构 -> 读写分离 -> 支撑10万+读QPS的架构

redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构

（1）redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认本身每次复制的数据量

（2）一个master node是能够配置多个slave node的

（3）slave node也能够链接其余的slave node

（4）slave node作复制的时候，是不会block master node的正常工做的

（5）slave node在作复制的时候，也不会block对本身的查询操做，它会用旧的数据集来提供服务; 可是复制完成的时候，须要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了

（6）slave node主要用来进行横向扩容，作读写分离，扩容的slave node能够提升读的吞吐量

master持久化对于主从架构的安全保障的意义

若是采用了主从架构，那么建议必须开启master node的持久化！

不建议用slave node做为master node的数据热备，由于那样的话，若是你关掉master的持久化，可能在master宕机重启的时候数据是空的，而后可能一通过复制，salve node数据也丢了

master -> RDB和AOF都关闭了 -> 所有在内存中

master宕机，重启，是没有本地数据能够恢复的，而后就会直接认为本身IDE数据是空的

master就会将空的数据集同步到slave上去，全部slave的数据所有清空

100%的数据丢失

master节点，必需要使用持久化机制

第二个，master的各类备份方案，要不要作，万一说本地的全部文件丢失了; 从备份中挑选一份rdb去恢复master; 这样才能确保master启动的时候，是有数据的

即便采用了后续讲解的高可用机制，slave node能够自动接管master node，可是也可能sentinal尚未检测到master failure，master node就自动重启了，仍是可能致使上面的全部slave node数据清空故障

一、哨兵的介绍

sentinal，中文名是哨兵

哨兵是redis集群架构中很是重要的一个组件，主要功能以下

（1）集群监控，负责监控redis master和slave进程是否正常工做 （2）消息通知，若是某个redis实例有故障，那么哨兵负责发送消息做为报警通知给管理员 （3）故障转移，若是master node挂掉了，会自动转移到slave node上 （4）配置中心，若是故障转移发生了，通知client客户端新的master地址

哨兵自己也是分布式的，做为一个哨兵集群去运行，互相协同工做

（1）故障转移时，判断一个master node是宕机了，须要大部分的哨兵都赞成才行，涉及到了分布式选举的问题 （2）即便部分哨兵节点挂掉了，哨兵集群仍是能正常工做的，由于若是一个做为高可用机制重要组成部分的故障转移系统自己是单点的，那就很坑爹了

目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来讲，重写了不少代码，主要是让故障转移的机制和算法变得更加健壮和简单

二、哨兵的核心知识

（1）哨兵至少须要3个实例，来保证本身的健壮性 （2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性 （3）对于哨兵 + redis主从这种复杂的部署架构，尽可能在测试环境和生产环境，都进行充足的测试和演练

三、为何redis哨兵集群只有2个节点没法正常工做？

哨兵集群必须部署2个以上节点

若是哨兵集群仅仅部署了个2个哨兵实例，quorum=1

+----+ +----+ | M1 |---------| R1 | | S1 | | S2 | +----+ +----+

Configuration: quorum = 1

master宕机，s1和s2中只要有1个哨兵认为master宕机就能够还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移

同时这个时候，须要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就能够容许执行故障转移

可是若是整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来容许执行故障转移，虽然另一台机器还有一个R1，可是故障转移不会执行

一、两种数据丢失的状况

主备切换的过程，可能会致使数据丢失

（1）异步复制致使的数据丢失

由于master -> slave的复制是异步的，因此可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了

（2）脑裂致使的数据丢失

脑裂，也就是说，某个master所在机器忽然脱离了正常的网络，跟其余slave机器不能链接，可是实际上master还运行着

此时哨兵可能就会认为master宕机了，而后开启选举，将其余slave切换成了master

这个时候，集群里就会有两个master，也就是所谓的脑裂

此时虽然某个slave被切换成了master，可是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了

所以旧master再次恢复的时候，会被做为一个slave挂到新的master上去，本身的数据会清空，从新重新的master复制数据

二、解决异步复制和脑裂致使的数据丢失

min-slaves-to-write 1 min-slaves-max-lag 10

要求至少有1个slave，数据复制和同步的延迟不能超过10秒

若是说一旦全部的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

上面两个配置能够减小异步复制和脑裂致使的数据丢失

（1）减小异步复制的数据丢失

有了min-slaves-max-lag这个配置，就能够确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样能够把master宕机时因为部分数据未同步到slave致使的数据丢失下降的可控范围内

（2）减小脑裂的数据丢失

若是一个master出现了脑裂，跟其余slave丢了链接，那么上面两个配置能够确保说，若是不能继续给指定数量的slave发送数据，并且slave超过10秒没有给本身ack消息，那么就直接拒绝客户端的写请求

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失

上面的配置就确保了，若是跟任何一个slave丢了链接，在10秒后发现没有slave给本身ack，那么就拒绝新的写请求

所以在脑裂场景下，最多就丢失10秒的数据

一、sdown和odown转换机制

sdown和odown两种失败状态

sdown是主观宕机，就一个哨兵若是本身以为一个master宕机了，那么就是主观宕机

odown是客观宕机，若是quorum数量的哨兵都以为一个master宕机了，那么就是客观宕机

sdown达成的条件很简单，若是一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数以后，就主观认为master宕机

sdown到odown转换的条件很简单，若是一个哨兵在指定时间内，收到了quorum指定数量的其余哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

二、哨兵集群的自动发现机制

哨兵互相之间的发现，是经过redis的pub/sub系统实现的，每一个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候全部其余哨兵均可以消费到这个消息，并感知到其余的哨兵的存在

每隔两秒钟，每一个哨兵都会往本身监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是本身的host、ip和runid还有对这个master的监控配置

每一个哨兵也会去监听本身监控的每一个master+slaves对应的__sentinel__:hello channel，而后去感知到一样在监听这个master+slaves的其余哨兵的存在

每一个哨兵还会跟其余哨兵交换对master的监控配置，互相进行监控配置的同步

三、slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，好比slave若是要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 若是slave链接到了一个错误的master上，好比故障转移以后，那么哨兵会确保它们链接到正确的master上

四、slave->master选举算法

若是一个master被认为odown了，并且majority哨兵都容许了主备切换，那么某个哨兵就会执行主备切换操做，此时首先要选举一个slave来

会考虑slave的一些信息

（1）跟master断开链接的时长 （2）slave优先级 （3）复制offset （4）run id

若是一个slave跟master断开链接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

（1）按照slave优先级进行排序，slave priority越低，优先级就越高 （2）若是slave priority相同，那么看replica offset，哪一个slave复制了越多的数据，offset越靠后，优先级就越高 （3）若是上面两个条件都相同，那么选择一个run id比较小的那个slave

五、quorum和majority

每次一个哨兵要作主备切换，首先须要quorum数量的哨兵认为odown，而后选举出一个哨兵来作切换，这个哨兵还得获得majority哨兵的受权，才能正式执行切换

若是quorum < majority，好比5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵受权就能够执行切换

可是若是quorum >= majority，那么必须quorum数量的哨兵都受权，好比5个哨兵，quorum是5，那么必须5个哨兵都赞成受权，才能执行切换

六、configuration epoch

哨兵会对一套redis master+slave进行监控，有相应的监控的配置

执行切换的那个哨兵，会从要切换到的新master（salve->master）那里获得一个configuration epoch，这就是一个version号，每次切换的version号都必须是惟一的

若是第一个选举出的哨兵切换失败了，那么其余哨兵，会等待failover-timeout时间，而后接替继续执行切换，此时会从新获取一个新的configuration epoch，做为新的version号

七、configuraiton传播

哨兵完成切换以后，会在本身本地更新生成最新的master配置，而后同步给其余的哨兵，就是经过以前说的pub/sub消息机制

这里以前的version号就很重要了，由于各类消息都是经过一个channel去发布和监听的，因此一个哨兵完成一次新的切换以后，新的master配置是跟着新的version号的

其余的哨兵都是根据版本号的大小来更新本身的master配置的

面试题剖析

就是若是你用redis缓存技术的话，确定要考虑如何用redis来加多台机器，保证redis是高并发的，还有就是如何让Redis保证本身不是挂掉之后就直接死掉了，redis高可用

我这里会选用我以前讲解过这一块内容，redis高并发、高可用、缓存一致性

redis高并发：主从架构，一主多从，通常来讲，不少项目其实就足够了，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例能够提供每秒10万的QPS。

redis高并发的同时，还须要容纳大量的数据：一主多从，每一个实例都容纳了完整的数据，好比redis主就10G的内存量，其实你就最对只能容纳10g的数据量。若是你的缓存要容纳的数据量很大，达到了几十g，甚至几百g，或者是几t，那你就须要redis集群，并且用redis集群以后，能够提供可能每秒几十万的读写并发。

redis高可用：若是你作主从架构部署，其实就是加上哨兵就能够了，就能够实现，任何一个实例宕机，自动会进行主备切换。

讲解分布式数据存储的核心算法，数据分布的算法

hash算法 -> 一致性hash算法（memcached） -> redis cluster，hash slot算法

用不一样的算法，就决定了在多个master节点的时候，数据如何分布到这些节点上去，解决这个问题
复制代码

一、redis cluster介绍

redis cluster

（1）自动将数据进行分片，每一个master上放一部分数据 （2）提供内置的高可用支持，部分master不可用时，仍是能够继续工做的

在redis cluster架构下，每一个redis要放开两个端口号，好比一个是6379，另一个就是加10000的端口号，好比16379

16379端口号是用来进行节点间通讯的，也就是cluster bus的东西，集群总线。cluster bus的通讯，用来进行故障检测，配置更新，故障转移受权

cluster bus用了另一种二进制的协议，主要用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间

二、最老土的hash算法和弊端（大量缓存重建）

三、一致性hash算法（自动缓存迁移）+虚拟节点（自动负载均衡）

四、redis cluster的hash slot算法

redis cluster有固定的16384个hash slot，对每一个key计算CRC16值，而后对16384取模，能够获取key对应的hash slot

redis cluster中每一个master都会持有部分slot，好比有3个master，那么可能每一个master持有5000多个hash slot

hash slot让node的增长和移除很简单，增长一个master，就将其余master的hash slot移动部分过去，减小一个master，就将它的hash slot移动到其余master上去

移动hash slot的成本是很是低的

客户端的api，能够对指定的数据，让他们走同一个hash slot，经过hash tag来实现

1、节点间的内部通讯机制

一、基础通讯原理

（1）redis cluster节点间采起gossip协议进行通讯

跟集中式不一样，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通讯，保持整个集群全部节点的数据是完整的

维护集群的元数据用得，集中式，一种叫作gossip

集中式：好处在于，元数据的更新和读取，时效性很是好，一旦元数据出现了变动，当即就更新到集中式的存储中，其余节点读取的时候当即就能够感知到; 很差在于，全部的元数据的跟新压力所有集中在一个地方，可能会致使元数据的存储有压力

gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到全部节点上去更新，有必定的延时，下降了压力; 缺点，元数据更新有延时，可能致使集群的一些操做会有一些滞后

咱们刚才作reshard，去作另一个操做，会发现说，configuration error，达成一致

（2）10000端口

每一个节点都有一个专门用于节点间通讯的端口，就是本身提供服务的端口号+10000，好比7001，那么用于节点间通讯的就是17001端口

每隔节点每隔一段时间都会往另外几个节点发送ping消息，同时其余几点接收到ping以后返回pong

（3）交换的信息

故障信息，节点的增长和移除，hash slot信息，等等

二、gossip协议

gossip协议包含多种消息，包括ping，pong，meet，fail，等等

meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，而后新节点就会开始与其余节点进行通讯

redis-trib.rb add-node

其实内部就是发送了一个gossip meet消息，给新加入的节点，通知那个节点去加入咱们的集群

ping: 每一个节点都会频繁给其余节点发送ping，其中包含本身的状态还有本身维护的集群元数据，互相经过ping交换元数据

每一个节点每秒都会频繁发送ping给其余的集群，ping，频繁的互相之间交换数据，互相进行元数据的更新

pong: 返回ping和meet，包含本身的状态和其余信息，也能够用于信息广播和更新

fail: 某个节点判断另外一个节点fail以后，就发送fail给其余节点，通知其余节点，指定的节点宕机了

三、ping消息深刻

ping很频繁，并且要携带一些元数据，因此可能会加剧网络负担

每一个节点每秒会执行10次ping，每次会选择5个最久没有通讯的其余节点

固然若是发现某个节点通讯延时达到了cluster_node_timeout / 2，那么当即发送ping，避免数据交换延时过长，落后的时间太长了

好比说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的状况，就会有问题

因此cluster_node_timeout能够调节，若是调节比较大，那么会下降发送的频率

每次ping，一个是带上本身节点的信息，还有就是带上1/10其余节点的信息，发送出去，进行数据交换

至少包含3个其余节点的信息，最多包含总节点-2个其余节点的信息

---

2、面向集群的jedis内部实现原理

开发，jedis，redis的java client客户端，redis cluster，jedis cluster api

jedis cluster api与redis cluster集群交互的一些基本原理

一、基于重定向的客户端

redis-cli -c，自动重定向

（1）请求重定向

客户端可能会挑选任意一个redis实例去发送命令，每一个redis实例接收到命令，都会计算key对应的hash slot

若是在本地就在本地处理，不然返回moved给客户端，让客户端进行重定向

cluster keyslot mykey，能够查看一个key对应的hash slot是什么

用redis-cli的时候，能够加入-c参数，支持自动的请求重定向，redis-cli接收到moved以后，会自动重定向到对应的节点执行命令

（2）计算hash slot

计算hash slot的算法，就是根据key计算CRC16值，而后对16384取模，拿到对应的hash slot

用hash tag能够手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，好比set mykey1:{100}和set mykey2:{100}

（3）hash slot查找

节点间经过gossip协议进行数据交换，就知道每一个hash slot在哪一个节点上

二、smart jedis

（1）什么是smart jedis

基于重定向的客户端，很消耗网络IO，由于大部分状况下，可能都会出现一次请求重定向，才能找到正确的节点

因此大部分的客户端，好比java redis客户端，就是jedis，都是smart的

本地维护一份hashslot -> node的映射表，缓存，大部分状况下，直接走本地缓存就能够找到hashslot -> node，不须要经过节点进行moved重定向

（2）JedisCluster的工做原理

在JedisCluster初始化的时候，就会随机选择一个node，初始化hashslot -> node映射表，同时为每一个节点建立一个JedisPool链接池

每次基于JedisCluster执行操做，首先JedisCluster都会在本地计算key的hashslot，而后在本地映射表找到对应的节点

若是那个node正好仍是持有那个hashslot，那么就ok; 若是说进行了reshard这样的操做，可能hashslot已经不在那个node上了，就会返回moved

若是JedisCluter API发现对应的节点返回moved，那么利用该节点的元数据，更新本地的hashslot -> node映射表缓存

重复上面几个步骤，直到找到对应的节点，若是重试超过5次，那么就报错，JedisClusterMaxRedirectionException

jedis老版本，可能会出如今集群某个节点故障还没完成自动切换恢复时，频繁更新hash slot，频繁ping节点检查活跃，致使大量网络IO开销

jedis最新版本，对于这些过分的hash slot更新和ping，都进行了优化，避免了相似问题

（3）hashslot迁移和ask重定向

若是hash slot正在迁移，那么会返回ask重定向给jedis

jedis接收到ask重定向以后，会从新定位到目标节点去执行，可是由于ask发生在hash slot迁移过程当中，因此JedisCluster API收到ask是不会更新hashslot本地缓存

已经能够肯定说，hashslot已经迁移完了，moved是会更新本地hashslot->node映射表缓存的

---

3、高可用性与主备切换原理

redis cluster的高可用的原理，几乎跟哨兵是相似的

一、判断节点宕机

若是一个节点认为另一个节点宕机，那么就是pfail，主观宕机

若是多个节点都认为另一个节点宕机了，那么就是fail，客观宕机，跟哨兵的原理几乎同样，sdown，odown

在cluster-node-timeout内，某个节点一直没有返回pong，那么就被认为pfail

若是一个节点认为某个节点pfail了，那么会在gossip ping消息中，ping给其余节点，若是超过半数的节点都认为pfail了，那么就会变成fail

二、从节点过滤

对宕机的master node，从其全部的slave node中，选择一个切换成master node

检查每一个slave node与master node断开链接的时间，若是超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master

这个也是跟哨兵是同样的，从节点超时过滤的步骤

三、从节点选举

哨兵：对全部从节点进行排序，slave priority，offset，run id

每一个从节点，都根据本身对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举

全部的master node开始slave选举投票，给要进行选举的slave进行投票，若是大部分master node（N/2 + 1）都投票给了某个从节点，那么选举经过，那个从节点能够切换成master

从节点执行主备切换，从节点切换为主节点

四、与哨兵比较

整个流程跟哨兵相比，很是相似，因此说，redis cluster功能强大，直接集成了replication和sentinal的功能

没有办法去给你们深刻讲解redis底层的设计的细节，核心原理和设计的细节，那个除非单独开一门课，redis底层原理深度剖析，redis源码

对于我们这个架构课来讲，主要关注的是架构，不是底层的细节，对于架构来讲，核心的原理的基本思路，是要梳理清晰的

缓存雪崩发生的现象

缓存雪崩的事前事中过后的解决方案

事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃

事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死

过后：redis持久化，快速恢复缓存数据