文章目录

一、概述
二、搭建Redis一主两从
三、主从复制场景
四、哨兵模式
五、主从复制原理

一、概述

主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
Redsi主从复制可以实现读写分离，对性能进行极大程度的扩展。
容灾快速恢复

通俗的说：

应用系统访问到master Redis服务器中，进行写数据的操作，当数据写入完成后，master服务器会将写入的数据复制到Slave从服务器中，进行数据的同步，当应用系统读取数据的时候，会去从服务器中读取数据。主服务器只做写数据操作，从服务器只做读数据的操作，这样减轻了各服务器的压力，提高读写效率，将读、写份离开，也就是数据的读写分离。

当应用程序在从服务器读取数据的时候，首先去第一台从服务器读取数据，突然，第一台从服务器宕机了，这时无法从此服务器继续读取数据，根据Redsi容灾机制，会切换到下一台从服务器去读取数据，这就实现了服务器的容灾恢复。

二、搭建Redis一主两从

环境配置

LInux操作系统，CentOS 7
Redis服务器
三台装有Redis的服务器。（此处使用一台服务器开启三个redis服务来模拟一主两从）

搭建步骤

第一步：在根目录下创建myRedis文件夹

第二步：复制redis.conf配置文件到myRedis文件夹

第三步：创建三个端口号不同的redis.conf，分别为redis6379.conf、redis6380.conf、redis6381.conf，以不同的端口服务模拟一主两从

第四步：在以上三个配置文件中，引入myRedis文件夹下的redis.conf文件，并添加单独的配置

include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

其他两个文件类似…

第五步：启动三个redis服务，以不同的端口

查看运行状态

进入redis客户端

redis-cli -p 6379

查看redis服务的运行状态:

info replication

目前三台服务器都是master主服务器，接下来以端口为6379的服务器为主机，其他两个为从机进行配置。

配置从（库）服务器

配置某个服务器为从服务器：

slaveof  <ip><port>
ip : 主服务器IP
port : 主服务器端口号

可以看到端口为6379 的主服务器有两个从服务器。

测试一下

在6379 中进行写操作：

在 6380 、6381 中查看：

数据已经同步成功。

那在6380 从机中进行写操作：

报错提示： You can’t write against a read only replica.（无法针对只读副本进行写入。）

测试成功，实现读写分离。

三、主从复制场景

一主二仆

基于以上搭建的一主两从服务，可能会出现以下的问题：

其中一台从服务器宕机之后，会发生什么？
如果master 主服务器宕机之后，会发生什么？

接下来就以上两个问题进行一个演示。

① 其中一台从服务器宕机之后，会发生什么？

目前以端口为 6379 的服务器为主服务器， 6380、6381为从服务器，先让6381的从服务器挂掉。

6379 运行状态：

显示，目前只有一台从服务器。

接下来往6379 主服务器写入数据：

6380 中查看数据：

数据同步正常。

接下来，将宕机的6381 重新启动：

重启后发现，之前的从服务器变成了主服务器，接下来重新让其变为从服务器。

如图，6381已经重新成为了从服务器，之前在6381宕机之后，主服务器写入了几条数据，那么是否同步成功？

发现，当6381服务器重新成为从服务器后，会将主服务器的数据重新复制一份。

特点：

当从服务器宕机后，再次重启之后，从服务器无法成为之前主服务器的从服务器，而是新的主服务器。
当从服务器宕机后，再次重启之后，从服务器会将主服务器中的数据重新全部复制一份。

② 如果master 主服务器宕机之后，会发生什么？

目前以端口为 6379 的服务器为主服务器， 6380、6381为从服务器，先让6379的主服务器挂掉。

6380、6381从服务器的运行状态：

当主服务器宕机后，从服务器依然是从服务器，主服务器依然是宕机后的主服务器。

接下来，重新启动主服务器，查看运行状态：

主服务器重新回到大哥的位置！！

特点：

当主服务器宕机后，从服务器不做任何事情，依然是宕机后的主服务器的从服务器。
当主服务器重新启动之后，依然是主服务器。

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

在这种场景中有一个缺点，就是当主服务器同步给第二节点的从服务器后，第二节点的从服务器宕机了，无法想后面的从服务器继续同步数据。

反客为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

将从机变为主机：

slaveof  no one

让主服务器 6379宕机:

查看6380状态，依然是从服务器：

执行命令，查看运行状态发现变成主服务器。

这种手动进行重启的方式非常的麻烦、耗时，redis中提供了当一个master服务器宕机后，自动的将从机升为master 主机，这种方式成为哨兵模式。

四、哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

具体实现步骤：

① 重新搭建Redis一主二仆

② 在/myRedis目录下新建sentinel.conf文件（注：文件名不能修改）

③ 配置哨兵，添加如下内容

sentinel monitor mymaster 127.0.0.1 6379 1
# 其中mymaster为监控对象起的服务器名称， 
# 1 为至少有多少个哨兵同意迁移的数量。

④ 启动哨兵

执行如下命令：

redis-sentinel  /sentinel.conf

⑤ 测试主机宕机，会发生什么？

如图可以看到，6381 成为主服务器， 6380为从服务器，重启6379 后也成为6381的从机。

复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

代码实现

		private static JedisSentinelPool jedisSentinelPool=null;

		public static  Jedis getJedisFromSentinel(){
					if(jedisSentinelPool==null){
							            Set<String> sentinelSet=new HashSet<>();
							            sentinelSet.add("192.168.11.103:26379");
							
							            JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
							            jedisPoolConfig.setMaxTotal(10); //最大可用连接数
							jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
							jedisPoolConfig.setMinIdle(5); //最小闲置连接数
							jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
							jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
							jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong
							
							jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
							return jedisSentinelPool.getResource();
				        }else{
							return jedisSentinelPool.getResource();
        	}
	}