Redis主从复制与哨兵模式

Redis主从复制与哨兵模式

一、主从复制

简单来说，主从复制就是将一台Redis服务器中的数据单向复制到其他的Redis服务器中，注意是单向的。其中前者称为主机Master，后者称为从机Slave，一般来说，写操作是在主机Master上完成，读操作是在从机Slave上完成，从而实现读写分离。

主从复制的作用主要有以下几点：

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，在实际的工程项目中我们往往使用的都不只有一台Redis服务器，原因主要有这几个：

1. 单台Redis服务器一旦发生宕机等意外情况就会导致整个Redis服务停止，影响整个项目的运行；
2. 单台Redis服务器的性能有限，让一台服务器来承担所有的请求负载，压力太大；
3. 单台Redis服务器的内存有限，如果我们的数据量太大的话，一台Redis服务器不足以承担太大的数据量。

二、Redis集群环境搭建

Redis能够搭建的集群环境有两种：一种是一主多从的结构，多台从机是直接作为主机的从机的；另一种是链式结构，除了第一台从机是作为主机的从机外，其他的从机都是作为前一台从机的从机。

下面是两种结构的图示：

Redis中提供了实现主从复制的命令：slaveof host port

在Redis中只需要配置从机，不需要配置主机，在默认情况下Redis服务启动的时候默认是主机，可以通过info replication来查看本机主从复制的信息，然后通过slaveof命令就可以将其配置为某个主机的从机。

这里介绍一下单机情况下配置多个Redis服务并搭建集群（一主二从）的情况：

1. 我们需要准备三个不同的配置文件（以三个不同的配置文件来启动三个Redis服务）；

2. 修改配置文件中的内容，需要修改的地方为：

   # 通过修改下面的配置来配置三个不同的配置文件
   port 6379							#端口号
   pidfile "/var/run/redis_6379.pid"	#pid文件名称
   logfile "6379.log"					#日志文件名称
   dbfilename "dump6379.rdb"			#rdb文件名称
   

3. 通过这三个不同的配置文件来启动三个Redis服务；

4. 通过info replication命令来查看主从机状态，刚启动的redis服务在默认情况下都是主机Master；

5. 选定一台主机，将其他的主机通过slaveof 127.0.0.1 6379命令来转变为主机的从机；

6. 通过info replication命令来查看主从机状态，可以在主机中查看到自己的身份是master，并且可以看到该主机拥有的从机有哪几个；在从机中可以查看到自己的身份是slave，并且可以看到该从机从属于哪一台主机；

7. 如果想要配置链式结构，就只需要通过slaveof命令将一台从机配置为另一台从机的从机即可；

8. 如果想要将从机重新转变为主机，可以通过slaveof no one来实现。

通过主从复制完成集群搭建之后，在主机中可以进行读写操作，而在从机中只能进行读操作。

如果主机宕机了，从机依旧是连接着主机的（依旧是从机），依旧可以进行读操作，但是无法进行写操作；若后面主机重新回来了，从机依旧可以从主机中获取主机写的数据。

如果从机宕机了，重启之后会变回主机，原因是通过命令行slaveof命令配置的主从复制是临时的，从机在重启之后会变回主机，如果需要重新变回从机就要重新执行slaveof命令，变回从机后就会立马从主机中获取数据。

如果想要配置永久的主从复制，可以通过配置文件来配置，因为Redis服务都是通过配置文件来启动的，在配置文件中配置了从属于某一台主机后，重新启动的话就会直接成为指定主机的从机。

复制原理：

Slave启动成功连接到master后会发送一个sync命令，Master接到命令后，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到Slave并完成一次完全同步。

全量复制：在Slave连接到Master时，自动执行全量复制，将Master上的全部数据复制到Slave中；

增量复制：在Slave和Master保持连接时，只针对于成功连接后Master上的更新的数据，同步到Slave中。

三、哨兵模式Sentinel

在了解哨兵模式之前先思考一个问题，在主从复制中，如果主机宕机了怎么办？

一般的解决方法就是重新启动主机（如果主机硬件坏了就没办法了），或者将其中的一台从机设置为主机。

如果是一主多从的直连结构的话就十分麻烦，不仅需要将一台从机设置为主机，还要修改其他的从机，将其主机指定为新的主机。

如果是链式结构的话就会简单很多，只需要将连接主机的那一台从机设置为主机即可。但是这种链式结构也有缺点，就是不仅主机宕机了，连中间的某个节点也宕机了怎么办？这修复起来也是十分麻烦的。

为了解决这样一个故障转移的问题，Redis提供了哨兵模式。

哨兵模式Sentinel

Redis的Sentinel系统是独立于Redis服务的进程，用于管理多个Redis服务器。

官网中给出了Sentinel系统的三个任务：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

这里有一个问题，如果Sentinel宕机了怎么办？很简单，加多几个Sentinel，不仅监控Redis系统，同时也互相监控。

一个多哨兵监控模式如下：

哨兵模式的工作过程

在了解哨兵模式的工作过程之前先了解一下主观下线和客观下线：

• 主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
• 客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

一次故障转移的过程大概是这样的：

1. 确定主机客观下线；
2. 哨兵们在从服务器中通过投票选举出一个从机作为新的主机，通过发送slaveof no one将其转为主机；
3. 通过发布订阅功能，将更新后的配置通知给其他的Sentinel让其更新配置；
4. 发送slaveof命令给其他的从机，让这些从机成为新的主机的从机，从新主机中复制。

简单的配置Sentinel

Sentinel和Redis服务类似，都需要通过配置文件来启动，默认情况下安装的Redis是不带Sentinel配置文件的，需要自己来创建。

创建配置文件sentinel.conf，实际上sentinel是有很多配置的，这里这配置一个，其他的都采用默认的就可以了。

# 配置所需要监控的redis服务
sentinel monitor myredis 127.0.0.1 6381 1

# 其他的配置不需要自己配，采取默认的即可

所以一个简单的配置文件只需要配置所需要监控的Redis服务即可。

sentinel启动命令：

# 根据配置好的配置文件来启动sentinel
redis-sentinel ./myconfig/sentinel.conf

启动之后该Sentinel就会监控所指定的Redis服务了，如果所监控的Redis服务宕机了就会根据投票来指定新的Master，这里只有一个Sentinel，所以就由这个Sentinel来指定新的Master。

参考文章：

https://wzlodq.blog.csdn.net/article/details/108182314

http://www.redis.cn/topics/replication.html

http://www.redis.cn/topics/sentinel.html