一、概述
- 主机数据更新后根据配置和策略, 自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主。
- Redsi主从复制可以实现读写分离,对性能进行极大程度的扩展。
- 容灾快速恢复
通俗的说:
应用系统访问到master Redis服务器中,进行写数据的操作,当数据写入完成后,master服务器会将写入的数据复制到Slave从服务器中,进行数据的同步,当应用系统读取数据的时候,会去从服务器中读取数据。主服务器只做写数据操作,从服务器只做读数据的操作,这样减轻了各服务器的压力,提高读写效率,将读、写份离开,也就是数据的读写分离。
当应用程序在从服务器读取数据的时候,首先去第一台从服务器读取数据,突然,第一台从服务器宕机了,这时无法从此服务器继续读取数据,根据Redsi容灾机制,会切换到下一台从服务器去读取数据,这就实现了服务器的容灾恢复。
二、搭建Redis一主两从
环境配置
搭建步骤
第二步:复制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();
}
}
五、主从复制原理
- 当从服务器连接上主服务器之后,从服务器向主服务器发送需要进行数据同步的消息。
- 主服务器接收到从服务器发送的数据同步的消息,先把主服务器 中的数据进行持久化到rdb中,将rdb文件发送给从服务器,从服务器拿到rdb文件进行读取数据。
- 每次主服务器进行写操作之后,就会和从服务器进行数据同步。(主服务器主动同步)
原文地址:https://xiaozhao.blog.csdn.net" target="_blank" rel="noopener" title="百思不得小赵">百思不得小赵</a> <img class="article-time-img article-heard-img" src="https://csdnimg.cn/release/blogv2/dis
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。