Redis——集群环境部署

一般情况下的Redis，我们都是在一台服务器上进行操作的，也就是说读、写以及备份操作都是在一台Redis服务器上进行的。随着项目访问量的增加，对Redis服务器的操作也更加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时。为了解决访问量大的问题，通常会采取的一种方式是主从（Master-Slave）复制。Master以写为主，Slave以读为主，Master更新后根据配置自动同步到Slave。本节中Master表示主节点，Slave表示从节点，以后不再赘述。

主要介绍Redis集群环境部署，讲解主从复制、哨兵模式和Redis集群。

1、主从复制

主从复制也叫主从模式，当用户向Master写入数据时，Master通过Redis同步机制将数据文件发送至Slave，Slave也会通过Redis同步机制将数据文件发送至Master以确保数据一致，从而实现Redis的主从复制。如果Master和Slave之间的连接中断，Slave可以自动重连Master，但是连接成功后，将自动执行一次完全同步。

配置主从复制后，Master可以负责读写服务，Slave只负责读服务。Redis复制在Master这一端是非阻塞的，也就是说在和Slave同步数据的时候，Master仍然可以执行客户端的命令而不受其影响。

1.1、主从复制的特点

同一个Master可以拥有多个Slave。
Master下的Slave还可以接受同一架构中其他Slave的连接与同步请求，实现数据的级联复制，即Master→Slave→Slave模式。
Master以非阻塞的方式同步数据至Slave，这将意味着Master会继续处理一个或多个Slave的读写请求。
主从复制不会阻塞Master，当一个或多个Slave与Master进行初次同步数据时，Master可以继续处理客户端发来的请求。
主从复制具有可扩展性，即多个Slave专门提供只读查询与数据的冗余，Master专门提供写操作。
通过配置禁用Master数据持久化机制，将其数据持久化操作交给Slave完成，避免在Master中有独立的进程来完成此操作。

1.2、主从复制的优势

避免Redis单点故障。
做到读写分离，构建读写分离架构，满足读多写少的应用场景。

1.3、Redis主从复制原理

当启动一个Slave进程后，它会向Master发送一个SYNC命令，请求同步连接。无论是第一次连接还是重新连接，Master都会启动一个后台进程，将数据快照保存到数据文件中，同时Master会记录所有修改数据的命令并将其缓存在数据文件中。

后台进程完成缓存操作后，Master就发送数据文件给Slave，Slave将数据文件保存到硬盘上，然后将其加载到内存中。接着Master就会把所有修改数据的命令发送给Slave。

若Slave出现故障导致宕机，那么恢复正常后会自动重新连接。Master收到Slave的连接请求后，将其完整的数据文件发送给Slave。如果Mater同时收到多个Slave发来的同步请求，那么Master只会在后台启动一个进程保存数据文件，然后将其发送给所有的Slave，确保Slave正常。

Redis主从复制环境使用的服务器资源如下表所示，将Redis安装在3台服务器上，3台服务器的操作系统都是CentOS 7：
在这里插入图片描述

1.4、Redis主从复制安装过程

1.4.1、Master操作

在Redis主服务器上的redis.conf配置文件中修改bind字段，将以下内容：

bind 127.0.0.1

修改为Master的主机IP地址：

bind 127.0.0.1 192.168.11.10

如果Redis主服务器只绑定了127.0.0.1，那么跨服务器IP地址的访问就会失败，也就是只有本机才能访问，外部请求会被过滤，这是由Linux的网络安全策略管理的。如果绑定的IP地址只是192.168.11.10，那么本机通过localhost和127.0.0.1，或者直接输入命令redis-cli登录本机Redis就会失败。所以跨服务器访问Redis，需要加上服务器IP地址才能被访问。

运行Redis服务：

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

1.4.2、Slave1操作

修改Redis的配置文件：

$ vi /usr/local/redis/conf/redis.conf

添加Master的IP地址与端口：

slaveof 192.168.11.10 6379

添加Mater的IP地址和端口时，中间用空格分隔，然后保存redis.conf配置文件。

运行Slave1（192.168.11.11）的Redis：

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

查看Slave1运行日志，如下图所示：
在这里插入图片描述
查看Master运行日志，如下图所示：

1.4.3、Slave2操作

修改Redis的配置文件，添加Master的IP地址与端口：

$ vi /usr/local/redis/conf/redis.conf
slaveof 192.168.1.10 6379

添加Master的IP地址和端口时，中间用空格分隔，然后保存redis.conf配置文件。

运行Slave2（192.168.11.12）的Redis：

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

查看Slave2运行日志，如下图所示：
在这里插入图片描述
结果与Slave1类似，只不过Slave2与Slave1（192.168.11.11:6379）建立连接，在同步数据时，Redis的主从级联复制便是这样：Master→Slave1→Slave2。

2、哨兵模式

2.1、灾备切换Sentinel的使用

Redis 2.6中开始提供了哨兵模式，到Redis 2.8以后的版本中该模式正式稳定。哨兵（Sentinel）进程监控Redis集群中Master主服务器工作的状态，在Master发生故障的时候，可以实现Master和Slave的切换，保证系统的高可用性。哨兵模式的出现是为了解决主从复制的缺点，其架构如下图所示：
在这里插入图片描述

2.1.1、哨兵模式的基本概念

Master节点：主节点，Redis的主数据库，写入都在这个节点上。
Slave节点：从节点，Redis的从数据库，读取都在这个节点上。
Sentinel节点：哨兵节点，监控各个节点的状态。

基于哨兵模式的高可用架构如下图所示：
在这里插入图片描述
在这个架构中，复制主要是将主节点的数据同步到从节点，这样做主要有以下两个原因：

一旦主节点宕机了，从节点可以作为主节点的备份随时成为新的主节点。
从节点可以作为主节点分担读的压力。

2.1.2、哨兵进程的作用

监控（Monitoring）：哨兵进程会不断地检查Master和Slave是否运作正常。
提醒（Notification）：当被监控的某个节点出现问题时，哨兵进程可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic Failover）：当一个Master不能正常工作时，哨兵进程会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master。当客户端试图连接失效的Master时，Redis集群也会向客户端返回新Master的地址，使得Redis集群可以使用现在的Master替换失效Master。Redis Sentinel故障转移架构如下图所示。
配置提供者：在哨兵模式下，客户端在初始化时连接的是哨兵节点集合，从中获取主节点的信息。

在这里插入图片描述

2.1.3、部署技巧

在生产环境中Sentinel节点不应该部署在一台物理“计算机”上。
在生产环境中部署至少3个且奇数个Sentinel节点。

2.2、Redis Sentinel的安装与配置

我们配置一个（Master）和两个（Slave），并在一台服务器上部署Redis服务器和Sentinel实例。哨兵模式的实验环境如下表所示：
在这里插入图片描述
Redis Sentinel的主从架构如下图所示：

3、Redis集群

Redis集群是一个由多个主从节点组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群将所有数据存储区域划分为16384个槽（Slot），每个节点负责一部分槽，槽的信息存储于每个节点中。Redis集群要将每个节点设置成集群模式，它没有中心节点，可水平扩展，它的性能和高可用性均优于主从模式和哨兵模式，而且集群配置非常简单。Redis集群架构如下图所示：
在这里插入图片描述
从Redis集群架构中可以很容易地看出，首先将数据根据散列规则分配到6个槽中，然后根据循环冗余校验（Cyclic Redundancy Check，CRC）算法和取模算法将6个槽分别存储到3个不同的Master节点中，每个Master节点又配套部署了一个Slave节点，当一个Master节点出现问题后，Slave节点可以顶上。相较于哨兵模式，这种方案的优点在于提高了读写的并发率，分散了I/O，在保障高可用性的前提下提高了性能。

3.1、Redis集群环境

Redis集群在物理结构上是由集群上的多个节点构成的，这些节点分为两类，一类叫“主节点”，另一类叫“从节点”。
Redis集群节点要求如下：

主节点不能少于总节点的一半。
主节点至少要有3个。

一个Redis集群正常工作至少需要3个主节点且不能少于总节点的一半，本集群环境使用一台节点服务器，在这台服务器开启6个Redis实例，每个Redis实例占用一个端口，模拟3个主节点和3个从节点环境，组成一个Redis集群。本书使用一台服务器部署6个Redis实例，也可以多台服务器部署Redis集群，只修改Redis配置文件redis.conf的IP地址就可以了。本集群实验采用三主三从模式，每个主节点处理各自的数据，提供读写能力，每个从节点异步复制主节点的数据。Redis 5集群的实验环境如下表所示：
在这里插入图片描述

3.2、Redis集群搭建

创建的Redis集群信息：
在这里插入图片描述
Redis集群有三个主节点和三个从节点，一个主节点对应一个从节点，形成一对一的对应关系，如下图所示：

3.3、Redis集群代理

集群代理（Cluster Proxy）是Redis 6的新特性。Redis集群代理（Redis Cluster Proxy）允许Redis客户端不需要知道集群中的具体节点个数和主从身份，直接通过集群代理访问集群。对于客户端来说，通过集群代理访问集群就和访问单机的Redis服务器一样，可以解除很多集群的使用限制。Redis集群代理架构如下图所示：
在这里插入图片描述