Redis的持久化功能在一定程度上保证了数据的安全，并确保即使服务器故障，数据丢失也非常少。 通常，为了避免服务单点故障，数据会复制到多个副本中并放置在单独的服务器上。 这些具有数据副本的服务器可以用于处理客户端的读取请求，从而提高整体性能
这里介绍了Redis主从复制的构成和实现原理。 然后有Redis的高可用性方案。 哨兵机制(Sentinel )、分区集群)。
什么是主从复制
通过配置slaveof命令或slaveof选项，可以复制当前服务器(在slave中指定的服务器)的内容。 复制的服务器称为主服务器)，对主服务器执行复制操作的称为从服务器) slave
主服务器master可以读写操作，当主服务器的数据发生更改时，master会发出命令流以保持对salve的更新，但从服务器的slave通常是只读的，且从属服务器的slave-read-only 在主从复制模式下，即使主服务器宕机，slave也将成为主服务器，无法进行写入操作
一个大师可以有多个slave。 也就是说，一个主节点很多，而slave可以接受其他slave连接，形成“主从链”层叠结构(层叠结构)，从Redis 4.0开始，所有sub-slave 如下图所示
主从拷贝的好处：
冗馀数据，实现数据热备份故障恢复，避免单点故障导致的服务读写分离，实现负载平衡。 主节点负责读写，从节点负责读取，提高服务并发量的高可用性基础是哨兵机制和集群实现的基础主从复制配置
设置主和从复制相对简单。 在要从服务器进行slave的配置文件中设置slaveof选项，或直接使用slaveof命令
现在，让我们使用三台虚拟机进行构建。 主服务器的ip为192.168.249.20，两个从服务器的ip分别为192.168.249.21和192.168.249.21，端口号为6379。 具体配置不需要按以下方式额外配置主服务器： 这里先开三台
添加了从服务器配置slaveof的选项，并在5.0版中使用了replicaof而不是slaveof。
虽然可以继续使用slaveof，但建议使用复制of。 如果使用命令行进行复制，则重新启动后无效
配置redis.conf后，我们分别启动了三台服务器，以便用户可以指示info replication显示复制信息
然后，可以将数据写入主服务并从其他服务读取数据
接下来，如果尝试向从服务器写入数据，则会通知无法向只读从服务器写入数据
如果需要在slave中验证主复制，则必须在主服务器上设置“请求路径”选项并设置密码。 如果需要从服务器使用密码，请使用config set masterauth命令或在配置文件中设置masterauth
主从式复制的实现原理
主从复制的结构还很简单，下面我们来看看主从复制的实现原理
Redis的主从复制过程大致分为三个阶段：连接建立、数据同步和命令传播
建立连接
此阶段主要是从服务器发出slaveof命令后，如何与主服务器建立连接和准备数据同步的过程。
1 )执行slaveof命令后，从服务器根据设置的主服务器ip地址和端口创建到主服务器的套接字连接，连接成功后，从服务器将专用处理器与该套接字相关联，后续
2 )建立连接后，从服务器向主服务器发送ping命令，确认主服务器是否可用以及当前是否可用，并接受处理命令。 有来自主服务的充裕的发卡响应的说明时可以使用。 否则，它可能是网络超时或主服务阻塞，将断开与服务器的连接并开始重新连接
3 )认证。 如果主服务器上设置了requirepass选项，则从属服务器必须设置masterauth选项，验证密码是否匹配，然后才能通过认证
4 )认证完成后，从服务器发送自己的监听端口，主服务器被保存
数据同步
主从服务器建立连接并确认各自身份后，开始数据同步，从服务器向主服务器发送PSYNC命令，执行同步操作，将自身的数据库状态更新为主服务器的数据库状态
Redis的主从同步分为完全重新同步和部分重新同步partial resynchronization
完全重新同步
完全重新同步有两种情况。 一种是master在slave连接上首次重新同步
制的时候；二是如果当主从断线，重新连接复制的时候有可能是完整重同步，这个在后面说下面是完整重同步的步骤
从服务器连接主服务器，发送SYNC命令主服务器接收到SYNC命名后，开始执行bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令主服务器basave执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令从服务器收到快照文件后丢弃所有旧数据，载入收到的快照主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令部分重同步
部分重同步是用于处理断线后重复制的情况，先介绍几个用于部分重同步的部分
runid(replication ID)，主服务器运行id，Redis实例在启动时，随机生成一个长度40的唯一字符串来标识当前节点offset，复制偏移量。主服务器和从服务器各自维护一个复制偏移量，记录传输的字节数。当主节点向从节点发送N个字节数据时，主节点的offset增加N，从节点收到主节点传来的N个字节数据时，从节点的offset增加Nreplication backlog buffer，复制积压缓冲区。是一个固定长度的FIFO队列，大小由配置参数repl-backlog-size指定，默认大小1MB。需要注意的是该缓冲区由master维护并且有且只有一个，所有slave共享此缓冲区，其作用在于备份最近主库发送给从库的数据当slave连接到master，会执行PSYNC 发送记录旧的master的runid(replication ID)和偏移量offset，这样master能够只发送slave所缺的增量部分。但是如果master的复制积压缓存区没有足够的命令记录，或者slave传的runid(replication ID)不对，就会进行完整重同步，即slave会获得一个完整的数据集副本
PSYNC命令执行完整重同步和部分重同步的流程图
命令传播
当完成数据同步之后，主从服务器的数据暂时达到一致状态，当主服务器执行了客户端的写命令之后，主从的数据便不再一致。为了能够使主从服务器的数据保持一致性，主服务器会对从服务器执行命令传播操作，即每执行一个写命令就会向从服务器发送同样的写命令
在命令传播阶段，从服务器会默认以每秒一次的频率向主服务器发送心跳检测REPLCONF ACK 其中replication_offset是当前从服务器的复制偏移量，该命令的作用有三个
检测主从服务器的网络连接状态辅助实现min-slaves选项检测命令丢失关闭持久化时，复制的安全性
关于关闭持久化时，复制的安全性问题，可以参考官网的描述。
在使用Redis复制功能时的设置中，强烈建议在master和在slave中启用持久化。当不可能启用时，例如由于非常慢的磁盘性能而导致的延迟问题，应该配置实例来避免重置后自动重启。
为了更好地理解为什么关闭了持久化并配置了自动重启的 master 是危险的，检查以下故障模式，这些故障模式中数据会从 master 和所有 slave 中被删除：
我们设置节点 A 为 master 并关闭它的持久化设置，节点 B 和 C 从 节点 A 复制数据。节点 A 崩溃，但是他有一些自动重启的系统可以重启进程。但是由于持久化被关闭了，节点重启后其数据集合为空。节点 B 和 节点 C 会从节点 A 复制数据，但是节点 A 的数据集是空的，因此复制的结果是它们会销毁自身之前的数据副本。当 Redis Sentinel 被用于高可用并且 master 关闭持久化，这时如果允许自动重启进程也是很危险的。例如， master 可以重启的足够快以致于 Sentinel 没有探测到故障，因此上述的故障模式也会发生。
任何时候数据安全性都是很重要的，所以如果 master 使用复制功能的同时未配置持久化，那么自动重启进程这项应该被禁用