校招面试重点总结(四)

四，Redis

 

0，数据类型及应用场景

字符串类型、散列类型、列表类型、集合类型、有序集合类型。

Redis的应用场景

   1，缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）

   2，分布式集群架构中的session分离。

   3，聊天室的在线好友列表。

   4，任务队列。（秒杀、抢购等等）

   5，应用排行榜。

   6，网站访问统计。

   7，数据过期处理（可以精确到毫秒）
 

1，持久化

    Redis提供两种持久化方式，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

    RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

    AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

RDB存在哪些优势呢？

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势有哪些呢？

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

常用配置

RDB持久化配置 Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置 在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。

2，事务处理

Redis的事务定义

    Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。 Redis事务的主要作用就是串联多个命令防止别的命令插队。

multi、exec、discard命令

    在Redis中从输入multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入exec后，Redis会将之前的命令队列中的命令依次执行。 在组队的过程中可以通过discard来放弃组队，这样先前输入的命令也都将不会执行。这个过程的示意图如下：

 

正常执行事务代码示例：

127.0.0.1:6379> multi         #命开启事务
OK
127.0.0.1:6379> set key1 v1   #命令入队
QUEUED
127.0.0.1:6379> set key2 v2   #命令入队
QUEUED
127.0.0.1:6379> get key2      #命令入队
QUEUED
127.0.0.1:6379> set key3 v3   #命令入队
QUEUED
127.0.0.1:6379> exec        #执行事务
1) OK
2) OK
3) "v2"
4) OK

事务执行结束，队列就消失了，再去get会返回nil

放弃事务代码示例：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> discard   # 放弃事务
OK
127.0.0.1:6379> get k3    # 事务队列中的命令都不会执行
(nil)

事务的错误处理

在组队的过程中如果某个命令出现了错误报告，那么执行exec时整个的命令队列都会被取消，即所有的命令都不会成功执行。这个过程的示意图如下：

 

如果在执行阶段的某个命令报出了错误（比如对一个非整数型的值进行incr自增），则执行exec时只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。这个过程的示意图如下：

 

编译型异常（命令有错）示例：

事务中所有的命令都不会被执行

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> getset k3  #错误命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> exec   #执行事务报错
(error) EXECABORT Transaction discarded because of previous errors.   
127.0.0.1:6379> get k5   #所有命令都不会被执行
(nil)

我们在使用getset命令时少写了一个参数，这是命令错误，所以在执行事务是会报错，最终所有的命令都不会被执行。

执行时异常示例：

如果事务队列中存在语法性错误，执行命令的时候，其他命令可以正常执行，错误命令抛出异常

127.0.0.1:6379> set k1 "v1"  #字符串无法+1
OK
127.0.0.1:6379> multi
OK  
127.0.0.1:6379> incr k1   #执行至此会失败
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> exec    #执行事务是，第一个命令执行出错，其他命令依旧会执行
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
4) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"

Redis的监视测试 watch key [key ...] 命令

    在Redis执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行exec之前这个(或这些) key 被其他命令所改动（比如被Redis的另一个连接先修改了key的value值并执行成功），那么当前事务将被打断，对这个key的修改将无效。

正常执行成功：

127.0.0.1:6379> set money 100 
OK
127.0.0.1:6379> set out 0 
OK
127.0.0.1:6379> watch money   #监视money对象 
OK
127.0.0.1:6379> multi   #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功 
OK
127.0.0.1:6379> decrby money 20 
QUEUED 
127.0.0.1:6379> incrby out 20 
QUEUED 
127.0.0.1:6379> exec 
1) (integer) 80 
2) (integer) 20 

多线程修改

线程1：
​
127.0.0.1:6379> get money
"80"
127.0.0.1:6379> set money 1000
OK

线程2：
​
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec
(nil)

watch监视后的事务执行失败后，可以使用unwatch解锁后重新开始监视：

127.0.0.1:6379> unwatch
OK
127.0.0.1:6379> watch money       #获取最新的值，再次监视
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec
1) (integer) 990
2) (integer) 10

此时exec时，比对监视的值是否发生变化，如果没有变化，可以执行成功，如果变量被修改 了，执行失败

Redis事务三特性 ① 单独的隔离操作 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

② 没有隔离级别的概念 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

③ 不保证原子性 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

3，悲观锁、乐观锁

    悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

 

    乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

 

4，击穿、穿透和雪崩

a，击穿

大家都知道，计算机的瓶颈之一就是IO，为了解决内存与磁盘速度不匹配的问题，产生了缓存，将一些热点数据放在内存中，随用随取，降低连接到数据库的请求链接,避免数据库挂掉。需要注意的是，无论是击穿还是后面谈到的穿透与雪崩,都是在高并发前提下，比如当缓存中某一个热点key失效。

 

有两个主要原因:

1、Key过期；2、Key被页面置换淘汰。

    对于第一个原因是因为在Redis中，Key有过期时间，如果某一个时刻(假如商城做活动,零点开始)key失效，那么零点之后对某一个商品查询请求将全都压到数据库上，导致数据库崩。

    对于第二个原因，因为内存是有限的，要时时刻刻缓存新的数据，淘汰旧的数据，所以在一定的页面置换策略(常见页面置换算法图解)中，淘汰数据，如果某些商品做活动之前无人问津，势必会被淘汰。

置换策略：
noeviction: 不进行置换，表示即使内存达到上限也不进行置换，所有能引起内存增加的命令都会返回error
allkeys-lru: 优先删除掉最近最不经常使用的key，用以保存新数据
volatile-lru: 只从设置失效（expire set）的key中选择最近最不经常使用的key进行删除，用以保存新数据
allkeys-random: 随机从all-keys中选择一些key进行删除，用以保存新数据
volatile-random: 只从设置失效（expire set）的key中，选择一些key进行删除，用以保存新数据
volatile-ttl: 只从设置失效（expire set）的key中，选出存活时间（TTL）最短的key进行删除，用以保存新数据

击穿的应对思路

正常的处理请求如图:

 

    由于key过期在所难免，高流量来到Redis时,根据Redis的单线程特性，可以认为任务是在队列里依次执行的，当请求到达Redis发现Key过期时，进行一个操作：设置锁。

这个流程大概如下:

• 请求到达Redis，发现Redis Key过期，查看有没有锁，没有锁的话回到队列后面排队

• 设置锁，注意，这儿应该是setnx()，而不是set()，因为可能有其他线程已经设置锁了

• 获取锁，拿到锁了就去数据库取数据，请求返回后释放锁。

  备注：setnx『SET if Not eXists』

 

    但是引出了一个新的问题，如果拿到锁去拿数据的请求然后挂了怎么办?也就是锁没有释放，其他进程都在等锁，解决办法是:

    对锁设置一个过期时间，如果到达了过期时间还没释放就自动释放，问题又来了，锁挂了好说，但是如果是锁超时呢?也就是在设定的时间里数据没有取出来，但是锁由过期了，常见的思路是，锁过期时间值递增，但是想想不靠谱，因为第一个请求可能超时，如果后面的也超时呢，接连多次超时之后，锁过期时间值势必特别大了，这样做弊端太多。

    另外一个思路是，再开启一个线程，进行监控，如果取数据的线程没有挂的话，就适当延迟锁的过期时间。

 

b，穿透

      穿透主要原因是很多请求都在访问数据库不存在的数据，例如一个卖书的商城一直被请求查询茶叶产品，由于Redis缓存主要是用来缓存热点数据，对于数据库都不存在的数据,是没法缓存的，这种异常流量就会直接到达数据库并且返回"没有"的查询结果。

     应对这种请求，处理办法是对访问请求加一层过滤器，例如布隆过滤器、增强版布隆过滤器、布谷鸟过滤器。

 

    除了布隆过滤器，可以增加一些参数检验，例如数据库数据id一般都是递增的，如果请求 id = -10 这种参数，势必绕过Redis，避免这种情况，可以对用户真实性检验等操作。

Redis布隆过滤器与布谷鸟过滤器：自行了解

c，雪崩 雪崩，和击穿类似，不同的是击穿是一个热点Key某时刻失效，而雪崩是大量的热点Key在一瞬间失效，网络上很多博客都在强调解决雪崩的策略是随机过期时间，这个非常不准确，举个例子，银行做活动，之前这个利息系数为2%，过了零点系数改为3%，这种情况能将用户的对应的key改为随机过期吗？如果用的过去的数据叫脏数据。

明显不可以，同样存钱，你存到年底利息300万，隔壁才200万，这不得打架啊，开玩笑~

正确的思路是，首先要看看这个Key过期是不是时点性有关，时点性无关的话，可以随机过期时间解决。

如果是时点性有关，例如刚刚说的银行某一天改变某系数，那么就要利用强依赖击穿方案，策略是先过去的线程更新一下所有key。

 

在后台更新热点key的同时，业务层将进来的请求延时一下，例如短暂的睡几毫秒或者秒，给后面的更新热点key分散压力。

5，主从复制

什么是主从复制

 

    主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。

    默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

    和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4. 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量

5. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制的相关操作

(1)配置文件:在从服务器的配置文件中加入 slaveof<masterip><masterport>。例如，新增redis6360.conf, 打开redis6360.conf并加入 slaveof 192.168.152.128 6359, 在6359启动完后再启6360，完成配置；

(2)启动命令：redis-server启动命令后加入 --slaveof<masterip><masterport>。例如，redis-server --slaveof 192.168.152.128 6359 临时生效

(3)查看状态：通过 info replication 命令可以看到复制的一些信息。

(4)断开主从复制：在slave节点，执行6380:>slaveof no one

(5)断开后再变成主从复制：6360:> slaveof 192.168.152.128 6359

(6)数据较重要的节点，主从复制时使用密码验证： requirepass

主从复制原理

    主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

    在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。

 

1）保存主节点（master）信息

执行 slaveof 后 Redis 会打印如下日志：

 

（2）从节点与主节点建立网络连接

从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。

 

从节点与主节点建立网络连接。

从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

 

如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone 取消复制。

关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：

 

（3）发送 ping 命令

连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：

• 检测主从之间网络套接字是否可用。

• 检测主节点当前是否可接受处理命令。

如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

 

 

从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：

 

（4）权限验证

如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。

（5）同步数据集

主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

（6）命令持续复制

当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

- 从服务器配置主服务器的连接信息（slaveof属性）；

- 从服务器连接上主服务器，发送SYNC命令

- 主服务器判断是否为全量复制：如果是全量复制，则进入下一步；否则可以看增量复制的子流程。

- 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；

- 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

- 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

- 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

 

增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

6，哨兵

一、什么是哨兵模式：

1、哨兵模式的架构：

 

2、什么是哨兵模式：

在主从模式下（主从模式就是把上图的所有哨兵去掉），master节点负责写请求，然后异步同步给slave节点，从节点负责处理读请求。如果master宕机了，需要手动将从节点晋升为主节点，并且还要切换客户端的连接数据源。这就无法达到高可用，而通过哨兵模式就可以解决这一问题。

哨兵模式是Redis的高可用方式，哨兵节点是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点挂掉时，哨兵会第一时间感知到，并且在slave节点中重新选出来一个新的master，然后将新的master信息通知给client端，从而实现高可用。这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。

3、哨兵的主要工作任务：

（1）监控：哨兵会不断地检查你的Master和Slave是否运作正常。

（2）提醒：当被监控的某个Redis节点出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。

（3）自动故障迁移：当一个Master不能正常工作时，哨兵会进行自动故障迁移操作，将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用新Master代替失效Master。

二、哨兵模式的搭建： 1、配置sentinel.conf文件，配件需要监听的主从的master节点

sentinel monitor <master‐name> <ip> <redis‐port> <quorum>

（1）master‐name：主节点master的名字

（2）quorum：哨兵集群中多少个sentinel 认为 master 失效才判定为客观下线，一般配节点数/2+1，也就是说大于半数

2、如果主从master设置了密码，还需要配置：

sentinel auth-pass <master-name> <password>

由于master挂了之后，哨兵会进行重新的选举，如果slave也配置了连接密码，那么最好在其他的节点都配置上 masterauth xxx，保证挂了的服务重启之后能正常加入主从中去

3、修改心跳检测的主观下线时间（后续讲原理的时候会详细讲到）：

sentinel down-after-milliseconds <master-name> <time>

（1）time：主观下线阈值，单位为毫秒ms

4、从服务器的个数配置：

sentinel parallel-syncs mymaster 2

5、启动指定的哨兵配置文件启动哨兵：

./redis-server sentinel.conf --sentinel &

6、查看状态信息：

配置完之后，进入./redis-cli，输入info命令，查看哨兵的状态信息

 

再使用同样的配置文件，启动另外两个哨兵，在查看信息之后会发现哨兵数量变成3个

 

7、Java客户端连接哨兵模式，只需要配置哨兵节点即可

spring.redis.sentinel.master=mymaster #哨兵配置中集群名字 spring.redis.sentinel.nodes=哨兵ip1:哨兵端口1,哨兵ip2:哨兵端口2,哨兵ip3:哨兵端口3

三、哨兵模式的工作原理： 哨兵是一个分布式系统，可以在一个架构中运行多个哨兵进程，这些进程使用流言协议(gossip protocols)来传播Master是否下线的信息，并使用投票协议(agreement protocols)来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。哨兵模式的具体工作原理如下：

1、心跳机制：

（1）Sentinel 与 Redis Node：Redis Sentinel 是一个特殊的 Redis 节点。在哨兵模式创建时，需要通过配置指定 Sentinel 与 Redis Master Node 之间的关系，然后 Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送 info 命令获取其拓扑结构和状态信息。

（2）Sentinel与Sentinel：基于 Redis 的订阅发布功能， 每个 Sentinel 节点会向主节点的 sentinel：hello 频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息 ，同时每个 Sentinel 节点也会订阅该频道， 来获取其他 Sentinel 节点的信息以及它们对主节点的判断

通过以上两步所有的 Sentinel 节点以及它们与所有的 Redis 节点之间都已经彼此感知到，之后每个 Sentinel 节点会向主节点、从节点、以及其余 Sentinel 节点定时发送 ping 命令作为心跳检测， 来确认这些节点是否可达。

2、判断master节点是否下线：

（1）每个 sentinel 哨兵节点每隔1s 向所有的master、slave以及其他 sentinel 节点发送一个PING命令，作用是通过心跳检测，检测主从服务器的网络连接状态

（2）如果 master 节点回复 PING 命令的时间超过 down-after-milliseconds 设定的阈值（默认30s），则这个 master 会被 sentinel 标记为主观下线，修改其 flags 状态为SRI_S_DOWN

（3）当sentinel 哨兵节点将 master 标记为主观下线后，会向其余所有的 sentinel 发送sentinel is-master-down-by-addr消息，询问其他sentinel是否同意该master下线

发送命令：sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>

ip：主观下线的服务ip

port：主观下线的服务端口

current_epoch：sentinel的纪元

runid：*表示检测服务下线状态，如果是sentinel的运行id，表示用来选举领头sentinel

（4）每个sentinel收到命令之后，会根据发送过来的 ip和port 检查自己判断的结果，回复自己是否认为该master节点已经下线了

回复内容主要包含三个参数（由于上面发送的runid参数是*，这里先忽略后两个参数）

down_state（1表示已下线，0表示未下线）

leader_runid（领头sentinal id）

leader_epoch（领头sentinel纪元）。

（5）sentinel收到回复之后，如果同意master节点进入主观下线的sentinel数量大于等于quorum，则master会被标记为客观下线，即认为该节点已经不可用。

（6）在一般情况下，每个 Sentinel 每隔 10s 向所有的Master，Slave发送 INFO 命令。当Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次。作用：发现最新的集群拓扑结构

3、基于Raft算法选举领头sentinel：

到现在为止，已经知道了master客观下线，那就需要一个sentinel来负责故障转移，那到底是哪个sentinel节点来做这件事呢？需要通过选举实现，具体的选举过程如下：

（1）判断客观下线的sentinel节点向其他 sentinel 节点发送 SENTINEL is-master-down-by-addr ip port current_epoch runid

注意：这时的runid是自己的run id，每个sentinel节点都有一个自己运行时id

（2）目标sentinel回复是否同意master下线并选举领头sentinel，选择领头sentinel的过程符合先到先得的原则。举例：sentinel1判断了客观下线，向sentinel2发送了第一步中的命令，sentinel2回复了sentinel1，说选你为领头，这时候sentinel3也向sentinel2发送第一步的命令，sentinel2会直接拒绝回复

（3）当sentinel发现选自己的节点个数超过 majority 的个数的时候，自己就是领头节点

（4）如果没有一个sentinel达到了majority的数量，等一段时间，重新选举

4、故障转移：

有了领头sentinel之后，下面就是要做故障转移了，故障转移的一个主要问题和选择领头sentinel问题差不多，到底要选择哪一个slaver节点来作为master呢？按照我们一般的常识，我们会认为哪个slave节点中的数据和master中的数据相识度高哪个slaver就是master了，其实哨兵模式也差不多是这样判断的，不过还有别的判断条件，详细介绍如下：

（1）在进行选择之前需要先剔除掉一些不满足条件的slaver，这些slaver不会作为变成master的备选

剔除列表中已经下线的从服务 剔除有5s没有回复sentinel的info命令的slave 剔除与已经下线的主服务连接断开时间超过 down-after-milliseconds * 10 + master宕机时长 的slaver （2）选主过程：

① 选择优先级最高的节点，通过sentinel配置文件中的replica-priority配置项，这个参数越小，表示优先级越高

② 如果第一步中的优先级相同，选择offset最大的，offset表示主节点向从节点同步数据的偏移量，越大表示同步的数据越多

③ 如果第二步offset也相同，选择run id较小的

5、修改配置：

新的master节点选择出来之后，还需要做一些事情配置的修改，如下：

（1）领头sentinel会对选出来的从节点执行slaveof no one 命令让其成为主节点

（2）领头sentinel 向别的slave发送slaveof命令，告诉他们新的master是谁谁谁，你们向这个master复制数据

（3）如果之前的master重新上线时，领头sentinel同样会给起发送slaveof命令，将其变成从节点

7，补充

（1）. 使用过Redis分布式锁嘛？有哪些注意点呢？

分布式锁，是控制分布式系统不同进程共同访问共享资源的一种锁的实现。秒杀下单、抢红包等等业务场景，都需要用到分布式锁，我们项目中经常使用Redis作为分布式锁。

选了Redis分布式锁的几种实现方法，大家来讨论下，看有没有啥问题哈。

• 命令setnx + expire分开写

• setnx + value值是过期时间

• set的扩展命令（set ex px nx）

• set ex px nx + 校验唯一随机值,再删除

命令setnx + expire分开写

if（jedis.setnx(key,lock_value) == 1）{ //加锁 expire（key，100）; //设置过期时间 try { do something //业务请求 }catch(){ } finally { jedis.del(key); //释放锁 } }

如果执行完setnx加锁，正要执行expire设置过期时间时，进程crash掉或者要重启维护了，那这个锁就“长生不老”了，别的线程永远获取不到锁啦，所以分布式锁不能这么实现。

setnx + value值是过期时间

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间 
String expiresStr = String.valueOf(expires); // 如果当前锁不存在，返回加锁成功 
if (jedis.setnx(key, expiresStr) == 1) { return true; } // 如果锁已经存在，获取锁的过期时间 String currentValueStr = jedis.get(key); // 如果获取到的过期时间，小于系统当前时间，表示已经过期 if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) { // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈） String oldValueStr = jedis.getSet(key_resource_id, expiresStr); if (oldValueStr != null && oldValueStr.equals(currentValueStr)) { // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁 return true; } } //其他情况，均返回加锁失败 return false; }

笔者看过有开发小伙伴是这么实现分布式锁的，但是这种方案也有这些缺点：

• 过期时间是客户端自己生成的，分布式环境下，每个客户端的时间必须同步。

• 没有保存持有者的唯一标识，可能被别的客户端释放/解锁。

• 锁过期的时候，并发多个客户端同时请求过来，都执行了jedis.getSet()，最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖。

set的扩展命令（set ex px nx）（注意可能存在的问题）

if（jedis.set(key, lock_value, "NX", "EX", 100s) == 1）{ //加锁 try { do something //业务处理 }catch(){ } finally { jedis.del(key); //释放锁 } }

这个方案可能存在这样的问题：

• 锁过期释放了，业务还没执行完。

• 锁被别的线程误删。

set ex px nx + 校验唯一随机值,再删除

if（jedis.set(key, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁 try { do something //业务处理 }catch(){ } finally { //判断是不是当前线程加的锁,是才释放 if (uni_request_id.equals(jedis.get(key))) { jedis.del(key); //释放锁 } } }

在这里，判断当前线程加的锁和释放锁是不是一个原子操作。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端，会解除他人加的锁。

 

一般也是用lua脚本代替。lua脚本如下：

if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end;

这种方式比较不错了，一般情况下，已经可以使用这种实现方式。但是存在锁过期释放了，业务还没执行完的问题（实际上，估算个业务处理的时间，一般没啥问题了）。

(2)使用过Redisson嘛？说说它的原理

分布式锁可能存在锁过期释放，业务没执行完的问题。有些小伙伴认为，稍微把锁过期时间设置长一些就可以啦。其实我们设想一下，是否可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放。

当前开源框架Redisson就解决了这个分布式锁问题。我们一起来看下Redisson底层原理是怎样的吧：

 

只要线程一加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下，如果线程1还持有锁，那么就会不断的延长锁key的生存时间。因此，Redisson就是使用Redisson解决了锁过期释放，业务没执行完问题。

(3)什么是Redlock算法

Redis一般都是集群部署的，假设数据在主从同步过程，主节点挂了，Redis分布式锁可能会有哪些问题呢？一起来看些这个流程图：

 

如果线程一在Redis的master节点上拿到了锁，但是加锁的key还没同步到slave节点。恰好这时，master节点发生故障，一个slave节点就会升级为master节点。线程二就可以获取同个key的锁啦，但线程一也已经拿到锁了，锁的安全性就没了。

为了解决这个问题，Redis作者 antirez提出一种高级的分布式锁算法：Redlock。Redlock核心思想是这样的：

搞多个Redis master部署，以保证它们不会同时宕掉。并且这些master节点是完全相互独立的，相互之间不存在数据同步。同时，需要确保在这多个master实例上，是与在Redis单实例，使用相同方法来获取和释放锁。

我们假设当前有5个Redis master节点，在5台服务器上面运行这些Redis实例。

 

RedLock的实现步骤:如下

• 1.获取当前时间，以毫秒为单位。

• 2.按顺序向5个master节点请求加锁。客户端设置网络连接和响应超时时间，并且超时时间要小于锁的失效时间。（假设锁自动失效时间为10秒，则超时时间一般在5-50毫秒之间,我们就假设超时时间是50ms吧）。如果超时，跳过该master节点，尽快去尝试下一个master节点。

• 3.客户端使用当前时间减去开始获取锁时间（即步骤1记录的时间），得到获取锁使用的时间。当且仅当超过一半（N/2+1，这里是5/2+1=3个节点）的Redis master节点都获得锁，并且使用的时间小于锁失效时间时，锁才算获取成功。（如上图，10s> 30ms+40ms+50ms+4m0s+50ms）

• 如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。

• 如果获取锁失败（没有在至少N/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。

简化下步骤就是：

• 按顺序向5个master节点请求加锁

• 根据设置的超时时间来判断，是不是要跳过该master节点。

• 如果大于等于三个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。

• 如果获取锁失败，解锁！

(4)Redis的跳跃表

 

跳跃表

• 跳跃表是有序集合zset的底层实现之一

• 跳跃表支持平均O（logN）,最坏 O（N）复杂度的节点查找，还可以通过顺序性操作批量处理节点。

• 跳跃表实现由zskiplist和zskiplistNode两个结构组成，其中zskiplist用于保存跳跃表信息（如表头节点、表尾节点、长度），而zskiplistNode则用于表示跳跃表节点。

• 跳跃表就是在链表的基础上，增加多级索引提升查找效率。

(5)MySQL与Redis 如何保证双写一致性

• 缓存延时双删

• 删除缓存重试机制

• 读取biglog异步删除缓存

延时双删？

什么是延时双删呢？流程图如下：

 

延时双删流程

1. 先删除缓存

2. 再更新数据库

3. 休眠一会（比如1秒），再次删除缓存。

这个休眠一会，一般多久呢？都是1秒？

这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。

这种方案还算可以，只有休眠那一会（比如就那1秒），可能有脏数据，一般业务也会接受的。但是如果第二次删除缓存失败呢？缓存和数据库的数据还是可能不一致，对吧？给Key设置一个自然的expire过期时间，让它自动过期怎样？那业务要接受过期时间内，数据的不一致咯？还是有其他更佳方案呢？

删除缓存重试机制

因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制

 

删除缓存重试流程

1. 写请求更新数据库

2. 缓存因为某些原因，删除失败

3. 把删除失败的key放到消息队列

4. 消费消息队列的消息，获取要删除的key

5. 重试删除缓存操作

读取biglog异步删除缓存

重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。其实，还可以这样优化：通过数据库的binlog来异步淘汰key。

 

以mysql为例吧

• 可以使用阿里的canal将binlog日志采集发送到MQ队列里面

• 然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性

(6)为什么Redis 6.0 之后改多线程呢？

• Redis6.0之前，Redis在处理客户端的请求时，包括读socket、解析、执行、写socket等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。

• Redis6.0之前为什么一直不使用多线程？使用Redis时，几乎不存在CPU成为瓶颈的情况， Redis主要受限于内存和网络。例如在一个普通的Linux系统上，Redis通过使用pipelining每秒可以处理100万个请求，所以如果应用程序主要使用O(N)或O(log(N))的命令，它几乎不会占用太多CPU。

redis使用多线程并非是完全摒弃单线程，redis还是使用单线程模型来处理客户端的请求，只是使用多线程来处理数据的读写和协议解析，执行命令还是使用单线程。

这样做的目的是因为redis的性能瓶颈在于网络IO而非CPU，使用多线程能提升IO读写的效率，从而整体提高redis的性能。

(7)Redis的Hash 冲突怎么办

Redis 作为一个K-V的内存数据库，它使用用一张全局的哈希来保存所有的键值对。这张哈希表，有多个哈希桶组成，哈希桶中的entry元素保存了key和value指针，其中key指向了实际的键，value指向了实际的值。

 

哈希表查找速率很快的，有点类似于Java中的HashMap，它让我们在O(1) 的时间复杂度快速找到键值对。首先通过key计算哈希值，找到对应的哈希桶位置，然后定位到entry，在entry找到对应的数据。

什么是哈希冲突？

哈希冲突：通过不同的key，计算出一样的哈希值，导致落在同一个哈希桶中。

Redis为了解决哈希冲突，采用了链式哈希。链式哈希是指同一个哈希桶中，多个元素用一个链表来保存，它们之间依次用指针连接。

 

有些读者可能还会有疑问：哈希冲突链上的元素只能通过指针逐一查找再操作。当往哈希表插入数据很多，冲突也会越多，冲突链表就会越长，那查询效率就会降低了。

为了保持高效，Redis 会对哈希表做rehash操作，也就是增加哈希桶，减少冲突。为了rehash更高效，Redis还默认使用了两个全局哈希表，一个用于当前使用，称为主哈希表，一个用于扩容，称为备用哈希表。

(8)在生成 RDB期间，Redis 可以同时处理写请求么？

可以的，Redis提供两个指令生成RDB，分别是save和bgsave。

• 如果是save指令，会阻塞，因为是主线程执行的。

• 如果是bgsave指令，是fork一个子进程来写入RDB文件的，快照持久化完全交给子进程来处理，父进程则可以继续处理客户端的请求。

(9)Redis底层，使用的什么协议?

RESP，英文全称是Redis Serialization Protocol,它是专门为redis设计的一套序列化协议. 这个协议其实在redis的1.2版本时就已经出现了,但是到了redis2.0才最终成为redis通讯协议的标准。

RESP主要有实现简单、解析速度快、可读性好等优点。

(10)布隆过滤器

应对缓存穿透问题，我们可以使用布隆过滤器。布隆过滤器是什么呢？

布隆过滤器是一种占用空间很小的数据结构，它由一个很长的二进制向量和一组Hash映射函数组成，它用于检索一个元素是否在一个集合中，空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。

布隆过滤器原理是？假设我们有个集合A，A中有n个元素。利用k个哈希散列函数，将A中的每个元素映射到一个长度为a位的数组B中的不同位置上，这些位置上的二进制数均设置为1。如果待检查的元素，经过这k个哈希散列函数的映射后，发现其k个位置上的二进制数全部为1，这个元素很可能属于集合A，反之，一定不属于集合A。

来看个简单例子吧，假设集合A有3个元素，分别为{d1,d2,d3}。有1个哈希函数，为Hash1。现在将A的每个元素映射到长度为16位数组B。

 

我们现在把d1映射过来，假设Hash1（d1）= 2，我们就把数组B中，下标为2的格子改成1，如下：

 

我们现在把d2也映射过来，假设Hash1（d2）= 5，我们把数组B中，下标为5的格子也改成1，如下：

 

接着我们把d3也映射过来，假设Hash1（d3）也等于 2，它也是把下标为2的格子标1：

 

因此，我们要确认一个元素dn是否在集合A里，我们只要算出Hash1（dn）得到的索引下标，只要是0，那就表示这个元素不在集合A，如果索引下标是1呢？那该元素可能是A中的某一个元素。因为你看，d1和d3得到的下标值，都可能是1，还可能是其他别的数映射的，布隆过滤器是存在这个缺点的：会存在hash碰撞导致的假阳性，判断存在误差。

如何减少这种误差呢？

• 搞多几个哈希函数映射，降低哈希碰撞的概率

• 同时增加B数组的bit长度，可以增大hash函数生成的数据的范围，也可以降低哈希碰撞的概率

我们又增加一个Hash2哈希映射函数，假设Hash2（d1）=6,Hash2（d3）=8,它俩不就不冲突了嘛，如下：

 

即使存在误差，我们可以发现，布隆过滤器并没有存放完整的数据，它只是运用一系列哈希映射函数计算出位置，然后填充二进制向量。如果数量很大的话，布隆过滤器通过极少的错误率，换取了存储空间的极大节省，还是挺划算的。

目前布隆过滤器已经有相应实现的开源类库啦，如Google的Guava类库，Twitter的 Algebird 类库，信手拈来即可，或者基于Redis自带的Bitmaps自行实现设计也是可以的。