Redis（4）——主从复制

Redis主从复制

• 主从复制：指的是将一个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。

电商网站上的商品，一般都是一次上传，无数次浏览，也就是“多读少写”。对于这种场景，我们可
以使用如下的架构：

环境配置

我们只需要配置从库，不需要配置主库

配置注意事项：

复制3个配置文件（文件区分命名），修改.conf中对应的信息：

1. 端口号port
2. pid名字
3. log文件名字
4. dump.rdb名字

配置完成如下：

注：

• info replication——查看主机信息
• slaveof host port——配置从机

一主二从

默认情况下，每台redis服务器都是主节点，主需要配置从机就行。

从机复制主机

从机执行 SLAVEOF no one 可以重新恢复为主机。

两种模式

1. 一个主机两个从机
   
2. 链路模式
   

这样的模型也可以完成主从复制，中间的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[故障转移]操作。切换成功后，就会通过发布/订阅模式，让各个哨兵把自己监视的从服务器实现切换主机，这个过程称为客观下线。

测试

1. 配置哨兵配置文件 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不好在线扩展，集群容量一旦到达上限，在线扩容十分麻烦
• 实现哨兵模式的配置很麻烦，里面有很多选择