2020-08-23---redis详细篇---主从复制

Redis的主从复制架构

这是一种基本的redis集群方式, 主要分离了 redis 的 读 和 写. 也为了解决 redis 单体 的不可靠性

• slaveof 192.168.1.1 6379 命令, 可以配置一个 从服务器 (redis 是支持动态的配置主从的. 因此才可以使用 config set slaveof 的命令开启从服务器的功能 )
• redis的主从复制, 基本都是由redis主服务器来进行同步 . 不过 之后 又出现了从从复制
• 关于主从复制, 有俩种策略, 一种是 全量复制 , 一种是 增量复制

具体流程

全局流程

1. 首先从服务器配置好自己要同步的主服务器. 从服务器会发送 一个TCP 的请求 (这个时候 主服务器会认为是 客户端请求 )
2. 发送 sync 命令 (这个命令也可以手动进行使用) (这个命令之后, 主服务器 就知道了 它是从redis 的身份, 用一个特殊的集合保存下来 这个实例)
3. 主服务器收到 sync 命令 , 进行 bgsave 的操作, 生成 rdb的文件, 发送给 这个从服务器 (完成全量复制)
4. 之后主redis 再收到 写命令, 就会对它记录的所有 从redis 进行一个 增量复制 , 传送这条写命令
5. 如果某一个从服务器宕机 , 重启 之后. 又回到第一步 ( 只有的版本里面有优化过 )

一些小细节

​ 在整个流程中, 主收到sync 命令之后, 会进行 bgsave … (这边会产生一个性能的问题 .) 因为 如果同一时间 如果多个从服务器一起连接… 可能导致 IO 繁忙. 所以 主redis , 可以使用一个延迟进行的操作, 在一段时间内连入的从服务器, 只生成一个 rdb文件

​ 还有就是 , 如果主服务器上 并没有这么大的磁盘空间… 可以使用 无磁盘同步 , 可以设置 repl-diskless-sync 来配置 (2.8.18之后)

​ 无磁盘同步, 就是直接使用网络, 对rdb 文件进行传输

全局流程中的优化

从redis 2.8开始, 对于流程中的第5部 , 如果一个服务器宕机重启, 也可以不是要用 全量同步, 还是使用 增量同步 进行同步

具体的做法是 :

1. 主 redis 中, 维护着 每一个从机 同步的偏移量, key 是 从机的id
2. 一个从机宕机连回来之后, 用id 去让主 redis 识别出来, 这也就可以从 偏移的位置 继续进行同步
3. 如果识别不出来, 那就只能进行全量同步了

小细节

在主从复制架构中, 其实可以让主redis 不需要进行持久化, 持久化的工作都交给从redis 来做.

但是这样的情况下, 一定 要让 主redis 宕机之后, 不要自动重启, 需要先脱离环境, (要么变成从机 (重启时间长一些, 让sentinel 发现))

大概就这样了~.