概述

• Redis 的单机模式实际上就是在一个服务器上装了一个单节点的Redis
• 通过简单的配置和简单的命令启动起来就可以使用
• 这种搭建环境，不保证高可用的情况下，完全没有问题
• 如果说你的项目必须要具备高可用，而且 Redis 也要提供更高的性能
• 这个单机的模式肯定是不行的, 需要对 Redis 的架构模式进行升级
  • 升级的过程：从单机变为主从，再变为哨兵
  • 最后搭建一个集群的环境

1 ）单机环境的优缺点

• 优点

  • 部署简单
    • 下载，编译安装
    • 通过一些简单的命令启动就可以使用
  • 成本低
    • 单机搭建不复杂，搭建成本低
    • 多机器则复杂，搭建和资金成本高，节点多了管理成本也高
  • 不需要考虑数据最终一致性

• 缺点

  • 可靠性低，可能会有节点故障
  • 性能受限于当前cpu，内存和磁盘

2 ) 架构升级

• 实际上开发中，Redis必然是高可用的，所以单机模式并不是我们的终点
• 我们需要对目前Redis架构模式进行升级，先整一个主从复制读写分离的环境
• 我们需要注意以下几点
  • 了解主从复制和读写分离的意义
  • Redis主从复制的环境搭建
  • 了解主从复制的原理和流程，如何保证复制一致性
  • 了解全量同步与部分同步
  • 主从复制的配置和查看复制过程 log 日志

主从复制

• 围绕着这张图, 可以看到多个客户端发起了读写的操作
• 这些读写的操作都落在了master这个节点上 (先不考虑 slave 从节点)
• 把这个 master节点 当成之前的单机，客户端所有的读写，都在这个单节点上
• 在并发比较少的情况下，完全没有任何问题，当并发现在上来了
• 无非就是读和写的请求多了，性能降低了，不能在第一时间内反馈你结果
• 或者说在大量的读的请求下，我们要去写数据，不能及时保证数据落盘
• Redis 的大部分应用场景是缓存，缓存有一个特性：读多写少
• 基于这个根本的问题，我们解决方案是：把读的压力释放出去
• 这就有了 Redis 的主从复制读写分离的环境，就是这么来的
• 它的目标也非常简单，就是把读压力释放出去
• 所以说我们就多来几个节点，这些节点就只扮演只读的这个角色
• 这里的从节点，它就是读操作，它不能写，注意：这个也不是绝对的
• 因为在 Redis 的配置文件里边，也可以开启从节点读写的配置，一般生产不会这么操作

1 ）场景演绎

• 现在咱们有10万的并发，搞了两个从节点，并发变成15万了，或者说20万了
• 当现在这个主从的环境，两个从节点依然不够用了，就可以再来一个从节点
• 所以说在这种模式下，大家可以发现我们只需要一个主节点就够了
• 因为，我们项目中实际上用 Redis 的写操作是比较少的
• 业务场景主要的定位就是缓存，所以写操作是比较少的
• 一般就只要一个主节点就可以轻松应对，无非就是要释放读压力
• 并发无休止的在增长，那你就根据当前的并发去扩展从节点即可
• 我们需要考虑的问题是：当无休止的扩展从节点，它们内部的数据是不是都是一致的

2 ）主从模式的优缺点

• 优点
  • 分成了 master/slave 主从角色，各司其职，写操作落在了主节点上，读操作分配给从节点
  • 当并发上来后，可以很方便的进行扩展，不停地加机器来提高读性能
  • 当主节点宕机后，可以手动把一个从节点升级为一个主节点的 (这里为哨兵的应用埋下伏笔)
• 缺点
  • 数据冗余，比如说主节点上有 10 T 的数据，那从节点也要有 10T 的数据
  • 主从之间会有一个同步数据的过程，在这个过程中，会有全量拷贝和增量拷贝
  • 所谓 全量拷贝
    • 环境搭建好之后，突然并发上来了，
    • 需要去扩展从节点，扩展一个新的从节点进来之后
    • 它第一次跟主节点建立连接关系的时候，它的这个节点上有没有数据
    • 它要把主节点所有的数据全部复制过来，才能提供读的支持
    • 这个时候，它就要做一次全量的复制
  • 所谓 增量拷贝
    • 随着后续客户端的写操作到主节点，根据RDB和AOF模式和心跳机制
    • 从节点和主节点持续通信，就可以把客户端写入的数据复制过来，写一个复制过来一个
    • 这就是增量复制
  • 这意味着，主节点有多少数据，从节点就有多少数据，这个存储压力会越来越成为一个问题
  • 但不要着急，集群是一种分片的机制，解决了存储的压力
  • 另一方面，单独去看 master, 只是一个单节点，没有释放写压力，也会有单点故障
  • 一般我们不会频繁的给 Redis 写数据, 除非有相应的使用场景，这个问题在集群中解决
  • 后期通过哨兵配合，自动切换
  • 最后，master 这个单机性能受限于自身配置

环境搭建

• 现在搭建一主两从的环境，准备3台机器

• 准备环境

  IP	角色
  192.168.10.101	Master
  192.168.10.102	Slave
  192.168.10.103	Slave

• 每台机器上都要进行安装 Redis 和相关配置

  # 创建配置目录
  mkdir -p /usr/local/redis/conf
  # 创建数据目录
  mkdir -p /usr/local/redis/data
  # 创建日志目录
  mkdir -p /usr/local/redis/log
  # 创建配置文件
  vim /usr/local/redis/conf/redis.conf
  

• 3台 Redis 节点对配置文件进行编辑，如下

  • 主节点配置

    # 放行访问IP限制，这个需要根据可信ip来配置，目前这个 0.0 做演示
    bind 0.0.0.0
    # 后台启动
    daemonize yes
    # 日志存储目录及日志文件名
    logfile "/usr/local/redis/log/redis.log"
    # rdb数据文件名
    dbfilename dump.rdb
    # aof模式开启和aof数据文件名
    appendonly yes
    appendfilename "appendonly.aof"
    # rdb数据文件和aof数据文件的存储目录
    dir /usr/local/redis/data
    # 设置密码
    requirepass 123456
    # 从节点访问主节点密码（必须与 requirepass 一致）
    masterauth 123456
    # 从节点只读模式
    replica-read-only yes
    

  • 从节点配置, 除了上述配置，还要添加下面额外的配置

    # 从节点，属于哪个主节点
    slaveof  192.168.10.101  6379
    

• 配置好之后，把 3台 Redis 实例分别运行起来

  • $ redis-server /usr/local/redis/conf/redis.conf

• 现在可以访问测试三台节点, 我们从主节点上来进行连接测试

• $ bin/redis-cli -a 123456 这里仅作为演示，可以通过 auth 来授权登录

• 因为这个是主节点，我们看下主从配置 $ info replication

  

• 再来看下从节点的主从配置 $ info replication

  

• 现在，我们来测试下：主节点可读可写，从节点只能读，不能写的功能

  • 在主节点：
    • $ set username wang 正常
    • $ get username 正常
  • 在从节点：
    • $ get username 正常
    • $ set age 18 发现报错：(error) READONLY You can’t write against a read only replica.

• 这样，我们就搭建测试完毕了