大家好，我是此林。
在生产环境上，Redis 一般都不会单节点部署，主从集群是 Redis 集群部署的一种方案。
下面是 Redis 主从集群的一种最简单的方式。
1. 优点
主从集群的优点主要有两个：
- 读写分离。主节点负责客户端写操作，从节点客户端负责读操作，提高读写性能。而且一般我们从节点会部署多台，很适合 Redis 读多写少的场景。
- 保证高可用。一台 slave 宕机了，还可以从其他 slave 读数据。
2. 主从集群配置
主从集群的配置也很简单，有两种方法。
- 配置文件（永久生效）：在从节点上的 redis.conf 文件中添加一行配置。
bash
slaveof <masterip> <masterport>- 命令行（重启失效）：在从节点的 redis-cli 客户端命令行输入下面命令。（注：把 slaveof 换成 replicaof，效果一致）。
bash
slaveof <masterip> <masterport>3. 主从集群原理
当从节点上执行 slaveof <masterip> <masterport> 命令时，master 和 slave 会经历3个阶段。
1. 第一阶段
- slave 和 master 建立连接，slave 向 master 请求数据同步，携带 replid 和 offset
- master 根据 replid 判断是否是第一次同步，是第一次同步，返回主节点的 replid 和 offset。
- slave 保存设置版本信息，设置 replid 和 主节点一致。
2. 第二阶段
- master 执行 bgsave，fork() 一个子进程后台生成 RDB 文件。
- 由于在生成 RDB 文件期间，master 还可以接收客户端的写命令，这些命令暂时写入 repl_baklog 缓冲区文件中。
- RDB 生成完了，master 向 slave 发送 RDB 文件。slave 清空本地数据，加载 RDB 文件。
3. 第三阶段
- master 向 slave 发送 repl_baklog 文件中的命令
- slave 执行接收到的命令。
需要说明的是，主从第一次同步时 全量同步。 后续同步时，由于 slave 和 master 的 replid 一致了，master 会认为无需全量同步，开始 增量同步。
增量同步：
每次同步时（即：master 向 slave 发送 repl_baklog 缓冲区中的命令），master 会记录 slave 同步 repl_baklog 的 offset（即：slave 同步到 repl_baklog 哪里了）
master 每次执行客户端写操作后，把命令记录到 repl_baklog 中，也会记录 master 在 repl_baklog 中的offset。
master 和 slave 的 offset 差值就是，slave 尚未同步的部分。
4. repl_baklog
如下图，就是 repl_baklog 示意图。
repl_baklog 是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。
repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset。
5. slave 宕机导致的主从数据不一致问题
考虑下面的情况：
-
如果有个 slave 宕机了很久，slave 宕机期间，master 还在接收写命令，offset 不断地在 repl_baklog 中前移。
-
repl_baklog 写满后，乃至 master 的 offset 转了一圈，又超过了 slave 的 offset，那么之前的命令数据就会被覆盖。
-
这个时候 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） 来解决了。请看下一章。