Redis主从复制

Posted on 2021-03-23 Edited on 2024-07-22 In 中间件 , Redis Views: Word count in article: 8.1k Reading time ≈ 7 mins.

1、主从复制

主从复制介绍

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（master/leader），后者称为从节点（slave/follower）；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制作用

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

实际项目建议

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：
- 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。
- 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

搭建Redis集群(一主二从)

①分别创建三个配置文件，用于启动主从结点。

②分别修改三个配置文件信息。

redis6379.conf：

port 6379 # 设置6379端口
daemonize yes # 设置后台运行
pidfile /var/run/redis_6379.pid # 设置进程文件位置及名称
logfile "6379.log" # 设置日志文件名
dbfilename dump6379.rdb # 设置rdb持久化文件名

redis6380.conf：

port 6380 # 设置6380端口
daemonize yes # 设置后台运行
pidfile /var/run/redis_6380.pid # 设置进程文件位置及名称
logfile "6380.log" # 设置日志文件名
dbfilename dump6380.rdb # 设置rdb持久化文件名

redis6381.conf：

port 6381 # 设置6381端口
daemonize yes # 设置后台运行
pidfile /var/run/redis_6381.pid # 设置进程文件位置及名称
logfile "6381.log" # 设置日志文件名
dbfilename dump6381.rdb # 设置rdb持久化文件名

③分别使用不同配置文件启动redis：
④目前每个redis都是主节点，接下来配置从结点。
- 第一个从节点设置为6380端口的，执行SLAVEOF 127.0.0.1 6379命令即可。
- 第二个从节点设置为6381端口的，执行SLAVEOF 127.0.0.1 6379命令即可。
- 主节点为6379端口，不用进行配置，查看其从节点信息：

主节点可以写，从节点只能读。

主节点可以写和读。
从节点只能读不能写。

主节点断开连接，从节点仍然能获取到数据，并且还保持着主节点的信息(此时如果要把自己变成主节点只需执行SLAVEOF no one命令)。主节点重新启动并添加键值，此时从节点依旧能从主节点读取信息。

①主节点断开连接。
②从节点仍然能获取到数据，并且还保持着主节点的信息。
③主节点重新启动并添加键值，此时从节点依旧能从主节点读取信息。

复制原理

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

2、哨兵模式

哨兵模式：实现自动选取主节点

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
- 这里的哨兵有两个作用：
  - 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
  - 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
- 假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试哨兵模式

①编写三个哨兵配置文件分别为：sentinel26379.conf、sentinel26380.conf、sentinel26381.conf，内容如下：

# 当前Sentinel服务运行的端口，三个配置文件只有端口号不同
port 26379

# 配置监听的主服务器
# sentinel monitor代表监控
# mymaster代表服务器的名称，可以自定义
# 127.0.0.1代表监控的主服务器，6379代表端口
# 2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作
sentinel monitor mymaster 127.0.0.1 6379 2

# 如果在failover-timeout该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel down-after-milliseconds mymaster 5000

②开启一主二从Redis服务器。

③分别启动三个哨兵，即运行以下三个命令。

1
2
3

redis-sentinel config/sentinel26379.conf
redis-sentinel config/sentinel26380.conf
redis-sentinel config/sentinel26381.conf

④此时断开主服务器，过一小段时间后发现主服务器被自动切换到端口号为6381的了。
⑤如果此时原来的主服务器重新连接，那么它只会被当做从机使用。

哨兵模式优点

哨兵集群，基于主从复制模式，所有的主从配置优点，它都有。
主从可以切换，故障可以转移，高可用性的系统。
哨兵模式就是主从模式的升级，手动到自动，更加健壮。

哨兵模式缺点

Redis不好在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦。
哨兵模式的配置繁琐。

哨兵模式配置文件详解

# 哨兵sentinel实例运行的端口默认26379
port 26379

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

# 哨兵sentinel监控的redis主节点的ip port
# master-name可以自己命名的主节点名字只能由字母A-z、数字0-9、这三个字符".-_”组成。
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 63792

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

# 指定多少毫秒之后主节点没有应答哨兵sentine1此时哨兵主观上认为主节点下线默认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，但是就不按paralle1-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>是“1eader”或者“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

3、Cluster模式

哨兵模式解决了主从复制不能自动故障转移，达不到高可用的问题，但还是存在难以在线扩容，Redis容量受限于单机配置的问题。Cluster模式实现了Redis的分布式存储，即每台节点存储不同的内容，来解决在线扩容的问题。如图。
Cluster采用无中心结构,它的特点如下：
- 采用去中心化的思想，没有中心节点的说法，它使用hash slot方式将16348个hash slot覆盖到所有节点上，对于存储的每个key值，使用CRC16（KEY）&16348=slot得到他对应的hash slot，并在访问key的时候就去找他的hash slot在哪一个节点上，然后由当前访问节点从实际被分配了这个hash slot的节点去取数据，节点之间使用轻量协议通信减少带宽占用，性能很高，自动实现负载均衡与高可用，自动实现failover并且支持动态扩展。
- 其内部中也需要配置主从，并且内部也是采用哨兵模式，如果有半数节点发现某个异常节点，共同决定更改异常节点的状态，如果改节点是主节点，则对应的从节点自动顶替为主节点，当原先的主节点上线后，则会变为从节点。
- 如果集群中的master没有slave节点，则master挂掉后整个集群就会进入fail状态，因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，无论是否有slave，集群都会进入fail状态。
- 同一分片多个节点间的数据不保持强一致性。

部署案例：制作6个实例，6379,6380,6381,6389,6390,6391。

①在/usr/redis-6.2.1/cluster-config目录下分别新建redis6379.conf、redis6380.conf、redis6381.conf、redis6389.conf、redis6390.conf、redis6391.conf，redis6379.conf的内容如下，其它配置文件只需要更改成不同的端口号：

port 6379 # 设置6379端口
daemonize yes # 设置后台运行
pidfile "/var/run/redis_6379.pid" # 设置进程文件位置及名称
dbfilename "dump6379.rdb" # 设置rdb持久化文件名
logfile "redis_6379.log" # 设置日志文件名
cluster-enabled yes # 开启集群模式
cluster-config-file nodes_6379.conf # 集群的配置文件
cluster-node-timeout 15000 # 设定节点失联时间，超过该时间(毫秒)，集群自动进行主从切换

②使用redis-server分别启动6个redis实例，如图。

③将6个结点合成一个大集群。

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6389 127.0.0.1:6390 127.0.0.1:6391 # --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点

④连接redis服务器（-c采用集群策略连接，设置数据会自动切换到相应的写主机），并查看节点的信息。
1
2
redis-cli -c -p 6379
cluster nodes
⑤验证插槽：
- 一个Redis集群包含16384个插槽（hash slot），数据库中的每个键都属于这16384个插槽的其中一个。如上面案例集群中的每个节点负责处理一部分插槽。
  - 节点A(6379端口)负责处理0号至5460号插槽。
  - 节点B(6380端口)负责处理5461号至10922号插槽。
  - 节点C(6381端口)负责处理10923号至16383号插槽。
- 集群使用公式CRC16(key)%16384来计算键key属于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验和。
⑥在集群中插入值。以下例子由于键k1计算出来的slot是12706，所以转交给了6381端口处理；由于键k2计算出来的slot是449，所以又转回给6379端口处理；而如果使用mset同时插入多组键值对会报错，解决办法是可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。
⑦使用基本命令。
- 查询某个key对应的slot。
- 计算某个插槽中有几个key(只能查看到自己slot范围中的key数量)。
- 返回插槽中指定数量的key。
⑧测试自动恢复。
- ①主节点下线。
- ②连接6380端口的服务器，发现6379的master下线后，原本作为slave的6389自动变成master。
- ③重新启动6379端口的服务器，发现其变成slave，不再是master。
- ④如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续？需要按照配置文件redis.conf中的参数cluster-require-full-coverage来指定：
  - 如果某一段插槽的主从都挂掉，而cluster-require-full-coverage为yes，那么整个集群都挂掉。
  - 如果某一段插槽的主从都挂掉，而cluster-require-full-coverage为no，那么该插槽数据全都不能使用，也无法存储。