Redis: 主从复制读写分离环境搭建

概述

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

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.
这样，我们就搭建测试完毕了