辽宁建设委员会网站首页百度seo优化招聘

大家好，我是此林。

在生产环境上，Redis 一般都不会单节点部署，主从集群 是 Redis 集群部署的一种方案。

下面是 Redis 主从集群的一种最简单的方式。

1. 优点

主从集群的优点主要有两个：

• 读写分离。主节点负责客户端写操作，从节点客户端负责读操作，提高读写性能。而且一般我们从节点会部署多台，很适合 Redis 读多写少的场景。
• 保证高可用。一台 slave 宕机了，还可以从其他 slave 读数据。

2. 主从集群配置

主从集群的配置也很简单，有两种方法。

• 配置文件（永久生效）：在从节点上的 redis.conf 文件中添加一行配置。

slaveof <masterip> <masterport>

• 命令行（重启失效）：在从节点的 redis-cli 客户端命令行输入下面命令。（注：把 slaveof 换成 replicaof，效果一致）。

slaveof <masterip> <masterport>

3. 主从集群原理

当从节点上执行 slaveof <masterip> <masterport> 命令时，master 和 slave 会经历3个阶段。

1. 第一阶段

1. slave 和 master 建立连接，slave 向 master 请求数据同步，携带 replid 和 offset
2. master 根据 replid 判断是否是第一次同步，是第一次同步，返回主节点的 replid 和 offset。
3. slave 保存设置版本信息，设置 replid 和 主节点一致。

2. 第二阶段

1. master 执行 bgsave，fork() 一个子进程后台生成 RDB 文件。
2. 由于在生成 RDB 文件期间，master 还可以接收客户端的写命令，这些命令暂时写入 repl_baklog 缓冲区文件中。
3. RDB 生成完了，master 向 slave 发送 RDB 文件。slave 清空本地数据，加载 RDB 文件。

3. 第三阶段

1. master 向 slave 发送 repl_baklog 文件中的命令
2. slave 执行接收到的命令。

需要说明的是，主从第一次同步时 全量同步。后续同步时，由于 slave 和 master 的 replid 一致了，master 会认为无需全量同步，开始 增量同步。

增量同步：

1. 每次同步时（即：master 向 slave 发送 repl_baklog 缓冲区中的命令），master 会记录 slave 同步 repl_baklog 的 offset（即：slave 同步到 repl_baklog 哪里了）

2. master 每次执行客户端写操作后，把命令记录到 repl_baklog 中，也会记录 master 在 repl_baklog 中的offset。

3. master 和 slave 的 offset 差值就是，slave 尚未同步的部分。

4. repl_baklog

如下图，就是 repl_baklog 示意图。

repl_baklog 是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset。

5. slave 宕机导致的主从数据不一致问题

考虑下面的情况：

1. 如果有个 slave 宕机了很久，slave 宕机期间，master 还在接收写命令，offset 不断地在 repl_baklog 中前移。

2. repl_baklog 写满后，乃至 master 的 offset 转了一圈，又超过了 slave 的 offset，那么之前的命令数据就会被覆盖。

3. 这个时候 slave 重启了，怎么同步数据呢？

关键点：repl_baklog 写满后，乃至 master 的 offset 转了一圈，又超过了 slave 的 offset。

这个时候 slave 的 offset 小于 repl_backlog_first_byte_offset，那么 master 在去做同步会判断，就会和 slave 重新进行一次 全量同步，从而保证主从数据一致性。

repl_backlog_first_byte_offset 可以通过 命令 INFO replication 查看。

存在的问题

slave 宕机了还好说，如果 master 宕机了呢？

这个时候就要靠 哨兵（Sentinel） 来解决了。请看下一章。

浅谈 Redis 主从复制原理（二）-CSDN博客