Redis实战（一）| 主从复制&哨兵模式

Redis实战 | 主从复制

1. 主从复制架构图

2. 主从复制说明or注意事项

• 对于任意一个redis实例而言，其隶属的主节点只能有一个，但可以允许它有多个从节点。
• 从节点只能读数据，不能写数据（read only），而主节点可写可读（不会真有人都主从复制了还在主节点进行读吧？不会吧不会吧？）
• 当从节点重新连接上主节点时，从节点的所有数据都会删除，并从主节点同步所有的数据
• 在主从架构运行过程中，如果主节点不幸挂掉，那么重启之后它还是主机，主从复制操作也能够继续地进行（想起神话一说：今日我虽死，可我仍是西楚霸王，hiahia）。

3. 主从复制的实现

​ redis实现主从复制非常的方便，只需通过简单的配置即可，笔者因为没有那么多的服务器实例资源，所以就只能是在一台机器上开多个redis实例来模拟主从复制了，当然原理都是一样的，下面是具体的配置实现。

3.1 编写实例节点的配置文件

​ 配置文件redis.conf一式三份，用来模拟三个不同的redis实例

• redis6379：Master节点
• redis6380：Slave节点 1
• redis6381：Slave节点 2

• 具体的配置：

  • Master：6379

    # 主机地址
    bind 127.0.0.1
    
    # 端口号
    port 6379
    
    # 进程Id文件
    pidfile /var/run/redis_6379.pid
    
    # log文件存储路径
    logfile "redis6379.log"
    
    # RDB持久化文件存储路径
    dbfilename dump6379.rdb
    
    # 连接密码，看个人需要：有无必要设置
    requirepass redis6379
    

    • 当然还有其他的配置信息，比如RDB、AOF的开启，这里就不赘述了

  • Slave 1：6380

    # 主机地址
    bind 127.0.0.1
    
    # 端口号
    port 6380
    
    # 进程Id文件
    pidfile /var/run/redis_6380.pid
    
    # log文件存储路径
    logfile "redis6380.log"
    
    # RDB持久化文件存储路径
    dbfilename dump6380.rdb
    
    # 连接密码，看个人需要：有无必要设置
    requirepass redis6379
    
    # 配置主节点的主机地址和端口号，也可以在redis-cli命令行进行配置，命令跟配置一样
    slaveof 127.0.0.1 6379
    
    # 配置主节点的连接密码，如果Master节点设置了密码的话，一定要陪着，否则连接不上
    masterauth redis6379
    

  • Slave 2：6381

    # 主机地址
    bind 127.0.0.1
    
    # 端口号
    port 6381
    
    # 进程Id文件
    pidfile /var/run/redis_6381.pid
    
    # log文件存储路径
    logfile "redis6381.log"
    
    # RDB持久化文件存储路径
    dbfilename dump6381.rdb
    
    # 连接密码，看个人需要：有无必要设置
    requirepass redis6379
    
    # 配置主节点的主机地址和端口号，也可以在redis-cli命令行进行配置，命令跟配置一样
    slaveof 127.0.0.1 6379
    
    # 配置主节点的连接密码，如果Master节点设置了密码的话，一定要陪着，否则连接不上
    masterauth redis6379
    

  • 其他配置

    # 以守护进程的方式启动(懂得都懂？)，当然这不是主从复制的必要，这只是提了一下
    daemonize yes
    

3.2 启动实例

——这里以Linux命令行下的启动为例

# 启动主节点
redis-server redis6379.conf

# 启动两个从节点
redis-server redis6380.conf
redis-server redis6381.conf

3.3 查看实现结果

• 分别进入各个实例的redis-cli

  redis-cli -p [端口号:如6379] -a [密码：如redis6379]
  

• ps：这里的redis.conf的路径看个人，应该都懂，可以相对路径也可以绝对路径

• 查看主从复制的实现情况

  • 主要使用命令

    127.0.0.1:6379> INFO replication
    

  • 查看具体情况

    • Master：6379
      

    • Slave 1：6380
      

    • Slave 2：6381

• 至此就说明，我们的Redis主从配置就算完成啦？下面就测试一下？

3.4 测试主从复制结果

• 初始状态: 三个节点均无数据

• 向主节点写入数据
  

• 查看从节点的数据 ：同步复制了主节点的数据

系不系很神奇？Master节点写入的数据，从节点也有了，这就是主从复制的魅力所在。

3. 主从复制的原理

——主要还是全量同步和增量同步

• 步骤：

  • slave节点启动成功并连接到master节点后向其发送一个sync命令，即要求同步数据

  • Master节点接收到命令后启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令（也就是写数据的命令，如set k1 v1）

  • 后台进程收集写命令完之后，master将整个数据文件传送到slave，以实现一次完全同步

    • 全量复制：slave节点接收到master节点传来的数据库文件后，将其存盘并加载到内存中
    • 增量复制：Master继续将新的所有收集到的写命令依次传给slave，完成同步。

  • 只要是slave重新连接到master，就会自动执行一次完全同步（全量复制）

4. 主从模式的缺点及哨兵模式

​ 虽说主从模式能够实现读写分离，一定程度实现了高并发，高可用的目的，但是有木有想过，万一主节点挂了呢？而这种模式下又不能自动切换主节点身份，且从节点又是只读模式，这不就GG了？

​ 这就引出了哨兵模式了（即使我屎了，还有千千万万个我，哈哈哈）

4.1 哨兵模式概述

​ 哨兵模式就是说，在主从架构的基础上，加入主节点选举的功能。怎么说？就是当一个主节点挂了，能够从其他从节点重新选举出一个主节点，继续行使主节点的权利，而原先挂掉的主节点重启后不再是主节点，而是委身于新的主节点下（十年河东，十年河西？），除非新的主节点又挂了，再次选举主节点时或许可能会选到原先最初的主节点（风水轮流转？）。

4.2 哨兵模式的实现

• 注意：哨兵模式本质也是主从复制的架构，因此哨兵模式的实现前提是你已经配置好了主从复制

4.2.1 哨兵模式架构图

4.2.2 配置实现哨兵模式

• sentinel.conf的配置

  主要配置的是sentinel.conf，同样是一式三份，为了方便区分，这里就命名为sentinel [端口].conf

  三个节点的配置都是差不多的，主要是端口不一样，因此这里只给出一份配置信息

  # sentinel端口：
  port 26379
  
  # 主节点的地址以及宕机条件
  # 表示初始时的主节点时redis6379 】
  # 1表示当有一个sentinel认为主机挂掉了，就切换主机
  sentinel monitor mymaster 127.0.0.1 6379 1
  
  # sentinel进程id文件路径
  pidfile /var/run/redis-sentinel6379.pid
  
  # 以后台守护进程方式启动
  daemonize yes
  
  # master主机校验密码，与redis.conf的requirepass相对应
  # 用于主从复制哨兵的模式的多个实例redis的密码最好用同一个
  sentinel auth-pass mymaster redis6379
  

• 启动哨兵

  redis-sentinel sentinel6379.conf
  

  -方便起见，演示就启动一个哨兵就可以了，即用一个哨兵进行监控就好

4.2.3 测试哨兵模式

• 初始启动：Master节点为6379、Slave节点为6380、6381

  • 主节点 6379
    

  • 从节点1 6381
    

  • 从节点2 6380
    

• 尝试shutdown Master：6379

• 结果：故障转移：

  • Master节点选举结果：6380，即原先的Slave节点6380变成Master节点

• 而原先down掉的原Master节点6379,重启后变为slave节点

至此，哨兵模式的实现就完成了，测试过程就不写啦，无非就是切换前后：主节点写从节点读的测试！！