Redis笔记 --主从复制

Redis主从复制

通过持久化功能，Redis保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，但是由于数据是存储在一台服务器上的，如果某个时刻该Redis服务挂了，那么会导致整个服务的Redis不可用，在此期间，大量的请求将会直接打到数据库(mysql)，导致数据库压力陡增，严重的可能导致数据库直接挂掉。这种情况，我们称之为单点故障。

为了避免单点故障，我们需要将数据复制多份部署在多台不同的服务器上，即使有一台服务器出现故障其他服务器依然可以继续提供服务。

这就要求当一台服务器上的数据更新后，自动将更新的数据同步到其他服务器上，这时候就用到了Redis的主从复制。

引用文章

1.主从同步

1.1.概念

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

前者称为主节点(master/leader)，后者称为从节点(slave/follower)；

数据的复制是单向的，只能由主节点到从节点。

Master以写为主，Slave 以读为主。

默认情况下，每台Redis服务器都是主节点；

且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

1.2 原理

Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

1.2.1 全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

1）从服务器连接主服务器，发送SYNC命令；

2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；

3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

1.2.2 增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

1.2.3 Redis主从同步策略

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

1.3特点

1. master可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给slave；
2. slave一般都是只读的，并且接收master同步过来的数据；
3. 一个master可以拥有多个slave，但是一个slave只能对应一个master，一个slave又可以拥有多个slave；
4. slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来；
5. master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务；
6. master挂了以后，不会自动在slave节点中重新选一个master，但可以手动操作升级slave为master；
7. 主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求；
8. 可以用于读写分离和容灾恢复；

1.4演示

1.4.1准备工作

查看master，此时connected_slaves为0，代表没有slave

复制相同文件夹，更改slave中redis.windows.conf中的端口号

#redis6380目录下的redis.windows.conf
port 6380
slaveof 127.0.0.1 6380
 
#redis6381目录下的redis.windows.conf
port 6381
slaveof 127.0.0.1 6381

1.4.2 启动服务

#win+R打开cmd，分别进入reids6379、redis6380、redis6381目录
#输入如下命令
redis-server.exe redis.windows.conf

使用info Replication 查看主从信息

1.4.3测试

在主机上写，在从机上读：

在6379上写，成功

在6380上写，失败。但是可以读master写入的数据

1.5 缺点

• master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务;
• IO剧增: 每次slave断开以后（无论是主动断开，还是网路故障）再连接master都要将master全部dump出来rdb，在aof，即同步的过程都要重新执行一遍；所以要记住多台slave不要一下都启动起来，否则master可能IO剧增（间隔1-2分）；
• 复制延迟: 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

2.哨兵模式

Redis的主从复制下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方法是无法接受的。但是Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化通知给Redis应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题。

sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，该系统执行以下三个任务：

• 监控（Monitoring）：Sentinel会不断地检查你的master和slave是否运行正常；

• 提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知；

• 自动故障迁移（Automatic failover）:

  （1）当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，他会将失效master的其中一个slave升级为新的master，并让失效master的其他slave改为复制新的master；
  （2）客户端试图连接失败的master时，集群也会向客服端返回新master的地址，集群可以使用新master代替失效master。

哨兵模式属于反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

2.1 特点

1. sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义；

2. 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master；

3. 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据；

4. sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群；

5. 多sentinel配置的时候，sentinel之间也会自动监控；

6. 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心；

7. 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis；

8. sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了；

2.2 工作机制

1. 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令

2. 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。

3. 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态

4. 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线

5. 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令

6. 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次

7. 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；
   若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

3.Cluster模式

3.1Cluster模式介绍

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用集群，只需要将redis配置文件中的 cluster-enable配置打开即可。每个集群中至少需要三个master才能正常运行，新增节点非常方便。

3.2实现原理

• 主观下线
  集群中每个节点都会定期向其他节点发送ping消息，接受节点回复ping消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接受节点标记为主观下线(pfail)状态。

• 客观下线
  1)当某个节点判断另一个节点主观下线后，相应的节点状态会跟随消息在集群内传播。

  2)假设节点a标记节点b为主观下线，一段时间后节点a通过消息把节点b的状态发送到其他节点，当其他节点收到消息并解析出消息体中含有b的pfail状态，把节点b加入下线报告链表；

  3)当某一节点c收到节点b的pfail状态时，此时有超过一半的槽主节点都标记了节点b为pfail状态时，则标记故障节点b为客观下线；

  4)向集群广播一条pfail消息，通知集群内的所有节点标记故障节点b为客观下线状态并立刻生效，同时通知故障节点b的从节点触发故障转移流程。

• 故障恢复
  1)资格检查：若从节点与主节点断线时间超过一定时间，则不具备资格
  2)准备选举时间：当从节点符合故障转移资格后，要等待一段选举时间后才开始选举在故障节点的所有从节点中，复制偏移量最大的那个从节点最先开始（与主节点的数据最一致）进行选举，然后是次大的节点开始选举…剩下其余的从节点等待到它们的选举时间到达后再进行选举
  3)发起选举
  4)选举投票：只有持有槽的主节点才具有一张唯一的选票，从从节点收集到N/2 + 1个持有槽的主节点投票时，从节点可以执行替换主节点操作
  5)替换主节点：当从节点收集到足够的选票之后，触发替换主节点操作

• 当前从节点取消复制变为主节点

• 撤销故障主节点负责的槽，并把这些槽委派给自己

• 向集群广播自己的pong消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息数据。

3.3 特点

1. 所有redis节点彼此互联，数据共享；
2. 所有的节点都是一主一从（也可以是一主多从），其中slave不提供服务，仅作为备用；
3. 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，
   并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为；
4. 支持在线增加、删除节点；
5. 客户端可以连接任何一个master进行读写；（客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可；）
6. 节点的fail是通过集群中超过半数的master节点检测失效时才生效；
7. 选举过程是集群中所有master参与,如果半数以上master节点与故障节点通信超过(cluster-node-timeout),认为该节点故障，自动触发故障转移操作；
8. 如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完全时进入fail状态；
9. 如果集群超过半数以上master挂掉，无论是否有slave集群进入fail状态（当集群不可用时,所有对集群的操作做都不可用）；

4.应用场景

• 读写分离【master以写为主(可写也可以读)，slave只能读不可写入】
• 大数据量【单机不足以容纳的数据量】
• 容灾恢复【主节点写入的数据会同步（不是准实时的）到salve上，这样如果主节点出现故障，数据丢失，则可以通过salve进行恢复。注：因为数据不是实时同步的，可能会存在从salve恢复数据后有数据丢失问题】