Redis的主从复制架构
这是一种基本的redis集群方式, 主要分离了 redis 的 读 和 写. 也为了解决 redis 单体 的不可靠性
- slaveof 192.168.1.1 6379 命令, 可以配置一个 从服务器 (redis 是支持动态的配置主从的. 因此才可以使用 config set slaveof 的命令开启从服务器的功能 )
- redis的主从复制, 基本都是由redis主服务器来进行同步 . 不过 之后 又出现了从从复制
- 关于主从复制, 有俩种策略, 一种是 全量复制 , 一种是 增量复制
具体流程
全局流程
- 首先从服务器配置好自己要同步的主服务器. 从服务器会发送 一个TCP 的请求 (这个时候 主服务器会认为是 客户端请求 )
- 发送 sync 命令 (这个命令也可以手动进行使用) (这个命令之后, 主服务器 就知道了 它是从redis 的身份, 用一个特殊的集合保存下来 这个实例)
- 主服务器收到 sync 命令 , 进行 bgsave 的操作, 生成 rdb的文件, 发送给 这个从服务器 (完成全量复制)
- 之后主redis 再收到 写命令, 就会对它记录的所有 从redis 进行一个 增量复制 , 传送这条写命令
- 如果某一个从服务器宕机 , 重启 之后. 又回到第一步 ( 只有的版本里面有优化过 )
一些小细节
在整个流程中, 主收到sync 命令之后, 会进行 bgsave … (这边会产生一个性能的问题 .) 因为 如果同一时间 如果多个从服务器一起连接… 可能导致 IO 繁忙. 所以 主redis , 可以使用一个延迟进行的操作, 在一段时间内连入的从服务器, 只生成一个 rdb文件
还有就是 , 如果主服务器上 并没有这么大的磁盘空间… 可以使用 无磁盘同步 , 可以设置 repl-diskless-sync
来配置 (2.8.18之后)
无磁盘同步, 就是直接使用网络, 对rdb 文件进行传输
全局流程中的优化
从redis 2.8开始, 对于流程中的第5部 , 如果一个服务器宕机重启, 也可以不是要用 全量同步, 还是使用 增量同步 进行同步
具体的做法是 :
- 主 redis 中, 维护着 每一个从机 同步的偏移量, key 是 从机的id
- 一个从机宕机连回来之后, 用id 去让主 redis 识别出来, 这也就可以从 偏移的位置 继续进行同步
- 如果识别不出来, 那就只能进行全量同步了
小细节
在主从复制架构中, 其实可以让主redis 不需要进行持久化, 持久化的工作都交给从redis 来做.
但是这样的情况下, 一定 要让 主redis 宕机之后, 不要自动重启, 需要先脱离环境, (要么变成从机 (重启时间长一些, 让sentinel 发现))
大概就这样了~.