文章目录
- 一、概述
- 二、搭建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文件，并添加单独的配置
代码语言：javascript复制include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
其他两个文件类似…
第五步：启动三个redis服务，以不同的端口
查看运行状态
进入redis客户端
代码语言：javascript复制redis-cli -p 6379 查看redis服务的运行状态:
代码语言：javascript复制info replication
目前三台服务器都是master主服务器，接下来以端口为6379的服务器为主机，其他两个为从机进行配置。
配置从（库）服务器
配置某个服务器为从服务器：
代码语言：javascript复制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不用做任何修改。
将从机变为主机：
代码语言：javascript复制slaveof no one 让主服务器 6379宕机:
查看6380状态，依然是从服务器：
执行命令，查看运行状态发现变成主服务器。
这种手动进行重启的方式非常的麻烦、耗时，redis中提供了当一个master服务器宕机后，自动 的将从机升为master 主机，这种方式成为哨兵模式。
四、哨兵模式
- 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
具体实现步骤：
① 重新搭建Redis一主二仆
② 在/myRedis目录下新建sentinel.conf文件（注：文件名不能修改）
③ 配置哨兵，添加如下内容
代码语言：javascript复制sentinel monitor mymaster 127.0.0.1 6379 1
# 其中mymaster为监控对象起的服务器名称，
# 1 为至少有多少个哨兵同意迁移的数量。④ 启动哨兵
执行如下命令：
代码语言：javascript复制redis-sentinel /sentinel.conf 
⑤ 测试主机宕机，会发生什么？
如图可以看到，6381 成为主服务器， 6380为从服务器，重启6379 后也成为6381的从机。
复制延时
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
代码实现
代码语言：javascript复制 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();
}
}五、主从复制原理
- 当从服务器连接上主服务器之后，从服务器向主服务器发送需要进行数据同步的消息。
- 主服务器接收到从服务器发送的数据同步的消息，先把主服务器 中的数据进行持久化到rdb中，将rdb文件发送给从服务器，从服务器拿到rdb文件进行读取数据。
- 每次主服务器进行写操作之后，就会和从服务器进行数据同步。（主服务器主动同步）
至此本次分享的内容就结束了，希望对大家有所帮助！！！
