Redis持久化

基本内容

Redis是基于内存的NoSQL数据库，所以它的读写速度很快，但存储在内存中的Redis数据会在服务器重启后丢失。
在一些场景里需要长久地保存数据，所以需要把内存中的Redis数据持久化地保存在硬盘中。
Redis提供了两种持久化的方式，分别是AOF（Append Only File，只追加文件，记录写命令）和RDB（Redis DataBase 内存快照，基于Redis数据库）

AOF（相对复杂）

流程

默认是不打开的，想要用就必须通过配置文件进行开启

AOF持久化打开后，每当发生写命令，该命令就会被记录到AOF缓冲区。
AOF缓冲区会根据事先配置的策略定期与硬盘文件进行同步操作。
当AOF文件大到一定程度后该文件会被重写，即在不影响持久化结果的前提下进行压缩。
当Redis服务器重启时，会加载硬盘上的AOF日志文件，以实现数据恢复的效果。

AOF故障恢复

当Redis因发生故障而重启时，Redis服务器会按照如下步骤根据AOF日志文件恢复数据。所谓伪客户端就是一个看不见的客户端在替你执行操作，一条一条从文件中拿写命令进行数据恢复。
具体流程：

• 创建一个伪客户端（fake client）。之所以叫伪客户端，是因为该客户端在本地，不带任何网络连接，但该伪客户端执行命令的效果和真实的带网络的客户端没有任何差别。
• 该伪客户端从AOF日志文件里依次读取一条写命令并执行，直到完成所有写命令。
  执行完上述步骤后，其实就达到了“根据AOF日志文件恢复Redis现场”的持久化效果。

AOF配置文件策略

配置文件相关参数：

• appendonly参数取值为always时，每次发生Redis的写命令时都会触发持久化动作，可能会影响到Redis乃至Redis所在服务器的性能（很影响性能，每次都同步）。
• appendonly参数取值为everysec时，会以一秒的频率触发持久化动作，在这种方式下能很好地平衡持久化需求和性能间的关系，一般情况下取这个值。
• appendonly参数取值为no时，会由操作系统来决定持久化的频率，这种方式对其他另外两种而言性能最好，但可能每次持久化操作间的间隔有些长，这样当故障发生时可能会丢失较多的数据，因为缓冲区的数据没来得及去持久化。
• 通过dir和appendfilename这两个参数能设置持久化文件所在的路径和文件名，而持久化文件的默认文件名是appendonly.aof。

AOF文件重写

随着持久化的不断增多，AOF文件会越来越大，这个时候就需要AOF文件重写了。即：Redis能创建新的AOF文件来替代现有的，在数据恢复时，这两个文件的效果是相同的，但新文件不会包含冗余命令，所以文件大小会比原来的小，可以通过如下三个参数来定义重写时的策略。

• 通过no-appendfsync-on-rewrite参数来平衡性能和安全性：如果该参数取值为yes，那么在重写AOF文件时能提升性能，但可能在重写AOF文件时丢失数据；如果取值为no，则不会丢失数据，但较取值为yes的性能可能会降低。默认取值是no。
• 通过auto-aof-rewrite-percentage参数能指定重写的条件，默认是100，即如果当前的AOF文件比上次执行重写时的文件大一倍时会再次触发重写操作。如果该参数取值为0，则不会触发重写操作。
• 通过auto-aof-rewrite-min-size参数可以指定触发重写时AOF文件的大小，默认是64MB。
  注意：上面两个 auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数指定的重写条件是“And”的关系，即只有当同时满足这两个条件时才会触发重写操作。
  也可以通过bgrewriteaof命令来手动触发针对AOF持久化文件的重写操作。
  具体AOF持久化实战可以参考这篇文章
  持久化实战

RDB（相对简单，默认持久化方式）

RDB是默认的存储方式 在默认配置中，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。

当然，具体怎么持久化，什么时候持久化都是由用户自行设定的

具体RDB持久化实战可以参考这篇文章
持久化实战

Docker管理Redis

Docker基本操作

关于docker的入门这里就不多赘述了，所以我准备了一篇文章，可以在这里找到Docker的相关知识。
Docker入门知识

实操

使用docker安装redis

用docker pull下载最新Redis镜像，也可以用“docker pull redis:标签”命令下载指定版本的Redis，如果不指定，就会用默认的标签latest去下载最新版本的Redis镜像

docker pull redis

docker images，表示已经成功下载了最新版本的Redis镜像。

可以看到最新的Redis已经拉下来了

运行Redis容器

随后可以用如下的run命令来运行Redis容器：
映射端口的时候本机端口在前，docker端口在后，即 -p 本机端口:docker端口

docker run -itd --name redis-6378 -p 6378:6379 redis:latest

这里的-it表示在终端交互式操作，d表示在后台运行；通过–name指定该容器的名字；通过-p参数指定容器的6378端口映射到宿主机（即运行Docker的机器）6379端口，这样在容器外部就能以宿主机ip:6378的方式访问Redis服务；最后的redis:latest参数指定根据该镜像启动容器

运行完上述run命令后再执行docker ps命令：

从中可以看到，名为redis-6378 的容器处于Up状态，并且是通过6378端口对外提供服务。
外界连接测试一下

查看启动日志

如果直接在Linux等环境上启动Redis服务器，就能直接看到启动后的效果。这里由于是通过Docker容器启动Redis服务器，因此在用docker run命令启动Redis容器后，可以通过如下的docker log命令来观察启动的效果：

docker logs redis-6378

上述docker logs命令用来输出容器启动时的日志，redis-6378 则表示待查看日志的容器名。如果Docker容器中的Redis服务被正确启动，就能看到如图的效果。

由于配置等问题导致Redis服务无法正确启动时，可以用docker logs观察启动时的日志，从而分析启动不成功的原因。

进入Redis容器

以交互模式进入容器
通过run命令能在后台启动Redis容器，此时可以通过如下的exec命令进入Redis容器，进而执行Redis的相关操作：

docker exec -it redis-6378 /bin/bash

docker exec表示在运行的容器中执行命令，其中redis-6378 参数表示在哪个容器里执行命令，-it表示以终端交互的方式执行命令，/bin/bash表示需要指定的命令。

执行上述exec命令后，就能看到如图所示的效果，说明已经进入了名为redis-6378 的容器

可以通过输入redis-cli命令连接该容器里的Redis服务器，随后可以通过set val 1命令创建一个值为1的val变量，创建后再通过get val来获取val变量的值:

当然也可以通过其他客户端工具访问。只要能成功地运行Redis相关命令并看到对应的结果，就说明基于Docker的Redis开发环境已经成功地安装到本机里。

退出Redis容器

随后如果要退到Windows命令行，就需要连续两次输入exit，其中第一个exit命令能退出用redis-cli进入的Redis运行窗口，第二个命令能退出因docker exec命令而进入的Redis容器，具体的效果如图。

由于本书所介绍的Redis的开发和运行环境是基于Docker的，当Redis容器启动后，在修改容器配置等操作后可能需要重启容器，并且在一些场景里还需要停止并删除过期的Redis容器，因此在这里将给出相关的操作步骤。

运行docker ps，发现名为redis-6378 的Redis容器处于Up（运行中）状态时，可以通过docker stop redis-6378 命令停止该容器，其中redis-test1是待停止的容器名。

docker stop redis-6378 

注意，这里停止的是容器，而不是Redis服务，运行后再运行docker ps命令将无法看到之前的Redis镜像，因为该命令只返回处于Up状态的容器，此时用docker ps -a命令查看所有容器才能看到如图1.14所示的效果，显示myFirstRedis容器已经处于Exited（退出）状态。

docker ps -a

要再启动该容器，可以用docker start redis-6378或docker restart redis-6378命令（这两个命令的参数都是待启动的容器名）。这两个命令的差别是，docker start会挂载容器所关联的文件系统，而docker restart不会。

也就是说，如果更改了Redis启动时需要加载的配置项参数，那么在重启时建议先运行docker stop命令再运行docker start命令。如果直接通过docker restart命令来重启，就未必会加载更改后的配置项参数了。

当Redis容器里的配置项参数或版本过于老旧时，可以通过docker rm命令删除该容器，具体语法是“docker rm 容器名”，但在删除前要先确保该容器处于Exited状态，否则删除时会出错。

比如删除名为myFirstRedis的Redis容器，首先要用docker stop myFirstRedis命令确保该容器处于Exited状态，随后用docker rm myFirstRedis命令删除，删除完成后再运行docker ps -a命令查看所有状态的容器，就无法再看到该容器了。

当通过docker run -itd --name myFirstRedis -p 6379:6379 redis:latest和docker start myFirstRedis这两个命令启动Redis容器后，包含在容器里的Redis服务器会自动启动。如果要停止Redis服务器的运行，可以直接用exit命令退出容器，或者在redis-cli的命令行里输入shutdown命令

启动时加载配置文件

通过docker命令，用Redis的镜像创建容器

docker run -itd --name redis2 -v /opt/server/redis-6.2.7/redis.conf:/redisConfig/redis.conf -p 6379:6378 redis:latest redis-server /redisConfig/redis.conf

通过–name的方式指定该容器的名字为redis-config-demo，
用-v指定本机和Docker虚拟机内目录和文件的映射关系，
具体是把/opt/server/redis-6.2.7/redis.conf映射成Docker虚拟机里的redisConfig/redis.conf文件，用-p参数来指定Docker虚拟机的6379端口映射到本机的6378端口上，以redis:latest的方式指定本容器的镜像为最新版本的Redis镜像。

再用redis-server /redisConfig/redis.conf的方式指定启动redisWithConfig镜像时需要运行的命令是redis-server /redisConfig/redis.conf，即用redis-server命令启动Redis服务器时需要装载对应的redis.conf文件。

创建文件先 mkdir 文件夹目录  再touch 刚刚的目录/文件名

注意事项：

• redis.conf的daemonize表示是是否以守护进程执行

• docker run命令里边有一个参数 -d这个参数也是以守护进程执行

• 为了防止冲突要修改 redis.conf 配置文件把daemonize修改为no
  

总结

（1）在安装完Docker软件后，可以在命令行里输入docker pull redis命令去下载最新的Redis镜像，下载完成后能通过docker images命令来确认镜像。

（2）可以用docker run -itd --name myFirstRedis -p 6379:6379 redis:latest命令根据下载的redis:latest镜像创建名为myFirstRedis的容器。创建完成后，可以通过docker ps -a命令来查看对应的容器。

（3）如果创建前已经有名为myFirstRedis的容器，那么再创建同名的容器会出现问题，这时可以先用docker stop myFirstRedis命令确保该容器处于Exited状态，并通过docker rm myFirstRedis命令删除该容器。

（4）如果通过docker ps -a命令发现myFirstRedis容器当前处于Exited状态，那么可以用docker start myFirstRedis命令来启动它。

（5）在创建并启动myFirstRedis容器后，可以通过docker logs myFirstRedis命令查看该容器里Redis服务器的启动情况，也可以通过docker exec -it myFirstRedis /bin/bash命令进入myFirstRedis容器，随后可以通过redis-cli命令创建一个连接到Redis服务器的客户端，并通过该客户端输入各种Redis命令。

（6）如果需要重新启动myFirstRedis容器，可以先通过docker stop myFirstRedis命令停止该容器，再通过docker start myFirstRedis命令启动它。

（7）如果要停止Redis服务器，那么可以先通过redis-cli命令连接到服务器，再输入shutdown命令，或者在myFirstRedis容器的命令行里直接输入exit命令。

Redis集群-主从复制

在实际项目里，一般不会简单地只在一台服务器上部署Redis服务器，因为单台Redis服务器不能满足高并发的压力，另外如果该服务器或Redis服务器失效，整个系统就可能崩溃。
项目里一般会用主从复制的模式来提升性能，用集群模式来提升吞吐量并提升可用性。
本节将使用Docker容器来模拟服务器，用启动多个Docker容器的方法来模拟“在多个服务器上安装Redis”的效果

基于主从复制模式的集群

主从复制思路

在主从复制模式的集群里，主节点一般是一个，从节点一般是两个或多个，写入主节点的数据会被复制到从节点上，这样一旦主节点出现故障，应用系统就能切换到从节点去读写数据，提升系统的可用性。容灾性更好。

再采用主从复制模式里默认的读写分离机制，就能提升系统的缓存读写性能。
在实际应用中，如果有相应的设置，在向一台Redis服务器里写数据后，这个数据可以同步到另外一台（或多台）Redis服务器，这里数据源服务器叫主服务器（Master Server），复制数据目的地所在的服务器叫从服务器（Slave Server）。

主从复制的优势

可以把写操作集中到主服务器上，把读操作集中到从服务器上，以提升读写性能；
由于出现了数据备份，因此能提升数据的安全性，比如当主Redis服务器失效后，能很快切换到从服务器上读数据。

实操-通过命令配置

主写从读架构

打开一个命令窗口，在其中运行如下命令创建一个名为redis-master的Redis容器。注意，它的端口是6360。

docker run -itd --name redis-master -p 6360:6360redis:latest

新开一个命令窗口，在其中运行如下命令创建一个名为redis-slave1的容器。注意，它的端口是6380。这里是在一台电脑上运行，所以用端口号来区别一台主Redis容器和另外两台从Redis容器。在真实项目里，多台Redis会部署在不同的服务器上，所以可以都用6379端口。

在docker中以不同的端口号启动相应的Redis服务

在redis-master容器的命令窗口里，运行docker exec -it redis-master /bin/bash命令，进入命令行窗口

docker exec -it redis-master /bin/bash

主机视角

在其中用redis-cli命令进入Redis客户端命令行

通过info replication命令查看当前的主从模式状态，能看到如下所示的部分结果。

info replication

回到包含redis-master容器的命令窗口，在其中运行docker inspect redis-master命令，查看redis-master容器的信息

docker inspect redis-master | grep IPAddress

在其中能通过IPAddress项看到该容器的IP地址，这里是172.17.0.2。在真实项目里，Redis服务器所在的IP地址是固定的，而通过Docker容器启动的Redis服务器的IP地址是动态的，所以这里要用上述命令来获取IP地址。
注意这个IP：172.17.0.2，一会配置从机的时候有很大用处。

从机视角

再开一个命令窗口，进入从机
再到redis-slave1容器的命令窗口里，通过docker exec -it redis-slave1/bin/bash命令进入容器的命令行窗口

docker exec -it redis-slave1 /bin/bash

通过redis-cli命令进入客户端命令行，然后通过info replication命令查看该Redis从服务器的主从模式状态，部分结果如下所示。
因为还没有把这台机器配置成从机，所以这里的角色仍然是主机，在配置完成后，就可以变成主机了。

现在要配置从机了
在从机的客户端里输入：slaveof 172.17.0.2 主机端口号
表示把从节点连接到主机上
再次运行配置信息，可以发现身份已经转变

同样的，一号从机这么操作，那么二号从机就也可以这么操作。就是把刚刚的操作再复刻一遍。

主机测试

回到主机页面，进入主机客户端查看消息
连接完成后，回到redis-master容器所在的命令行窗口，运行info replication命令，此时能看到如下的部分输出，从第4行的输出里能看到当前的主服务器连接着两台从服务器。

至此，配置完成一主二从模式的主从模式。

此时到两台从服务器里运行get name命令，返回是空；

到redis-master容器所在的命令行窗口运行set name Peter后，再到两台从服务器里运行get name命令，就能看到返回值。

这说明主从模式配置成功，主服务器里的数据会自动同步到各从服务器上。

实操-通过配置文件配置

在项目里除了可以用slaveof命令搭建主从模式的集群外，还可以用配置参数的方式来搭建，具体的步骤如下。

搭建主服务器redis-master的命令不变，并且还是用6379端口。

docker run -itd --name redis-master -p 6370:6370 redis:latest

用docker inspect redis-master命令确认该Redis服务器所在容器的IP地址依然是172.17.0.2。

在/opt/server下编写配置文件redisSlave1.conf，并在其中编写如下内容。

port 6380
slaveof 172.17.0.2 6370

通过第1行的命令设置该Redis的端口为6380，通过第2行的slaveof配置把该Redis服务器设置成“从模式”，并连接到redis-master所在的主服务器上。

在新的命令窗口里运行如下的命令，创建名为redis-slave1的Redis服务器。该服务器的工作端口是6380，并且用redis-server后的参数指定在启动Redis服务器时加载redisSlave1.conf配置文件。
把/opt/server/redisSlave1.conf的配置文件映射到docker中的/redisConfig/redisSlave1.conf 上

docker run -itd --name redis-slave1 -v /opt/server/redisSlave1.conf:/redisConfig/redisSlave1.conf -p 6380:6380 redis:latest redis-server /redisConfig/redisSlave1.conf

注意，这个命令中，两个文件路径的位置是进行双向映射绑定的，Linux的文件映射到Docker中的某一个虚拟路径上，无论修改哪一个，对方都会跟着更改

随后通过docker exec -it redis-slave1 /bin/bash命令进入到该容器的命令行

docker exec -it redis-slave1 /bin/bash

由于Redis工作端口已经变成6380（配置文件中指定了端口），所以需要通过redis-cli -h 127.0.0.1 -p 6380命令进入Redis客户端。在其中运行info replication命令来查看连接情况

以同样的方式创建redis-slave2，将端口绑定到6370，绑定到对应主机即可

实操-配置读写分离效果

在上文里配置的redis-slave1和redis-slave2这两台从服务器里运行info replication命令，还能看到“slave_read_only:1”这项配置，说明从服务器默认是“只读”的。

到redis-slave1的Redis客户端命令行里输入set val 1，就会看到如下面第2行所示的错误，从而能进一步验证该Redis服务器的“只读”属性。

对于Redis从服务器而言，建议采用默认的“只读”配置，因为在项目里一般不会向作为数据同步目的地的“从服务器”上写数据。如果业务上确实需要，可以通过如下步骤设置“可读可写”的效果。

在上文提到的redisSlave2.conf配置文件里再加入一行“slave-read-only no”的配置，指定该服务器可读可写。

如果上文提到的redis-slave2容器还处于活动状态，则需要先用docker stop redis-slave2停止该容器，再用docker rm redis-slave2命令删除该容器，之后可以用如下命令再次创建redis-slave2容器。

实操-用心跳机制提高主从复制的可靠性

在Redis主从复制模式里，如果主从服务器之间有数据同步的情况，那么从服务器会默认以一秒一次的频率向主服务器发送REPLCONF ACK命令，依次来确保两者间连接通畅。这种定时交互命令确保连接的机制就叫“心跳”机制。

在上文开启的redis-master这个主服务器的命令行里，运行info replication命令，就能看到它从属服务器的“心跳”状况。

info replication

通过lag表示该从属服务器发送REPLCONF ACK命令的时间，这里均是1秒，表示两台从服务器和主服务器的连接均属通畅。

这里大家可以想象一下，如果从服务器宕机，那么主从复制就没有意义了。对此，可以通过如下的步骤来关联心跳机制和主动复制的动作。

在/usr/server下新建redisMaster.conf文件，在其中编写如下的代码。

min-slaves-to-write 2
min-slaves-max-lag 15

第1行的参数表示实现主从复制的从服务器个数最少是2台，第2行的参数表示如果由第1行参数指定的从服务器个数（这里是2台）的心跳延迟时间（lag值）大于15秒，就不执行主从复制。

这两个条件是“或者”的关系，即只要出现从服务器个数小于2，或者2台从服务器的心跳延迟时间大于15秒，主服务器即停止主从复制的操作。

需要重新启动主服务器容器，加载配置文件

在上文开启的redis-master主服务器的命令行里，运行info replication命令，能看到表示复制数据偏移量的master_repl_offset数据，

这里的数据是1614，表示主服务器向从服务器发送数据的字节数。

同样，到redis-slave1从服务器的命令行里也能通过info replication查看该偏移量。

在从服务器里，该数据表示从主服务器中接收到的数据字节数，如果主从服务器中两者的数据一致，就说明主从服务器间的数据是同步的。

如果出现Redis问题，可以通过master_repl_offset数值来检查同步数据是否正确，由此再进一步排查问题。

主从模式存在的问题

主从复制模式的集群里，当主服务器发生故障后，需要手动进行数据恢复动作，比如让应用程序连到从服务器上，同时需要重新设置主从关系。
也就是说，基于主从复制模式的集群在发生故障时可能会出现数据丢失的情况，对此可以在主从模式的基础上再引入“哨兵（Sentinel）”机制。
一方面用哨兵进程监控主从服务器是否可用，另一方面当主服务器故障发生时通过哨兵机制可以实现“故障自动恢复”的效果。

Redis集群-哨兵模式

一般哨兵模式都是与主从复制联合使用的，哨兵模式就是怕主Redis挂掉了之后没有别的Redis顶上去
在基于哨兵的模式里会在一台或多台服务器上引入哨兵进程，这些节点也叫哨兵节点。
哨兵节点一般不存储数据，它的作用是监控主从模式里的主服务器节点。当哨兵节点监控的主服务器发生故障时，哨兵节点会主导“故障自动恢复”的流程哨兵节点会在该主服务器下属的从服务器里选出一个新的主服务器（也就是所谓的选举机制），并完成相应的数据和配置更改等动作。

如果采用这种模式，可以让故障自动修复，从而提升系统的可用性。

哨兵模式架构图

实操-哨兵模式搭建

按1.2节所给出的方法搭建一个一主二从的Redis集群，其中redis-master是主服务器，redis-slave1和redis-slave2是从服务器。
以上面的为基础，搭建一个哨兵来做服务的监控
如图就是6379相对应的

创建哨兵配置文件

在/opt/server目录里创建sentinel1.conf配置文件，该配置文件会在启动哨兵节点时被读取，代码如下：

port 16379
sentinel monitor master 172.17.0.2 6379 2
logfile "sentinel1.log"

通过port指定了哨兵节点的工作端口是16379，
在第2行指定了监控对象，master是哨兵节点为所监控服务器指定的名字，172.17.0.3和6379分别是redis-master这台主服务器的IP地址和端口号，
而最后的2表示至少需要有2台哨兵节点认可才能认定该主服务器失效。
在第3行里定义了该哨兵节点的日志文件名。

完成编写上述配置文件后，新开一个命令窗口，在其中运行如下的命令，新启一个名为redis-sentinel1的Docker容器，并在其中启动哨兵（sentinel）节点。
设置文件权限

chmod -R 777 /opt/server  

按配置文件启动哨兵，本质上还是启动一个Redis，前半段是启动Docker，后半段redis-server之后就是让Redis去读哨兵配置文件启动服务

docker run -itd --name redis-sentinel1 -v /opt/server:/redisConfig:z -p 16379:16379 redis:latest redis-server /redisConfig/sentinel1.conf --sentinel

这里通过-v挂载了/opt/server/目录，同时用-p参数指定了Docker容器16379端口映射到本机16379端口。这里用redis-sentinel命令启动了哨兵节点，启动时加载了sentinel1.conf配置文件。

到这就算配置好了，剩下的进入容器再看就行

通过上述命令启动一个哨兵节点后，可以通过docker exec -it redis-sentinel1 /bin/bash命令进入Docker容器里的命令行

然后用redis-cli -h 127.0.0.1 -p 16379命令进入Redis客户端。

在Redis客户端里，再通过info sentinel命令查看哨兵节点的信息，该命令的具体输出如下所示。

info sentinel

该哨兵节点监控的主服务器状态（status）是ok，slaves数量是2，即该主服务器有两个从服务器，这和之前的配置情况是一致的。

配置第二台哨兵

创建sentinel2.conf配置文件，其中的代码如下。

还是在opt/server下创建

port 16380
sentinel monitor master 172.17.0.2 6379 2
logfile "sentinel2.log"

同样也为这个文件赋予读取权限

chmod 777 /opt/server/sentinel2.conf

该配置文件和哨兵节点redis-sentinel1所用到的很相似，只不过是把端口改为16380，同时更改了日志文件名。

随后开启一个命令窗口，在其中通过如下命令再创建一个哨兵节点

docker run -itd --name redis-sentinel2 -v /opt/server:/redisConfig:z -p 16380:16380 redis:latest redis-server /redisConfig/sentinel2.conf --sentinel

随后用docker exec -it redis-sentinel2 /bin/bash命令进入该哨兵节点的命令行
通过redis-cli -h 127.0.0.1 -p 16380命令进入Redis客户端
最后info sentinel查看哨兵机器状态

该哨兵节点正在监控172.17.0.3:6379指向的主服务器，再观察sentinels的值是2，表示172.17.0.3:6379指向的主服务器（redis-master主服务器）被两台哨兵节点监控。

至此，完成了哨兵模式集群的搭建工作，该集群的架构如图所示，具体说明如下：两个哨兵节点同时监控redis-master这台主Redis服务器。主服务器和从服务器之间依然存在着“数据同步”的复制模式。这里哨兵节点只监控着一个“一主二从”的集群。在实际项目里，可以通过配置让哨兵节点监控多个集群。
如果这个期间主节点挂掉了，那么哨兵会选举出一个从节点作为主节点顶上去
架构图

哨兵其他配置

这个配置主要是判断主节点掉线多久才重新选举

在上文里，通过sentinel monitor master 172.17.0.3 6379 2配置参数来设置该节点所监控的主机，此外还可以通过sentinel down-after-milliseconds参数来指定判断下线时间的阈值，下面给出一个具体的用法。

sentinel down-after-milliseconds master 60000

其中，master表示该哨兵节点监控的服务器名，需要和sentinel monitor配置项里指定的服务器名保持一致，而60000表示时间，单位是毫秒。

也就是说，如果在60秒里该哨兵节点没有收到master服务器的正确响应，就会认为该服务器已经下线失效。

之前配置了“sentinel monitor master 172.17.0.3 6379 2”参数，所以只有当2个哨兵节点都通过“sentinel down-after-milliseconds”判断该服务器失效时才会认定该服务器失效，从而启动故障恢复机制。

此外，还可以通过如下配置来设置“故障恢复的时效”，该时效参数的单位是毫秒，这里的含义是，在进行故障恢复时，如果在180秒里还没有完成主从服务器的切换动作，就会认定本次恢复动作失败。

sentinel failover-timeout master 180000

哨兵模式下修复重连

如果我主节点挂掉了，从节点顶上来了，总有一天我主节点是要修复好重新上线的，那么重新连接之后，这个节点的身份是什么样的？是从节点

到redis-master所在的命令行窗口用docker start redis-master命令启动服务器，以此来模拟该服务器排除故障后的效果。

docker start redis-master

运行完命令后，再到redis-slave1所在的命令行窗口里运行info replication命令，就能看到如下的输出，从输出里能确认故障恢复后的redis-master服务器会自动以“从服务器”的身份接入。

哨兵节点不仅能自动恢复故障，而且当故障节点恢复后会自动把它重新加入到集群中，而无须人工干预。也就是说，与简单的“主从复制模式集群”相比，基于哨兵模式的集群能很好地提升系统的可靠性。

Cluster集群（集群升级版）

前言

因为cluster的中文翻译是“集群”，所以在一些资料里会把本书提到的cluster集群称为Redis集群。

从广义上来讲，只要两台服务器之间有关联，它们就可以构成一个集群，所以在前文里把由“一主二从”和“哨兵节点加一主二从”等构成的系统称为“集群”。
这里为了避免混淆，将提到的集群称为cluster集群。
相比于哨兵模式，cluster集群能支持扩容，且无须额外的节点来监控状态，所以使用这种模式集群的系统会用得更多些。

Redis Cluster采用的是基于P2P的 去中心化网络拓扑架构，没有中心节点，所有节点既是数据存储节点，也是控制节点。
它放弃了一致性哈希算法，取而代之引入槽（slot）的这样一个概念，通过CRC+hashslot哈希算法支持多个主节点（分片），每个主节点分别负责存储一部分数据，这样理论上可以支持无限主节点的 水平扩容以便支持海量吞吐量。
内置类似哨兵（Sentinal） 高可用机制，每个节点都是主节点，能够实现自动故障转移，保证每个主节点（分片）的高可用。