Redis主从复制

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。

• 前者称为主节点（master/leader），后者称为从节点（slave/follower）。
• 数据的复制是单向的，只能由主节点到从节点。
• Master以写为主，Slave以读为主。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

数据冗余：在网络托管中，数据冗余是一种策略，确保您永远不会失去任何数据。

备份：是现有数据的重复拷贝。

冗余，不仅仅是复制数据；它是一个积极主动的行动计划，设计这个计划是为了您永远不会丢失数据。备份是整个冗余计划的一部分。

Redis运用到项目中

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：

1. 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大.
2. 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是“多读少写”。

​ 对于这种场景，我们可以使如下这种架构：

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

环境配置

只配置从库，不用配置主库。

使用命令查看当前库的信息

info replication

主库的role为masterrole:master

同时需要设置连接的从库数量connected_slaves:0

复制3个配置文件，然后修改对应的信息。

1. 端口
2. pid名字
3. log文件名字。6379.log
4. dump.rdb名字

修改完毕之后，分别对应修改后的三个配置文件启动我们的3个Redis服务器，可以通过进程信息查看。

ps -ef|grep redis

一主二从

默认情况下，每台Redis服务器都是主节点；我们一般情况下只用配置从机就好了！

认老大！一主（6379）二从（6380，6381）。从机认主机当老大

配置详情见子项

如果两个都配置完了，就是有两个从机的信息

真实环境的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，只是暂时的！

细节！

主机可以写，从机不能写只能读！主机中的所有信息和数据，都会自动被从机保存！

1. 主机断开连接，从机依旧会连接到主机，但是没有写操作，这个时候，如果主机回来了，继续写数据，从机依旧可以直接获取到主机写的信息。（无论命令行还是配置文件配置的主从都是这样）
2. 如果是使用命令行来配置的主从，这个时候从机如果重启了，就会变回主机！但是使用命令行让他再次连接主机，就会立即从主机获取值。（只要变为从机，立马就会从主机中获取值）

（如果是配置文件配置的主从，从机重启后立即会从主机获取值）

配置主机

127.0.0.1:6380> slaveof 127.0.0.1 6379 # slaveof 主机地址 端口号，找谁当老大
OK
127.0.0.1:6380> info replication
# Replication
role:slave # 当前角色是从机
master_host:127.0.0.1 # 可以看到主机的信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e700a386c850303c045de2c5223947da75490c74
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

在主机中查看

# 配置从机之前的信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:2f5f0dbe824198d52ee1da8228368c158fc86cab
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
# 配置从机之后的信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1 # 多了从机的配置信息
slave0:ip=127.0.0.1,port=6380,state=online,offset=56,lag=1
master_replid:e700a386c850303c045de2c5223947da75490c74
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56

master宕机时手动选择新master

宕机后手动配置主机

层层链接

上一个Master链接下一个Slave！此时的80依旧是从节点，不能进行写操作。

这个模型也能完成我们的主从复制。

如果没有老大了，这个时候能不能选择一个老大出来呢？手动设置！

如果主机断开了连接，我们可以使用SLAVEOF no one命令让自己变成主机！其他的节点就可以手动连接到最新的这个主节点（手动）！如果这个时候老大修复了，老大就变成光杆司令了，需要重新连接！

哨兵模式（重点）

哨兵模式是自动选举新主机的模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。

配置主机自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

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

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