概念
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制是单向的,只能由主节点到从节点。Master以写为主,Slave以读为主。
默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
主从复制的作用
-
数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
-
故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
-
负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
-
高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
主从复制的两种策略
全量同步
Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:
- 从服务器连接主服务器,发送sync命令;
- 主服务器接收到sync命名后,开始执行bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
- 主服务器bgsave执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
- 从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
- 从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;
增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
思考:如果没有主节点了!能否从从节点中选一个作为主节点?
(答案是肯定的,在从机上使用 slaveof no one 命令将自己变成主机,其他的从机手动更改配置文件或者通过命令连接到这个新的主节点!实现故障恢复。)
哨兵模式(进阶)
(当主节点挂掉的时候,自动从从节点中选举主节点)
概述
主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的模式,更多时候,我们会优先考虑哨兵模式。Redis从2.8开始正式提供Sentinel(哨兵)架构来解决这个问题。
手动版升级为自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转为主库。
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
这里的哨兵有两个作用:
-
通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
-
当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。
然后一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。
工作流程:
假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover【故障转移操作】过程,仅仅是哨兵1主观的认为服务器不可用,这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间会进行一次投票,投票的结果由一个哨兵发起,进行failover【故障转移操作】,将票数多的一个从机切换成主机。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器连接到该主机,这个过程称之为客观下线。
如果主机此时回来了,只能归并到新的主机下,当作从机,这就是哨兵模式的规则!
哨兵模式优缺点:
优点:
哨兵集群,基于主从复制模式,所有的主从配置优点,它全有
主从可以切换,故障可以转移,系统的可用性就会更好
哨兵模式就是主从模式的升级,手动到自动,更加健壮
缺点:
Redis 不好在线扩容,集群容量一旦到达上限,在线扩容就十分麻烦!
实现哨兵模式的配置其实是很麻烦的,里面有很多选择!