Redis主从复制
-
主从复制:
指的是将一个Redis服务器的数据,复制到其他的Redis服务器
。前者称为主节点(master/leader),后者称为从节点(slave/follower)。 -
数据的复制是单向的 ,只能从主节点到从节
点。Master以写为主,Slave以读为主。 -
默认情况下,每台Redis服务器都是主节点,且一个主节点可以有多个从节点(或者没有从节点),但一个从节点只能有一个主节点。
主从复制的作用主要包括:
- 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式;
- 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复,实际上是一种服务冗余;
- 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务 (即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),
分担服务器负载
。尤其是在写少读多的场景下,通过从节点分担读负载,可以大大提供Redis服务器的并发量。 - 高可用(集群)基石:除了上述作用以外,主从复制还是哨兵和集群能够实现的基础,因此说主从复
制是Redis高可用的基础。
一般来说,用将Redis运用于工程项目中,只使用一台Redis是万万不可能的,原因如下:
- 从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大;
- 从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器内存容量为256G,也不能将所有内存用作Redis存储内存,一般来说,单台Redis最大使用内存不应该超过20G。
电商网站上的商品,一般都是一次上传,无数次浏览,也就是“多读少写”。对于这种场景,我们可
以使用如下的架构:
环境配置
我们只需要配置从库,不需要配置主库
配置注意事项:
复制3个配置文件(文件区分命名),修改.conf
中对应的信息:
- 端口号
port
pid
名字log
文件名字dump.rdb
名字
配置完成如下:
注
:
info replication
——查看主机信息slaveof host port
——配置从机
一主二从
默认情况下,每台redis服务器都是主节点,主需要配置从机就行。
从机复制主机
从机执行 SLAVEOF no one
可以重新恢复为主机。
两种模式
- 一个主机两个从机
- 链路模式
这样的模型也可以完成主从复制,中间的6380服务器既可以作为主服务器也可以作为从服务器,此时的6380依然属于从节点,依然只能读,无法写入。
- 此时假设主节点宕机,那么80结点想要当爸爸,在没有哨兵模式之前,我们的设定方法是:手动修改!!——让自己变成主机,其他结点可以手动选择该结点作为主节点。
如果此时主节点恢复连接,那也只能重新连接了:
相关细节
主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动保存在从机中。
主机断开连接
,从机依旧连接到主机的,但是没有写操作,这个时候,主机如果回来了,从机依旧可以 直接获取到主机写的信息- 如果使用命令行配置的从机,重启后,就会变回主机!只要在把他重新配成原来主机的从机,数据依旧可以获取到。
复制原理
Slave启动成功连接到Master后会向Master发送一个sync同步命令
Master接受到命令后,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,Master将传送 整个数据文件(全量复制) 到Slave,并完成一次完全同步。
- 全量复制 :Slave服务在接受到数据库文件数据后,将其存盘并加载到内存中
- 增量复制 :Master继续将新的所有收集到的修改命令一次传给Slave,完成同步
但是只要是重新连接Master,一次完全同步(全量复制)将被自动执行
!
哨兵模式
(自动选举老大的模式)
概述
- 前言:主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。
这不是一种推荐的方式
,更多时候,我们优先考虑哨兵模式。- Redis从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。
谋朝篡位的自动版
—— 能够后台监控主机是否故障,如果故障了,根据投票数自动将从库转换为主库哨兵模式是一种特殊的模式;
首先Redis提供了哨兵的命令,哨兵是一个单独的进程
,作为进程,他会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
哨兵的作用
- 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器
- 当哨兵监测到Master宕机,会自动将Slave切换成Master,然后
通过发布/订阅模式通知其他的从服务器
,修改配置文件,让它切换主机。然而一个哨兵进程对Redis服务器进程监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。
- 假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行
failover
进程,仅仅是哨兵1主观的认为主服务器不可用,这个现象称为主观下线
。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,头片的结果有一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布/订阅模式,让各个哨兵把自己监视的从服务器实现切换主机,这个过程称为客观下线
。
测试
- 配置哨兵配置文件
sentinel.conf
#sentinel monitor 主机名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
最后面的1,代表主机挂了,Slave投票看谁接替成为主机,票数最多的,就会成为主机.
2.启动哨兵
D:\redis\Redis-x64-3.2.100>redis-server sentinel.conf --sentinel
注意
:
- 如果Master节点断开,这个时候就会从从机中随机选择一个转换为主机!
- 如果之前的主机重新启动后,只能归并到新的主机下,成为新主机的从机。
测试主机宕机后哨兵的状态:
于是随机选取了6381转换为主机:
之前的Monster回来了,只能归并到新主机下:
哨兵模式的优点
- 哨兵集群,基于主从复制模式,所有的主从复制优点,它全有
- 主从可以切换,故障可以转移,系统的
可用性会更好
- 哨兵模式就是主从模式的升级,手动转自动,更加健壮
哨兵模式的缺点
- Redis不好在线扩展,集群容量一旦到达上限,在线扩容十分麻烦
- 实现哨兵模式的配置很麻烦,里面有很多选择