文章内容是学习过程中的知识总结,如有纰漏,欢迎指正
文章目录
以下是本篇文章正文内容
一、主从复制
1.面临问题
Redis有
两种不同的持久化方式,Redis
服务器通过持久化,把Redis
内存中持久化到硬盘当中,当Redis
宕机时,我们重启Redis
服务器时,可以由RDB
文件或AOF
文件恢复内存中的数据。
问题1:不过持久化后的数据仍然只在一台机器上,因此当硬件发生故障时,比如主板或CPU
坏了,这时候无法重启服务器,有什么办法可以保证服务器发生故障时数据的安全性?或者可以快速恢复数据呢?
问题2:容量瓶颈
2.解决办法
针对这些问题,redis提供了复制(replication)
的功能,通过"主从(一主多从)"和"集群(多主多从)"的方式对redis的服务进行水平扩展,用多台redis服务器共同构建一个高可用的redis服务系统。
3.主从复制
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave),数据的复制是单向的,只能由主节点到从节点。
4.常用策略
策略1 :一主多从 主机(写),从机(读)
策略2:薪火相传
5.主从复制原理
Redis
的主从复制是异步复制,异步分为两个方面,一个是master
服务器在将数据同步到slave
时是异步的,因此master服务器在这里仍然可以接收其他请求,一个是slave在接收同步数据也是异步的。
复制方式
- 全量复制
master
服务器会将自己的rdb
文件发送给slave
服务器进行数据同步,并记录同步期间的其他写入,再发送给slave
服务器,以达到完全同步的目的,这种方式称为全量复制。
- 增量复制
因为各种原因master
服务器与slave
服务器断开后,slave
服务器在重新连上maste
r服务器时会尝试重新获取断开后未同步的数据即部分同步,或者称为部分复制。
工作原理
master
服务器会记录一个replicationId
的伪随机字符串,用于标识当前的数据集版本,还会记录一个当数据集的偏移量offset
,不管master
是否有配置slave
服务器,replication Id和offset会一直记录并成对存在,我们可以通过以下命令查看replication Id和offset:
> info repliaction
通过redis-cli在master或slave服务器执行该命令会打印类似以下信息(不同服务器数据不同,打印信息不同):
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1
master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee
master_repl_offset:9472
当master与slave正常连接时,slave使用PSYNC命令向master发送自己记录的旧master的replication id和offset,而master会计算与slave之间的数据偏移量,并将缓冲区中的偏移数量同步到slave,此时master和slave的数据一致。
而如果slave引用的replication太旧了,master与slave之间的数据差异太大,则master与slave之间会使用全量复制的进行数据同步(repl_backlog_size值调大可以尽量避免)。
6.配置主从复制
注:主从复制的开启,完全是在从节点发起的;不需要我们在主节点做任何事情。
从节点开启主从复制,有3种方式:
(1)配置文件:在从服务器的配置文件中加入:slaveof
(2)redis-server启动命令后加入 --slaveof
(3)Redis服务器启动后,直接通过客户端执行命令:slaveof ,则该Redis实例成为从节点
演示:
①、通过 info replication 命令查看三台节点角色
初始状态,三台节点都是master
②、设置主从关系,从节点执行命令:SLAVEOF IP(主节点) 6379
再看主节点信息:
这里通过命令来设置主从关系,一旦服务重启,那么角色关系将不复存在。想要永久的保存这种关系,可以通过配置redis.conf 文件来配置。
slaveof 主节点IP 6379
7.测试主从关系
①、增量复制
master 操作写入:
slave操作获取:
②、全量复制
通过执行 SLAVEOF 127.0.0.1 6379,如果主节点 6379 以前还存在一些 key,那么执行命令之后,从节点会将以前的信息也都复制过来
③、主从读写分离
尝试slave操作写入:
原因是在配置文件 6380redis.conf 中对于 slave-read-only 的配置
replica-read-only yes
如果我们将其修改为 no 之后,执行写命令是可以的,但是从节点写命令的数据从节点或者主节点都不能获取的。
④、主节点宕机
主节点 Master 挂掉,两个从节点角色会发生变化吗?
上图可知主节点 Master 挂掉之后,从节点角色还是不会改变的。
⑤、主节点宕机后恢复
主节点Master挂掉之后,马上启动主机Master,主节点扮演的角色还是 Master 吗?
也就是说主节点挂掉之后重启,又恢复了主节点的角色。
二、sentinel哨兵模式
通过前面的配置,主节点Master 只有一个,一旦主节点挂掉之后,从节点没法担起主节点的任务,那么整个系统也无法运行。
如果主节点挂掉之后,从节点能够自动变成主节点,那么问题就解决了,于是哨兵模式诞生了。
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
哨兵模式搭建步骤:
①、在配置文件目录下新建 sentinel.conf 文件,名字绝不能错,然后配置相应内容
sentinel monitor 主服务器器的名字(自己起名字) 主服务ip地址 端口号 得票数
分别配置被监控的名字,ip地址,端口号,以及得票数。上面的得票数为1表示表示主机挂掉后salve投票看让谁接替成为主机,得票数大于1便成为主机
②、启动哨兵
redis-sentinel /redis/sentinel.conf
接下来,我们干掉主机 6379,然后看从节点有啥变化
(选主策略:①从库优先级slave-priority配置项、②从库复制进度大的、③ID号小的)
PS:哨兵模式也存在单点故障问题,如果哨兵机器挂了,那么就无法进行监控了,解决办法是哨兵也建立集群,Redis哨兵模式是支持集群的。
总结
主从复制常用策略:
1.一主多从 主机写,从机读
2.薪火相传
主从复制方式:
1.全量复制
2.增量复制