redis集群-主从同步

一、Redis 复制
复制（Replication）：是 Redis 实现高可用的基础。且在复制过程中，主节点/从节点都是非阻塞的，但是从节点在执行同步时使用的是旧数据集提供查询。

Redis 复制启动图与流程说明：



1）、当从节点连接到主节点时，会发送 psync 命令给主节点，runId 是主节点的 ID；offset 是从节点保存复制偏移量，如果没有默认是 -1，主节点根据复制偏移量仅发送从节点所需的增量部分，如果是第一次复制则为 -1； 2）、如果主节点回复 +FULLRESYNC，那么从节点将触发全量复制流程； 3）、如果主节点回复 +CONTINUE，那么从节点触发部分复制； 4）、如果主节点回复 +ERR，说名主节点不支持该命令；

二、Redis 主从全量复制
主从复制：主机数据更新后根据配置和策略，自动同步到备机的 master/slaver 机制，Master以写为主，Slave以读为主。



三、Redis 主从部分复制


四、Redis 主从搭建
【1】修改主节点 redis.conf 文件：使用[./redis-server redis.conf]启动主节点。



1 bind 127.0.0.1
2 Port 7000
3
4 #是否开启保护模式，默认为 yes 是开启。要是配置里没有指定 bind 和密码。开启该参数后，redis只会本地进行访问，拒绝外部访问。
5 #要是开启了密码和 bind，可以开启。否则最好关闭，设置为no。
6 protected-mode no
7 #修改 redis 安全密码
8 requirepass "123456789"
9 # master 设置密码
10 masterauth "123456789"
11 #开启appendonly 模式后,redis 将每一次写操作请求都追加到appendonly.aof 文件中
12 appendonly yes


【2】新建从节点并配置复制主节点信息（配从(库)不配主(库)）每次与 master 断开之后，都需要重新连接，除非你配置进 redis.conf 文件 info replication（Redis Sentinel 还使用该信息来发现 slave 实例）

1 #slaveof 主库IP 主库端口
2 slaveof 127.0.0.0 7000
【3】Redis 主/从复制注意点：1）、主/从节点应启用持久化：master 和 slave 中应启用持久化。当由于性能要求不能启用持久化时，应配置实例避免自动重启，因为主节点未持久化又重启时，内存数据为空，会导致从节点同步主节点空数据。 2）、从节点应配置只读属性：主从复制中，从节点应配置只读属性[replica-read-only yes]。 3）、从节点应配置对主节点的验证：主节点通过 requirepass 配置了密码时，从节点应使用[masterauth <password>]配置对主节点的访问密码。 4）、主节点配置写查询接收条件：为了尽量保证主从一致性，主节点应配置当至少有 N 个 slave，并且滞后小于 M 秒时，才接收客户端写入命令[min-slaves-to-write <slave 数量> min-slaves-max-lag <秒数>]

五、主从复制常用3招
✘ 一主二仆： 一个 Master 两个 Slave； ✘ 薪火相传：上一个 Slave 可以是下一个 Slave 的 Master，Slave 同样可以接收其他 Slaves 的连接和同步请求，那么该 Slave 作为了链条中下一个的 Master，可以有效减轻 Master 的写压力。中途变更转向会清除之前的数据，重新建立拷贝最新的slaveof 新主库IP 新主库端口； ✘ 反客为主：SLAVEOF NO ONE。使当前数据库停止与其他数据库的同步，转成主数据库

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

复制的缺点：由于所有的写操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave 机器数量的增加也会使这个问题更加严重。

redis有俩种复制模式：Rdb和aof

redis持久化问题；会有数据损失吗，开启aof的持久化吗；

redis提供2种持久化方案。rdb和aof

redis有自己默认的持久化方案 （Rdb 方案）

Rdb(默认)：在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF：append only file。以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

优缺点：

相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。

由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。不过生产环境其实更多都是二者结合使用的。

常用配置

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。


（1）首先从节点根据当前状态，决定如何调用psync命令：

如果从节点之前未执行过slaveof或最近执行了slaveof no one，则从节点发送命令为psync ? -1，向主节点请求全量复制；
如果从节点之前执行了slaveof，则发送命令为psync <runid> <offset>，其中runid为上次复制的主节点的runid，offset为上次复制截止时从节点保存的复制偏移量。
（2）主节点根据收到的psync命令，及当前服务器状态，决定执行全量复制还是部分复制：

如果主节点版本低于Redis2.8，则返回-ERR回复，此时从节点重新发送sync命令执行全量复制；
如果主节点版本够新，且runid与从节点发送的runid相同，且从节点发送的offset之后的数据在复制积压缓冲区中都存在，则回复+CONTINUE，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可；
如果主节点版本够新，但是runid与从节点发送的runid不同，或从节点发送的offset之后的数据已不在复制积压缓冲区中(在队列中被挤出了)，则回复+FULLRESYNC <runid> <offset>，表示要进行全量复制，其中runid表示主节点当前的runid，offset表示主节点当前的offset，从节点保存这两个值，以备使用。