redis主从复制

注意：我使用的版本是6.0.10，不同版本可能略有差别

虽然redis有持久化的功能可以保证redis服务重启不会丢失数据，但是如果redis服务器的硬盘损坏就会导致数据丢失，，使用主从复制来避免这种单点故障。

主机数据更新后根据配置和策略自动同步到备机的master/slave机制，master以写为主，slave以读为主

原理

主要是使用PSYNC命令来实现

PSYNC命令具有完整重同步和部分重同步两种模式

• 完整重同步用于处理初次复制的情况：slave启动成功连接到master后会发送一个psync命令，master接到命令后会启动后台创建并发送RDB文件，完成后将命令发送给slave
• 部分重同步用于处理断线后重复制的情况：在断线后重连，slave向master发送psync命令，master将断线之后的写命令发送给slave

那么如何知道slave和master之间只差了这几个命令呢？

是因为master和slave在复制的时候都维护了一个复制偏移量，而master在复制积压缓冲区中会保存一部分最近传播的写命令，为每个字节来记录相应的复制偏移量，可以根据复制偏移量来找到对应的字节，当然，如果复制积压缓冲区中没有这个偏移量了，那么就只能进行全量复制了

redis默认的复制积压缓冲区为1mb，可以修改配置中repl-backlog-size 来进行调整

配置

配主不配从，配置slave即可，使得slave时刻盯住主机

在这里由于我只有一台电脑，所以只能用三个配置文件来启动三个redis服务了，带有配置文件的启动服务

redis-server redis79.conf

以及使用端口启动客户端

redis-cli -p 6379

启动之后就可以配置从机了

replicaof 127.0.0.1 6379

在5.0之后使用replicaof，5.0之前使用slaveof 不过当前slaveof还没有失效

# 可以配置最少有多少个从节点  主节点才可以写
# min-replicas-to-write 3
# min-replicas-max-lag 10

一主两仆

看一下执行命令之前的配置变化(使用info replication来查看)

#之前
# Replication
role:master
connected_slaves:0
master_replid:96519fc9dab0e66f4d1e8513f519b68622f4af9e
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

#之后
#主机
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=2646,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=2646,lag=1
master_replid:63b39507da5e42ce5e1b4d931f4e743c91bb92cd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2646
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2646


#从机
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:63b39507da5e42ce5e1b4d931f4e743c91bb92cd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:43
repl_backlog_histlen:0

重点：

从机会将主机的所有数据进行备份从机只能读，不能写(error) READONLY You can't write against a read only replica.主机挂了之后，从机身份不变(masterlinkstatus变成down)，直到主机回来，主机回来之后还是主机从机挂了之后需要重新执行从属命令replicaof 127.0.0.1 6379(如果是直接在配置文件中配置的从属关系则不需要)

可以使用命令来将从库变成主库

replicaof no one

在5.0之后使用replicaof，5.0之前使用slaveof 不过当前slaveof还没有失效

薪火相传

由于一主两仆机制会导致主机挂掉之后整个redis就挂掉的问题，所以为了去中心化，有了薪火相传机制，上一个slave可能是下一个slave的master，slave同样可以接收其他的slave的连接和请求，可以有效地减轻master的写压力

这里slave80对于slave81是主机，对于master79是从机

该机制可能会存在延迟

哨兵模式

由于一主两从的主库挂掉之后，需要人工的去干预从库反客为主，再进行更改主从配置，而哨兵模式通过监听主库是否挂掉，从库根据投票来决定自动将从库切换为主库

配置redis-sentinel.conf配置文件

#哨兵监控 6379  当6379挂了之后从库进行投票，票数超过1即可成为主库，配置文件会自动修改为新选举的主库ip和port
sentinel monitor mymaster 127.0.0.1 6379 1

哨兵启动

redis-sentinel redis-sentinel.conf

当主库挂掉之后，从库进行重新选举出新的主库，原来的主库回来之后，只会成为从库，不会变成双主库

哨兵的功能

哨兵节点不同于数据节点，不存储数据，且仅支持部分命令

• 监控 哨兵检查主节点和从节点是否正常运作
• 自动故障转移 主节点不能正常工作时，哨兵开始自动故障转移操作，将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点复制新的主节点
• 配置提供者 客户端在初始化时，通过连接哨兵来获得当时redis服务的主节点地址
• 通知 将故障转移结果发送给客户端

选举新的主服务器

sentinel会将所有的从服务器保存到一个列表中，然后进行筛选

• 首先会删除掉下线的从服务器
• 然后删除掉最近五秒内没有回复过sentinel的info命令的从服务器
• 删除掉与主服务连接断开超过down-after-milliseconds * 10 毫秒的从服务器(down-after-milliseconds表示判断主服务器下线所需的时间)
• 根据从服务器优先级进行排序，如果有多个最高优先级的从服务器，则选出偏移量最大的
• 如果存在多个最高优先级、复制偏移量最大的从服务器，则按照id进行排序，选出id最小的

sentinel是不会监控从服务器的，所以如果从服务器挂掉之后，sentinel是不会对其进行故障转移的

作用

• 读写分离
• 灾备