1. 前言

1.1 什么是复制？

1.1.1 复制概述

• 在redis中，用户可以通过执行 slaveof 命令 或者设置 slaveof 选项（我用的6.0，需要设置replicaof 选项），让一个服务器去复制（replicate）另一个服务器，我们称呼被复制的服务器为主服务器（master），而对主服务器进行复制的服务器则被称为从服务器（slave）。

1.1.2 主从复制的架构

• Redis Replication是一种 master-slave 模式的复制机制，这种机制使得 slave 节点可以成为与 master 节点完全相同的副本，可以采用一主多从或者级联结构。架构如下：
  

1.2 为什么要使用主从复制？

• 使用Redis主从复制的原因主要是单台Redis节点存在以下的局限性：
  1. Redis虽然读写的速度都很快，单节点的Redis能够支撑QPS大概在5w左右，如果上千万的用户访问，Redis就承载不了，成为了高并发的瓶颈。
  2. 单节点的Redis不能保证高可用，当Redis因为某些原因意外宕机时，会导致缓存不可用。
  3. CPU的利用率上，单台Redis实例只能利用单个核心，这单个核心在面临海量数据的存取和管理工作时压力会非常大。

1.3 主从复制主要的命令+配置

1. 查看当前角色命令：

   info replication
   

2. 从库配置（临时）命令

   slaveof 主库IP 主库端口
   

3. 从库配置（配置文件-永久）

   replicaof master的IP 6379
   

4. 反客为主命令

   slaveof no one
   

2. 准备工作

• 2至3台服务器或者虚拟机，最后3台吧，配置好主机名、IP地址和Redis环境

3. 核心配置

• 实现主从复制的配置要点：配从库不配主库。

3.1 主服务器

• 如下：

  daemonize yes
  
  # bind 127.0.0.1
  bind 0.0.0.0
  port 6379
  	
  requirepass redis
  
  loglevel notice
  logfile "/home/susu/soft/mkinstall/redis/redis-6.0.16/logs/redis-master.log"
  

3.2 从服务器

• 这里只看其中一台从服务器的配置即可，如下：

  daemonize yes
  
  bind 127.0.0.1
  port 6372
  
  loglevel notice
  logfile "/home/susu/soft/mkinstall/redis/redis-6.0.16/logs/redis-s1.log"
  
  # replicaof <masterip> <masterport>
  replicaof master的IP 6379
  
  # masterauth <master-password>
  masterauth redis
  

4. 实例演示

4.1 简单实例——两台服务器

4.1.1 同一服务多个redis实例——slaveof命令

• 我这里是一个简单的操作，没有复杂的配置，就是在一台服务器上配置了两个redis服务，一个6379的端口，一个6372的端口。
• 把 6379 作为 master 的话，需要在 6372 里执如下命令实现主从复制：

  slaveof 127.0.0.1 6379
  

  
  

4.1.2 两台服务

4.1.2.1 slaveof 临时连接

• 两台服务器，主服务，端口 6379 ，从服务器端口 6372，如下：

  slaveof 主服务器IP 6379
  

  其实与《4.1.1 同一服务多个redis实例》差不多，不截图了，如果有遇到connected_slaves:0 问题，看下面的6.1
• 这种临时模式存在的问题：从服务器重启后会失效，需要重新 slaveof 。

4.1.2.2 通过配置文件永久生效

4.1.2.2.1 主要配置

• 还是上面的两台服务器，主要配置如下：

  # replicaof <masterip> <masterport>
  replicaof 43.143.190.116 6379
  

4.1.2.2.2 查看效果

• 连接客户端，已经实现了主从复制，不用使用 slaveof 手动实现主从复制，如下：
  
  

4.1.2.2.2 注意事项

• 主服务器如果配置了密码，如下：

  # requirepass foobared
   requirepass redis
  

  那么，从服务器需要配置 masterauth 选项，如下：

  # masterauth <master-password>
  masterauth redis
  

4.2 简单演示——一主二从

• 两台从机的配置基本上是没啥差别的，这里不再说明
• 配置完成之后，master 里执行查看角色命令 info replication，可以看出下面挂着两个slave
  

5. 总结

5.0 下面参考网站地址：

• 推荐两篇写的不错的文章，如下：

  Redis主从复制原理.

5.1 主从复制的原理

• 从总体上来说，Redis主从复制的策略就是：当主从服务器刚建立连接的时候，进行全量同步；全量复制结束后，进行增量复制。当然，如果有需要，slave 在任何时候都可以发起全量同步。

5.1.1 主从全量复制

• Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份，具体步骤如下：

  • 首先，slave 启动，同步申请：
    slave启动成功后连接到master后会发送一个sync命令。
    slave首次全新连接master，一次完全同步（全量复制）将被自动执行，slave自身原有数据会被master数据覆盖清除。

  • master 首次连接，全量复制：
    master节点收到sync命令后会开始在后台保存快照（即rdb持久化，主从复制时会触发R D B），同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化完后，master将RDB快照文件和所有缓存的命令发送打所有slave，以完成一次完全同步。

    而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化。

5.1.2 进入平稳，增量复制

• Redis的增量复制是指在初始化的全量复制并开始正常工作之后，master服务器将发生的写操作同步到slave服务器的过程。
  增量复制的过程主要是master服务器每执行一个写命令就会依次向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令，完成同步。

5.1.3 从机下线，断点续传

• 当master-slave网络连接断掉后，slave重新连接master时，会触发全量复制，但是从2.8版本开始，slave与master能够在网络连接断开重连后，只从中断处继续进行复制，而不必重新同步，这就是所谓的断点续传。

  master会检查backlog里面的offset，master和slave都会保存一个复制的offset，还有一个masterId，offset是保存在backlog中的，master只会把已经复制的offset后面的数据复制给slave。

5.2 主从复制的好处

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：如果master宕掉了，使用哨兵模式，可以提升一个 slave 作为新的 master，进而实现故障转移，实现高可用
3. 负载均衡：可以轻易地实现横向扩展，实现读写分离。
   一个 master 用于写，多个 slave 用于分摊 读 的压力，从而实现高并发；

5.3 主从复制的缺点

• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
• 如果master挂了的话，默认情况下不会在slave节点中自动重选一个master，如果每次都人工干预的话也不太现实。

5.4 主从复制过程的几大注意点

• 如果是通过配置文件实现的主从复制：
  1. 从机不能操作写命令，只能读，从而体现读写分离。
  2. 主机shutdown后，从机不会上位，但是主机重启后，主从关系依然存在。
  3. 某从机shutdown后，主机还在继续，当从机重启后主从关系还在，并实现主机所有复制。

6. 配置常见的问题

6.1 connected_slaves:0

6.1.1 问题描述

• 问题描述：
  进行主从连接配置时，主服务器使用 info replication 查到的 connected_slaves数一直是0。
  
  

6.1.2 connected_slaves:0 之 网络问题

6.1.2.1 查找问题

• 先看从服务器上的日志，如下：

  11176:S  * Connecting to MASTER 主服务器IP:6379
  11176:S  * MASTER <-> REPLICA sync started
  11176:S  # Error condition on socket for SYNC: Connection refused
  

  
• 连接被拒绝了，然后我们 telent一下端口，是不通的

  telnet master的IP 6379
  

  

6.1.2.1.2 解决问题

• 第一步：修改主服务器上的配置文件里的 bind 选项

  • 我这里将 bind 127.0.0.1 暂且改为了bind 0.0.0.0

    # bind 127.0.0.1
    bind 0.0.0.0
    

  • 关于bind的更多解释，如下：
    • bind 配置的用法：bind配置了什么ip，别人就得访问bind里面配置的ip才访问到redis服务。
    • 官方说明，bind是用于，在一台redis服务器中有多块网卡的场景下。如果不配置 “bind”,redis会监听来自宿主机器上所有网卡的请求，官方认为这是很危险的。
    • bind默认的是 127.0.0.1，说明只能用redis宿主机的redis-cli去访问redis，不允许网络上其他主机访问。
    • 所以，要解决这个报错，比较推荐的做法是：配置宿主机的内或外网ip（redis从服务器 能访问的到的ip)。
      或者将bind 127.0.0.0 改为 bind 0.0.0.0，这配置表明接收所有网卡的请求。

• 第二步：再尝试一下 telnet，看到从服务器已经能访问了
  
  好了，主服务器上再次执行 info replication 命令查看，可以看到问题已经解决了
  

6.1.3 connected_slaves:0 之 密码问题

• 首先，看日志是不是这方面的问题：
  

• 然后，查看master上配置的密码:

  requirepass redis
  

  

• 接着再设置从服务器的 masterauth

  # masterauth <master-password>
  masterauth redis
  

  
  好了，设置完之后，重启从服务器，问题解决！

6.2