Redis--12.进阶（主从复制）

1.介绍

主从复制,是指将一台Redis服务器的数据 ,复制到其他的Redis服务器。前者称为主节点(master/leader) ,后者称为从节点(slave/follower) ;数据的复制是单向的,只能由主节点到从节点。Master以写为主, Slave以读为主。默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点) ,但一个从节点只能有一个主节点。
主从复制的作用主要包括:
1、数据冗余:主从复制实现了数据的热备份,是持久化之外的一-种数据冗余方式。
2、故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
3、负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点) , 分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
4、高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制Redis高可用的基础。

一般来说 ,要将Redis运用于工程项目中,只使用一台Redis是万万不能的（宕机）,原因如下:
1、从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力大;
2、从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器内存容 量为256G ,也不能将所有内存用作Redis存储内存，一般来说 ,单台Redis最大使用内存不应该超过20G。
电商网站上的商品, 一般都是一次上传,无数次浏览的,说专业点也就是"多读少写"。
对于这种场景，我们可以使用如下架构：

主从复制,读写分离! 80% 的情况下都是在进行读操作!减缓服务器的压力!架构中经常使用!一主二从!
 

2.配置一个redis伪集群

1）我们先启动redis服务器，再启动一个redis客户端，使用  "info replication"命令查看当前服务的i情况：发现role=master（主机），这也验证了前面说的，redis默认是主节点，而非从节点

2）所以我们需要给它配置从机，我们开启四个命令行，三个用于配置主从结构，一个用于测试：

3）然后我们需要为三个redis服务器配置各自的配置文件，先将默认的复制3份：

 4）修改各自的配置文件，启动等会redis服务时，就用各自的配置文件：

（1）配置redis6379.conf：将log文件名改为“6379.log”，把rdb文件名改为“dump6379.log”

（2）配置redis6380.conf：将port、log、profile、rdb都改成带有6380字样的，因为防止重名

（3）同理修改redis6381.conf配置文件

5）使用各自的文件启动redis服务： 使用ps命令查看启动情况：三个服务启动成功！

但是现在这三个都是master(连接客户端后使用info replication命令查看):6379的如下,其他省略:

3.配置一个一主二重的redis主从结构

默认情况下,每台Redis服务器都是主节点;我们一般情况下只用配置从机就好了；下面将其中两台配置成slave:这里我将6379端口的当主机，6380和6381的当作从机：

1）使用SLAVEOF命令：这种方法是暂时的，关闭了就失效了，因为不会保存

然后我们在6380端口的redis下查看，当前库的身份：是6379端口的从机了

同理配置6381端口为6379端口的从机：

然后我们在6379端口即可看到从机的一些信息：

2）在文件中进行配置：找到REPLICATION

在这个分区下面的replicaof 

注意：配置好后，主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动被从机保存!

如下：6379写入，6380和6381读出，且6380和6381不能写入

还有几点：

（1）当主机断开连接,从机依旧连接到主机的,但是不能写操作,若这个时候,主机如果重新连接,从机依旧可以继续直接获取到主机写的信息。
（2）如果是使用命令行来配置的主从,这个时候如果从机重启了,这个从机就会变回主机!但是只要又进行配置，变为之前那个主机的从机,立马就会获取那个主机中的数据。

4.复制原理

Slave启动成功连接到master后会发送一个sync同步命令，Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传送整个数据文件到slave ,并完成一次完全同步。
全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制: Master继续将新的所有收集到的修改命令依次传给slave ,完成同步。
但是只要是重新连接master , 一次完全同步(全量复制)将被自动执行，也就是上面说的情况。

5.另一种方式的主从结构

由图就可以看出，两种方式的主从结构，而上面配置的是第一种主从结构，我们也可以配置第二种 主从结构：将6379作为主机，6380作为6379的从机，6381作为6380的从机，就形成了链状结构。

这里我们还是用命令行测试一下：

上面是6381端口的信息，下面我们看一下中间的6380是什么身份：

6.宕机后手动配置主节点

主从结构都有一个问题：如果主节点宕机了，那怎么将从节点配置成主节点呢，或者有多个从节点，怎么从其中选出主节点呢？----哨兵模式

但是现在这里我们讲手动配置：

如果主机断开了连接,我们可以使用[ SLAVEOF no one ] 让自己变成主机!其他的节点就可以手动连接到最新的这个主节点即可。倘若此时原来的主机重新连接了，这是也是新的主机当其他从节点的主节点，而非原来的那个了。

7.Sentinel(哨兵模式)概述

主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。上面提到过，这不是一种推荐的方式 ,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵)架构来解决这个问题。
Sentinel：它能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。哨兵模式是一种特殊的模式 ,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。结构如图:这里的哨兵有两个作用:
●通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
●当哨兵监测到master宕机,会自动将slave切换成master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,比如哨兵也宕机了，为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式：

假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,因为仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票 ,投票的结果由一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。

8.哨兵模式基础配置

这里配置哨兵用到的redis结构是第一种方式，也就是一主机连接两个从机

1）新建一个名为sentinel.conf(名字不能错了)的文件：这里最后面的1表示，当主机挂了，就让从机投票选举新的主机。这句话是最基础和核心的配置。

2）启动哨兵：redis-sentinel  +配置文件路径

3）测试

(1)我们先关闭主节点6379

(2)等待查看sentinel进程的信息(3)看一下现在是不是6380被选举成了主机(4)若此时我们将6379重新连接：会把6379作为新的主机的从机

哨兵进程日志：6379变成了6380的从机

4）优缺点：

优点:
-- 哨兵集群,基于主从复制模式,所有的主从配置优点,它全有
-- 主从可以切换,故障可以转移,系统的可用性就会更好
-- 哨兵模式就是主从模式的升级,手动到自动,更加健壮!
缺点:
-- Redis 不好在线扩容,集群容量一旦到达 上限,在线扩容就十分麻烦!
-- 实现哨兵模式的配置其实是很麻烦的,里面有很多选择!上面的只是最基础的一条配置

9.哨兵模式详细配置样例

# Examp1e sentinel.conf

#哨兵sentinel实例运行的端口默认26379 如果要配置集群,则需要为每个sentinel配置不同端口
port 26379

#哨兵sentinel的工作目录
dir /tmp

#哨兵sentinel监控的redis主节点的ip port
# master-name 可以自己命名的主节点名字只能由字母A-z、数字0-9、这三个字符".- "组成。
# quorum配置多少个sentinel哨兵统--认为master主节点失联,那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

#当在Redis实例中开启了requirepass foobared 授权密码这样所有连接Redis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123password

# 指定多少毫秒之后主节点没有应答哨兵sentinel此时哨兵主观上认为主节点下线默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，
# 这个数字越小，完成failover所需的时间就越长，
# 但是如果这个数字越大，就意味着越多的slave因为replication而不可用。
# 可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
#故障转移的超时时间failover-timeout可以用在以下这些方面:
# 1.同一个sentinel对同一个master两次failover之间的间隔时间。
# 2.当一个slave从一个错 误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那# 里同步数据时。
# 3.当想要取消一个正在进行的failover所需要的时间。
# 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时
# slaves #依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

#SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通#知相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 !
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信 号终止，之后重新执行。
#通知型脚本:当sentine1有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等)，将
#会去调用这个脚本，这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。
#调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文#件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法
#正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh 

#客户端重新配置主节点参数脚本
#当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已
#经发生改变的信息。
#以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#目前<state>总是“failover”,
# <role> 是“Teader”或者“observer"中的一个。
#参数from-ip，from-port， to-ip， to-port是用来和旧的master和新的master (即旧的slave)通信的
#这个脚本应该是通用的,能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh