redis|redis集群搭建之主从复制缓存|nosql|redis

前期准备

把安装的三个redis服务全部停掉

文章图片
建立一个redistest文件夹，把三个redis实例的配置文件复制一份到这里

文章图片

修改配置文件：让日志在控制台输出

关闭后台运行

文章图片

文章图片

关闭aof

文章图片

启动redis ，发现日志全部打印到了控制台

文章图片

主从复制设计图

文章图片

通过命令行手动启动 【redis|redis集群搭建之主从复制】5.0版本以前命令是SLAVEOF, 5.0以后的版本是REPLICAOF 127.0.0.1 6379
1.启动所有的redis实例的服务端和客户端
1.我们把6379实例当做主节点，6380和6381当做从节点
2.在6380客户端执行命令REPLICAOF 127.0.0.1 6379，返回ok

文章图片

3.然后我们查看6379服务端的日志输出;

文章图片

4. 查看6380的日志输出

文章图片

从主节点和从节点的日志输出，我们可以看出，复制过程是：

文章图片

测试效果：

文章图片

文章图片

从节点只能不能写，可以通过修改主节点的配置文件进行调整 replica-read-only yes
思考1：从节点挂掉后，又立刻恢复了，这时候主节点对从节点是进行全量同步数据还是只同步从节点挂掉后，写入的数据？
查看从节点重启的日志

文章图片

主节点的日志：

文章图片

说明：从节点挂掉后，再重启，主节点只发送增量的数据，并不是全量同步，原因是我们采用的rdb持久化方式，在rdb文件中会记录一个id，这样下次同步数据的时候就能判断出只做增量同步，如果我们采用AOF，我们可以看到aof文件中是没有那个id的，所以每次都是进行全量同步；
rdb增量同步，AOF全量同步
思考2 ：如果主机挂了，那这个服务就只能读不能写了，那我们该如何切换？
这时候我们可以通过命令replicaof no one 把一个从节点变为主节点，然后让另一个从节点去追随

文章图片

文章图片

通过配置进行主从复制

文章图片

主从复制的配置讲解

replica-serve-stale-data yes: 如果设置为yes, 主节点向从节点同步数据的这个过程中，从节点依然可以响应客户端的请求，将数据返回给客户端，设置为no, 在这个过程中从节点是不响应客户端的请求，会返回错误（SYNC with master in progress）
replica-read-only yes：从节点是否只读，yes表示只读，no表示读写都可以
repl-diskless-sync no ：这是在设置主从数据同步的方式， no表示从节点先落到磁盘，通过网络IO将RDB文件发送给从节点，从节点数据落到磁盘，然后加载进内存，yes表示主节点和从节点省去了落磁盘的过程，主节点直接把内存的数据通过网络IO发送给从节点内存；
repl-backlog-size 1mb ：如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。因此主节点会维护一个缓冲区，从库还未读取的操作被主库新写的操作覆盖的数据放入这个缓冲区，从库读取完后，再把缓冲区的数据同步，保证数据一致性，如果缓冲区的大小设置的比较小，会出现数据挤压，导致新的操作在缓冲区保存不下，就会触发全量同步
min-replicas-to-write 3 ；min-replicas-max-lag 10 ：在主从同步的时候：需要至少3个副本，且延迟<= 10秒

Redis 复制的非常重要的事实：

Redis 使用异步复制，slave 和 master 之间异步地确认处理的数据量
一个 master 可以拥有多个 slave
Redis 复制在 master 侧是非阻塞的。这意味着 master 在一个或多个 slave 进行初次同步或者是部分重同步时，可以继续处理查询请求。

当 master 关闭持久化时，复制的安全性

我们设置节点 A 为 master 并关闭它的持久化设置，节点 B 和 C 从节点 A 复制数据。
节点 A 崩溃，但是他有一些自动重启的系统可以重启进程。但是由于持久化被关闭了，节点重启后其数据集合为空。
节点 B 和节点 C 会从节点 A 复制数据，但是节点 A 的数据集是空的，因此复制的结果是它们会销毁自身之前的数据副本。
结论：当 Redis Sentinel 被用于高可用并且 master 关闭持久化，这时如果允许自动重启进程也是很危险的。例如， master 可以重启的足够快以致于 Sentinel 没有探测到故障，因此上述的故障模式也会发生。任何时候数据安全性都是很重要的，所以如果 master 使用复制功能的同时未配置持久化，那么自动重启进程这项应该被禁用。

Redis 复制功能是如何工作的 1.每一个 Redis master 都有一个 replication ID ：这是一个较大的伪随机字符串，标记了一个给定的数据集。每个 master 也持有一个偏移量，master 将自己产生的复制流发送给 slave 时，发送多少个字节的数据，自身的偏移量就会增加多少，目的是当有新的操作修改自己的数据集时，它可以以此更新 slave 的状态。复制偏移量即使在没有一个 slave 连接到 master 时，也会自增，所以基本上每一对Replication ID和 offset都会标识一个 master 数据集的确切版本。
2.当 slave 连接到 master 时，它们使用 PSYNC 命令来发送它们记录的旧的 master replication ID 和它们至今为止处理的偏移量。通过这种方式， master 能够仅发送 slave 所需的增量部分。但是如果 master 的缓冲区中没有足够的命令积压缓冲记录，或者如果 slave 引用了不再知道的历史记录（replication ID），则会转而进行一个全量重同步：在这种情况下， slave 会得到一个完整的数据集副本，从头开始。
Redis 复制如何处理 key 的过期 slave 不会让 key 过期，而是等待 master 让 key 过期。当一个 master 让一个 key 到期（或由于 LRU 算法将之驱逐）时，它会合成一个 DEL 命令并传输到所有的 slave。