九 Redis 罕用配置文件详解

可能正当的查看，以及了解批改配置文件，能帮忙咱们更好的应用 Redis，上面依照 Redis 配置文件的程序顺次往下讲

• 1k 和 1kb，1m 和 1mb、1g 和 1gb 的大小是有区别的，同时其对大小写不敏感

• include 相当于 import 的概念，能够引入，而后组合多个配置文件

• 网络配置如下（为了解决近程连贯问题，会正文掉 bind 127.0.0.1，以及将保护模式 protected-mode 改为 no）

  • bind 127.0.0.1 —— 绑定的 ip
  • protected-mode yes —— 保护模式
  • port 6379 —— 端口设置

• 以守护过程的形式运行，默认为 no，自行开启为 yes

• 后盾运行，须要指定 pid 文件

• 日志相干

  • loglevel 指定日志级别：debug，verbose，notice，warning，其中 notice 是生产环境
  • logfile —— 具体的日志名
  • database —— 数据库的数量，默认为 16
  • always-show-logo —— 是否总是显示 logo

• 长久化相干：因为 Redis 是基于内存的数据库，所以长久化就是将数据长久化到具体的文件中去

  • 有两种形式，RDB、AOF 上面咱们会具体的讲长久化的概念，这里简略提及
  • save 900 1：如果 900 s 内，如果至多有 1 个 key 被批改，则进行长久化操作，上面两个同理
  • stop-writes-on-bgsave-error：长久化出错，是否还要持续工作
  • rdbcompression：是否压缩 rdb 文件（会耗费 CPU）
  • rdbchecksum：保留 rdb 文件的时候，进行谬误的查看校阅
  • dir：rdb 文件保留的目录

• 主从复制会在上面专门解说，这里临时略过
• 接下来的 SECURITY 局部，正文中有提及到对于明码的设置，这里多提一下在客户端中设置明码的形式

127.0.0.1:6379> ping PONG 
127.0.0.1:6379> config get requirepass # 获取 redis 的明码 
1) "requirepass" 
2) ""127.0.0.1:6379> config set requirepass"123456" # 设置 redis 的明码 
OK
127.0.0.1:6379> config get requirepass # 发现所有的命令都没有权限
(error) NOAUTH Authentication required. 
127.0.0.1:6379> ping
(error) NOAUTH Authentication required. 

127.0.0.1:6379> auth 123456 # 应用明码进行登录
OK
127.0.0.1:6379> config get requirepass 
1) "requirepass" 
2) "123456"

• CLIENTS 客户端连贯局部，正文太多，这里不好截图，就简略说一说

  • maxclients —— 最大客户端数量
  • maxmemory —— 最大内存限度
  • maxmemory-policy noeviction —— 内存达到限度值的解决策略

  • redis 中的 默认 的过期策略是 volatile-lru，设置形式如下：

    • config set maxmemory-policy volatile-lru

maxmemory-policy 六种形式

• volatile-lru：只对设置了过期工夫的 key 进行 LRU（默认值）
• allkeys-lru：删除 lru 算法的 key
• volatile-random：随机删除行将过期 key
• allkeys-random：随机删除 volatile-ttl：删除行将过期的
• noeviction：永不过期，返回谬误

• APPEND ONLY 局部为长久化形式之一的 AOF 的配置形式，上面会细讲这两种长久化，所以这里也是提及一下即可

  • appendonly no —— 默认是不开启 AOF 模式的，默认是应用 RDB 形式长久化的，RDB 个别够用
  • appendfilename “appendonly.aof” —— 长久化文件的名字
  • appendfsync always —— 每次批改都会 sync（耗费性能）
  • appendfsync everysec —— 每秒执行一次 sync，可能会失落这 1s 的数据
  • appendfsync no —— 不执行 sync，操作系统本人同步数据，速度最快

十 Redis 长久化

后面曾经讲过，Redis 是一个内存数据库，也就是说，咱们的数据全副存储在内存中，而咱们常见的 MySQL 和 Oracle 等 SQL 数据库会将数据存储到硬盘中，凡事都是有利有弊，尽管内存数据库读写速度要比在硬盘中读写的数据库快的多，然而却呈现了一个很麻烦的问题，也就是说，当 Redis 服务器重启或者宕机后，内存中的数据会全副失落，为了解决这个问题，Redis 提供了一种长久化的技术，也就是将内存中的数据存储到硬盘中去，日后不便咱们应用这些文件复原数据库中的数据

在配置文件的解释中，提到了两种长久化形式 RDB、AOF，上面咱们具体来讲解一下：

(一) RDB 形式

(1) 概念

在指定工夫距离后，将内存中的数据集快照写入数据库，在复原时候，间接读取快照文件，进行数据的复原

简略了解：肯定的工夫内，检测 key 的变动状况，而后长久化数据

默认状况下，Redis 将数据库快照保留在名字为 dump.rdb 的二进制文件中。

文件名能够在配置文件中进行自定义，例如：dbfilename dump.rdb

(2) 工作原理

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来实现该操作（这也是保障了其极大性能的特点）

1. Redis 调用 forks，同时领有父过程和子过程。
2. 子过程将数据集写入到一个长期 RDB 文件中。
3. 当子过程实现对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作形式使得 Redis 能够从写时复制（copy-on-write）机制中获益（因为是应用子过程进行写操作，而父过程仍然能够接管来自客户端的申请。）

咱们晓得了一个过程如何采纳申请调页，仅调入包含第一条指令的页面，从而可能很 快开始执行。然而，通过零碎调用 fork() 的过程创立最后能够通过应用相似于页面共享的技术，绕过申请调页的须要。这种技术提供了疾速的过程创立，并最小化必须调配给新创建过程的新页面的数量。

回忆一下，零碎调用 fork() 创立了父过程的一个复制，以作为子过程。传统上，fork() 为子过程创立一个父过程地址空间的正本，复制属于父过程的页面。然而，思考到许多子过程在创立之后立刻调用零碎调用 exec()，父过程地址空间的复制可能没有必要。

因而，能够采纳一种称为写时复制的技术，它通过容许父过程和子过程最后共享雷同的页面来工作。这些共享页面标记为写时复制，这意味着如果任何一个过程写入共享页面，那么就创立共享页面的正本。

(3) 长久化触发条件

1. 满足 save 条件会主动触发 rdb 准则

   • 如：save 900 1：如果 900 s 内，如果至多有 1 个 key 被批改，则进行长久化操作

2. 执行 save / bgsave / flushall 命令，也会触发 rdb 准则

   • save：立刻对内存中的数据进行长久化，然而会阻塞，即不再承受其余任何操作，这是因为 save 命令为同步命令，会占用 Redis 主过程，若 Redis 数据十分多，阻塞工夫会十分长
   • bgsave：异步申请，长久化时，能够继续响应客户端申请，阻塞产生在 fock 阶段，通常很快，然而耗费内存
   • flushall：此命令也会触发长久化；
3. 退出 Redis，也会主动产生 rdb 文件（默认生成地位就是 redis 的启动目录）

(4) 复原 RDB 文件

只有将 rdb 文件，放在 Redis 的启动目录，Redis 会主动在这个目录下查看 dump.rdb 文件，而后复原其中的数据

查问配置文件中地位的命令

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

(5) 优缺点

长处：

1. 适宜大规模的数据恢复
2. 对数据的完整性要求不高

毛病：

1. 易失落最初一次操作，因为其须要肯定的工夫距离进行操作，如果 Redis 意外宕机了，这个最初一次批改的数据就没有了
2. fork 过程的时候，会占用肯定的内存空间

(二) AOF 形式

(1) 概念

以日志的模式来记录每个写的操作，将 Redis 执行过的所有指令记录下来（读操作不记录），只许追加文件但不能够改写文件，redis 启动之初会读取该文件从新构建数据，换言之，redis 重启的话就依据日志文件的内容将写指令从前到后执行一次以实现数据的复原工作。

如果你不深究其背地的操作，能够简略了解为：每一个操作执行后，进行长久化操作

想要应用 AOF 形式，须要被动关上，因为默认应用的是 RDB

在配置文件中，咱们找到这两行，能够设置 aof 的启动，以及其长久化文件的名字

• appendonly no：no 代表敞开 aof，改为 yes 代表开启
• appendfilename "appendonly.aof" —— 长久化文件的名字

这里能够批改其长久化的一个形式

• appendfsync always —— 每次批改都会 sync（耗费性能）
• appendfsync everysec —— 每秒执行一次 sync，可能会失落这 1s 的数据
• appendfsync no —— 不执行 sync，操作系统本人同步数据，速度最快

其默认是有限追加模式的，如果 aof 文件大于 64m，就 fork 一个新的过程来将咱们的文件进行重写

no-appendfsync-on-rewrite no
aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

(2) aof 文件错位的解决方案

如果这个 aof 文件有错位，这时候 redis 是启动不起来的

Redis 给咱们提供了一个工具 redis-check-aof --fix

# 命令示例
redis-check-aof --fix appendonly.aof

(3) 优缺点

长处

1. 文件的完整性会更加好，因为每一次批改都会同步
2. 若应用 appendfsync no 速度最快，效率最高

毛病

1. aof 文件大小远大于 rdb，修复速度因而比 rdb 慢
2. aof 运行效率也要比 rdb 慢，所以咱们 redis 默认的配置就是 rdb 长久化
3. 若应用每秒同步一次，可能会失落一秒的数据

(三) 扩大要点（来源于网络，侵删）

1. 如果你只心愿你的数据在服务器运行的时候存在，你也能够不应用任何长久化，即只当做缓存应用
2. 同时开启两种长久化形式

   在这种状况下，当 redis 重启的时候会优先载入 AOF 文件来复原原始的数据，因为在通常状况下 AOF

   文件保留的数据集要比 RDB 文件保留的数据集要残缺。

   RDB 的数据不实时，同时应用两者时服务器重启也只会找 AOF 文件，那要不要只应用 AOF 呢？作者

   倡议不要，因为 RDB 更适宜用于备份数据库（AOF 在一直变动不好备份），疾速重启，而且不会有

   AOF 可能潜在的 Bug，留着作为一个万一的伎俩。

3. 性能倡议

   因为 RDB 文件只用作后备用处，倡议只在 Slave 上长久化 RDB 文件，而且只有 15 分钟备份一次就够

   了，只保留 save 900 1 这条规定。

   如果 Enable AOF，益处是在最顽劣状况下也只会失落不超过两秒数据，启动脚本较简略只 load 自

   己的 AOF 文件就能够了，代价如下：

   • 一是带来了继续的 IO，
   • 二是 AOF rewrite 的最初将 rewrite 过程中产生的新数据写到新文件造成的阻塞简直是不可避免的。

因而只有硬盘许可，应该尽量减少 AOF rewrite 的频率，AOF 重写的根底大小默认值 64M 太小了，能够设到 5G 以上，默认超过原大小 100% 大小重写能够改到适当的数值。

如果不 Enable AOF，仅靠 Master-Slave Repllcation 实现高可用性也能够，能省掉一大笔 IO，也

缩小了 rewrite 时带来的零碎稳定。

• 代价是如果 Master/Slave 同时倒掉，会失落十几分钟的数据，启动脚本也要比拟两个 Master/Slave 中的 RDB 文件，载入较新的那个，微博就是这种架构。

十一 Redis 公布与订阅

(一) 概念

这部分，用的不是特地多，作为一个补充。上面是我在 菜鸟教程（runoob）贴过来的定义，重制了一下图

定义：Redis 公布订阅 (pub/sub) 是一种音讯通信模式：发送者 (pub) 发送音讯，订阅者 (sub) 接管音讯。

Redis 客户端能够订阅任意数量的频道。

下图展现了频道 channel1，以及订阅这个频道的三个客户端 —— client2、client5 和 client1 之间的关系：

当有新音讯通过 PUBLISH 命令发送给频道 channel1 时，这个音讯就会被发送给订阅它的三个客户端：

(二) 命令

• PSUBSCRIBE pattern [pattern..] —— 订阅一个或多个合乎给定模式的频道。
• PUNSUBSCRIBE pattern [pattern..] —— 退订一个或多个合乎给定模式的频道。
• PUBSUB subcommand [argument[argument]] —— 查看订阅与公布零碎状态。
• PUBLISH channel message —— 向指定频道公布音讯
• SUBSCRIBE channel [channel..] —— 订阅给定的一个或多个频道。
• SUBSCRIBE channel [channel..] —— 退订一个或多个频道

  演示

------------ 订阅端 ----------------------
127.0.0.1:6379> SUBSCRIBE ideal-20 # 订阅 ideal-20 频道
Reading messages... (press Ctrl-C to quit) # 期待接管音讯
1) "subscribe" # 订阅胜利的音讯
2) "ideal-20"
3) (integer) 1

1) "message" # 接管到来自 ideal-20 频道的音讯 "hello ideal"
2) "ideal-20"
3) "hello ideal"

1) "message" # 接管到来自 ideal-20 频道的音讯 "hello i am ideal-20"
2) "ideal-20"
3) "Hi,i am BWH_Steven"

-------------- 音讯公布端 -------------------
127.0.0.1:6379> PUBLISH ideal-20 "hello ideal" # 公布音讯到 ideal-20 频道
(integer) 1
127.0.0.1:6379> PUBLISH ideal-20 "Hi,i am BWH_Steven" # 公布音讯
(integer) 1

----------------- 查看沉闷的频道 ------------
127.0.0.1:6379> PUBSUB channels
1) "ideal-20"

(三) 原理简述

阐明：每个 Redis 服务器过程都维持着一个示意服务器状态的 redis.h/redisServer 构造，而构造的 pubsub_channels 属性是一个字典，这个字典就用于保留订阅频道的信息

• 其中，字典的 键为正在被订阅的频道 ，而字典的 值则是一个链表 ， 链表中保留了所有订阅这个频道的客户端

例子示意图：在下图展现的这个 pubsub_channels 示例中，client2、client5 和 client1 就订阅了 channel1（频道 1），其余 channel（频道）同理

有了这个构造上的概念，订阅以及公布的动作就很好了解了：

• 订阅：当客户端调用 SUBSCRIBE 命令执行订阅频道操作时，程序就会把一个个客户端（client）和要订阅的频道（channel）在 pubsub_channels 中关联起来
• 公布：程序首先依据 channel 定位到字典的键（例如找到 channel1），而后将信息发送给字典值链表中的所有客户端（例如 client2、client5、client1）。

(四) 毛病

1. 依赖于数据传输的可靠性，订阅方断线，会导致其失落在断线期间发布者公布的音讯
2. 客户端如果读取所订阅频道发来音讯的速度不够快，积压的音讯会使得 Redis 输入缓存区提及变得越来越大，轻则升高 Redis 速度，重则解体

(五) 利用

1. 多人在线聊天室
2. 音讯订阅，如公众号那种模式，然而理论大部分都用 MQ 来做（前面会写）

十二 Redis 主从复制

(一) 应用起因

首先，在一个我的项目中，应用一台 Redis 服务器必定是有问题的：

• 一台服务器解决所有申请，压力过大，且容易呈现故障，会导致整个相干服务呈现问题
• 一台服务器的内存是无限的，不可能将所有内存用作 Redis 存储（举荐不应该超过 20g）
• 大部分场景下，大部分都是读的操作，写的操作会绝对少一点，所以对读取的要求会大一些

而主从复制就能够将读写拆散，上面来一起理解一下

(二) 概念

主从复制，是指将一台 Redis 服务器的数据，复制到其余的 Redis 服务器

• 前者称为主节点（Master/Leader），后者称为从节点（Slave/Follower）
• 数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点以读为主）

简略了解一下就是：一台服务器作为主机器，其余服务器作为从机器，他们通过命令或配置进行了连贯，这样从机就能获取到主机的数据了，从机能够帮主机分担很多读的申请等等

(三) 作用

1. 数据冗余：主从复制实现了数据的热备份，是长久化之外的一种数据冗余的形式。
2. 故障复原：当主节点故障时，从节点能够临时代替主节点提供服务，是一种服务冗余的形式
3. 负载平衡：在主从复制的根底上，配合读写拆散，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，进步并发量。
4. 高可用基石：主从复制还是哨兵和集群可能施行的根底。

(四) 集群环境搭建（模仿）

失常的状况，应该是多台不同的服务器，为了演示不便，这里应用几个不同的端口来模仿不同的 Redis 服务器

首先，要应用不同的端口，天然须要多个不同的配置文件了，咱们先将原先的配置文件，复制三份（别离代表等会的一台主机和两台从机）

# 一段都是为了通知大家我的配置文件的目录，即 redis 启动目录上面的 myconfig 目录下
[root@centos7 ~]# cd /usr/local/bin 
[root@centos7 bin]# ls
appendonly.aof  dump.rdb  myconfig  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server  temp-2415.rdb
[root@centos7 bin]# cd myconfig/
[root@centos7 myconfig]# ls
redis.conf

# 复制三份，别离依照等会的端口号起名
[root@centos7 myconfig]# cp redis.conf redis6379.conf
[root@centos7 myconfig]# cp redis.conf redis6380.conf
[root@centos7 myconfig]# cp redis.conf redis6381.conf

# 这样三份就赋值好了
[root@centos7 myconfig]# ls
redis6379.conf  redis6380.conf  redis6381.conf  redis.conf

复制后，就须要别离通过 vim 批改每个配置文件的 port、daemonize、pid、logfile、dbfilename

例如：

port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile "6380.log"
dbfilename dump6380.rdb

在 XShell 中再关上两个窗口，而后别离运行不同端口号的 Redis

在第一个窗口运行 Redis 服务，应用 6379 这个配置文件

[root@centos7 bin]# redis-server myconfig/redis6379.conf

其余两个也是同理，别离启动 6380、6381

查看一下，三个端口的 Redis 都启动了

<div align=”center”>

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1b4bf5017e5d4e2781d83fe698f9a67c~tplv-k3u1fbpfcp-zoom-1.image)

</div>

(五) 一主二从

一主二从，就是代表一台主机，还有两台是从机，而 Redis 默认都是主机，也就是说，咱们下面模仿搭建进去的几台 Redis 服务器，当初还都是主机，而且相互之间并不存在什么关系

在客户端中通过 info replication 命令能够查看以后的一个信息

127.0.0.1:6379> info replication
# Replication
role:master # 以后是一个 master 主机
connected_slaves:0
master_replid:bfee90411a4ee99e80ace78ee587fdb7b564b4b4
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

阐明：以下演示中主机端口号为 6379，两台从机别离为 6380、6381

(1) 命令的形式（临时）

配置一主二从，只须要配置从机，应用 SLAVEOF 127.0.0.1 6379 即可

别离在 6380 和 6381 的窗口中执行

而后查问从机本身的信息，例如查问 6380 这台

127.0.0.1:6380> info replication
# Replication
role:slave # 以后身份变成了一台从机
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:364
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:bd7b9c5f3bb1287211b23a3f62e41f24e009b77e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:364
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:85
repl_backlog_histlen:280

同样在主机中查问，也能看到有两台从机曾经连贯

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=84,lag=0 # 第一台
slave1:ip=127.0.0.1,port=6380,state=online,offset=84,lag=0 # 第二台
master_replid:bd7b9c5f3bb1287211b23a3f62e41f24e009b77e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:84

(2) 批改配置文件的形式（永恒）

下面应用命令的形式，须要每一次重启等都须要执行命令，而将其写到配置文件中的时候，就能够每次依据配置主动加载了，首先批改从机配置文件中的 replicaof 前面追随主机的 ip 和 端口

如果主机的 Redis 设置了明码，别忘了在从机中的 masterauth 中加上主机的明码

(3) 规定阐明

1. 从机只能读，不能写，主机可读可写然而多用于写。

   • 从机执行写操作会报错 (error) READONLY You can’t write against a read only replica.

2. 主机断电 / 宕机后，默认角色不变，从机仍是从机，集群只是失去了写操作，期待主机复原，会从新回到原来的状态

   • 主机故障后，若须要一台从机作为主机，有两种形式可选

     • ① 从机手动执行命令 slaveof no one 使其成为主机
     • ② 应用哨兵模式主动选举（上面接着解说哨兵模式）
3. 从机断电 / 宕机后，若之前应用的是命令的形式称为从机，则启动后无奈获取主机，重新配置或者是应用配置文件的形式成为从机，重启后，能够从新获取到主机所有数据

(4) 复制原理

Slave（从机）启动胜利连贯到 Master（注解）后会发送一个 sync（同步命令）

Master 接到命令，启动后盾的存盘过程，同时收集所有接管到的用于批改数据集命令，在后盾过程执行，结束之后，master 将传送整个数据文件到 slave，并实现一次齐全同步。

全量复制：而 slave 服务在接管到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master 持续将新的所有收集到的批改命令顺次传给 slave，实现同步

然而只有是从新连贯 master，一次齐全同步（全量复制）将被主动执行，从机中就能看到所有数据

十三 哨兵模式

(一) 概念

在后面的主从复制的概念中，咱们晓得，一旦主服务器宕机，就须要应用手动的形式，将一台从服务器切换为主服务器，这种形式很麻烦，还有一种形式就是哨兵模式，也是一种比拟举荐的形式

定义：哨兵模式是一种非凡的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的过程，作为过程，它会独立运行。其原理是 哨兵通过发送命令，期待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

其作用如下：

• 通过发送命令，让 Redis 服务器返回监控包含主服务器和从服务器的运行状态，。
• 当哨兵监测到 master 宕机，会主动将 slave 切换成 master，而后通过 公布订阅模式 告诉其余的从服务器，批改配置文件，让它们切换主机。

单哨兵与多哨兵模式：

单哨兵模式：以独立的过程监控 3 台 Redis 服务器是否失常运行

多哨兵模式：除了监控 Redis 服务器，哨兵之间也会相互监控

(二) 配置以及启动

Redis 启动目录下的 redis-sentinel 就是咱们要启动的哨兵，然而咱们须要为其指定配置文件，这样哨兵太晓得要监控谁

我在我的 Redis 启动目录 /usr/local/bin/ 下的 myconfig 目录中，创立了一个名为 sentinel.conf 的配置文件

[root@centos7 bin]# vim myconfig/sentinel.conf

外面写入了其外围配置内容，即指定监控咱们本地 6379 端口的主机，前面的数字 1，代表主机宕机后，会应用投票算法机制抉择一台从机作为新的主机

# sentinel monitor 被监控的名称 host port 1 
sentinel monitor myredis 127.0.0.1 6379 1

接着咱们回到 Redis 启动目录，以方才那个配置文件启动哨兵

[root@centos7 bin]# redis-sentinel myconfig/sentinel.conf

启动胜利如下图：

一旦将主机断开连接，期待一下，哨兵监测到，就会发动投票（这里只有一个哨兵，所以是 100% 的），而后切换一台从机成为新的主机，而主机一旦从新上线后，也只能作为新主机的一台从机了

能够依据哨兵这边自动弹进去的日志看到，首先 6379 这台主机断开后，1 个哨兵认为其断开，而后上面的 switch 即抉择了新的 6380 作为新的主机，6379 从新上线后，只能作为 6380 的从机了

查看一下 6380 的信息，其果然曾经成为了主机

127.0.0.1:6380> info replication
# Replication
role:master # 主机
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=147896,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=147764,lag=0
master_replid:d32e400babb8bfdabfd8ea1d3fc559f714ef0d5a
master_replid2:bd7b9c5f3bb1287211b23a3f62e41f24e009b77e
master_repl_offset:147896
second_repl_offset:7221
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:85
repl_backlog_histlen:147812

(三) 残缺配置文件

实际上最外围的也就是咱们方才演示中的那一句即上面的：sentinel monitor mymaster 127.0.0.1 6379 1

还有端口批改会用到，其余的能够依据状况设置

其配置文件还是比较复杂的

# Example sentinel.conf
 
# 哨兵 sentinel 实例运行的端口 默认 26379
port 26379
 
# 哨兵 sentinel 的工作目录
dir /tmp
 
# 哨兵 sentinel 监控的 redis 主节点的 ip port 
# master-name  能够本人命名的主节点名字 只能由字母 A -z、数字 0 -9、这三个字符 ".-_" 组成。# quorum 当这些 quorum 个数 sentinel 哨兵认为 master 主节点失联 那么这时 主观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
 
# 当在 Redis 实例中开启了 requirepass foobared 受权明码 这样所有连贯 Redis 实例的客户端都要提供明码
# 设置哨兵 sentinel 连贯主从的明码 留神必须为主从设置一样的验证明码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵 sentinel 此时 哨兵主观上认为主节点下线 默认 30 秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在产生 failover 主备切换时最多能够有多少个 slave 同时对新的 master 进行 同步，这个数字越小，实现 failover 所需的工夫就越长，然而如果这个数字越大，就意味着越 多的 slave 因为 replication 而不可用。能够通过将这个值设为 1 来保障每次只有一个 slave 处于不能解决命令申请的状态。# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时工夫 failover-timeout 能够用在以下这些方面：#1. 同一个 sentinel 对同一个 master 两次 failover 之间的间隔时间。#2. 当一个 slave 从一个谬误的 master 那里同步数据开始计算工夫。直到 slave 被纠正为向正确的 master 那里同步数据时。#3. 当想要勾销一个正在进行的 failover 所须要的工夫。#4. 当进行 failover 时，配置所有 slaves 指向新的 master 所需的最大工夫。不过，即便过了这个超时，slaves 仍然会被正确配置为指向 master，然而就不按 parallel-syncs 所配置的规定来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件产生时所须要执行的脚本，能够通过脚本来告诉管理员，例如当零碎运行不失常时发邮件告诉相干人员。#对于脚本的运行后果有以下规定：#若脚本执行后返回 1，那么该脚本稍后将会被再次执行，反复次数目前默认为 10
#若脚本执行后返回 2，或者比 2 更高的一个返回值，脚本将不会反复执行。#如果脚本在执行过程中因为收到零碎中断信号被终止了，则同返回值为 1 时的行为雷同。#一个脚本的最大执行工夫为 60s，如果超过这个工夫，脚本将会被一个 SIGKILL 信号终止，之后从新执行。#告诉型脚本: 当 sentinel 有任何正告级别的事件产生时（比如说 redis 实例的主观生效和主观生效等等），将会去调用这个脚本，#这时这个脚本应该通过邮件，SMS 等形式去告诉系统管理员对于零碎不失常运行的信息。调用该脚本时，将传给脚本两个参数，#一个是事件的类型，#一个是事件的形容。#如果 sentinel.conf 配置文件中配置了这个脚本门路，那么必须保障这个脚本存在于这个门路，并且是可执行的，否则 sentinel 无奈失常启动胜利。#告诉脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个 master 因为 failover 而产生扭转时，这个脚本将会被调用，告诉相干的客户端对于 master 地址曾经产生扭转的信息。# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前 <state> 总是“failover”,
# <role> 是“leader”或者“observer”中的一个。# 参数 from-ip, from-port, to-ip, to-port 是用来和旧的 master 和新的 master(即旧的 slave)通信的
# 这个脚本应该是通用的，能被屡次调用，不是针对性的。# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

十四 Redis 缓存穿透、击穿、和雪崩

此局部为一个补充知识点，本文重点还是 Redis 的一个根本入门，而上面的这些知识点，更多的是在具体场景中产生的一些问题，而且其每一个内容开展讲都是非常复杂的，所以这里只做一个基本概念的介绍，不做具体阐明

(一) 缓存穿透

用户查问数据，首先在 Redis 缓存中去查，如果没有，也就是缓存没有命中，就会去长久层数据库，例如 MySQL 中去查。

缓存穿透：大量缓存未命中的状况下，大量申请长久层数据库，长久层数据库承载很大的压力，呈现问题。

常见解决方案有两种：

• 布隆过滤器
• 缓存空对象

① 布隆过滤器：

对所有可能查问的参数以 Hash 的模式存储，以便疾速确定是否存在这个值，在管制层先进行拦挡校验，校验不通过间接打回，加重了存储系统的压力。

② 缓存空对象：

次申请若在缓存和数据库中都没找到，就在缓存中方一个空对象用于解决后续这个申请

不过此办法存在两种问题：

• 空值也能被缓存的话，就会须要更多的空间来存储更多的空值
• 即便对空值设置了过期工夫，还是会存在缓存层和存储层的数据会有一段时间窗口的不统一，这对于须要放弃一致性的业务会有影响

(二) 缓存击穿

定义：缓存击穿，是指一个 key 十分热点，在不停的扛着大并发，大并发集中对这一个点进行拜访，当这个 key 在生效的霎时，继续的大并发就穿破缓存，间接申请数据库，就像在一个屏障上凿开了一个洞

解决方案：

1. 设置热点数据永不过期

   这样就不会呈现热点数据过期的状况，然而当 Redis 内存空间满的时候也会清理局部数据，而且此种计划会占用空间，一旦热点数据多了起来，就会占用局部空间。

2. 加互斥锁(分布式锁)

   在拜访 key 之前，采纳 SETNX（set if not exists）来设置另一个短期 key 来锁住以后 key 的拜访，拜访完结再删除该短期 key。保障同时刻只有一个线程拜访。这样对锁的要求就非常高。

(三) 缓存雪崩

大量的 key 设置了雷同的过期工夫，导致在缓存在同一时刻全副生效，造成刹时 DB 申请量大、压力骤增，引起雪崩。

解决方案：

① redis 高可用

• 这个思维的含意是，既然 redis 有可能挂掉，那我多增设几台 redis，这样一台挂掉之后其余的还能够持续工作，其实就是搭建的集群

② 限流降级

• 这个解决方案的思维是，在缓存生效后，通过加锁或者队列来管制读数据库写缓存的线程数量。比方对某个 key 只容许一个线程查问数据和写缓存，其余线程期待

③ 数据预热

• 数据加热的含意就是在正式部署之前，我先把可能的数据先事后拜访一遍，这样局部可能大量拜访的数据就会加载到缓存中。在行将产生大并发拜访前手动触发加载缓存不同的 key，设置不同的过期工夫，让缓存生效的工夫点尽量平均