Redis （主从复制，哨兵模式，集群）概述及部署

语言

在Mysql数据库中为保证数据的高可用性，其有主从复制与MHA使用高可用。那么Redis如何实现高可用？本文接受Redis高可用实现的几种方式与服务搭建。

一，Redis主从复制

1.1 Redis主从复制概念

主从复制，是指将一台redis服务器的数据，复制到其他的Redis服务器，前者称为主节点（master），后者称为从节点（slave），数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点（或者没有从节点），但一个从节点只能有一个主节点。

2，Redis主从复制的作用

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式

故障恢复：当主节点出现问题是，可以从从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余。

负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写的服务，由从节点提供读的服务（即Redis数据时应用连接主节点，读Redis数据时应用连接从节点）分担服务器负载，尤其是在写少读多的场景下，通过多个从节点分担负载，可以大大提高Redis服务器的并发量。

高可用基础：除了上述作用以外，主从复制还是哨兵和集群能够实现的基础，因此说主从复制是Redis高可用的基础。

3，Redis主从复制的流程

3.1 Redis主从复制的搭建

主机IPmaster节点192.168.135.194slave1节点192.168.135.195slave2节点192.168.135.196
安装所以Redis（所以主机）

systemctl stop firewalld
setenforce 0
 
yum install -y gcc gcc-c++ make
 
tar zxvf redis-5.0.7.tar.gz -C /opt/
 
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
 
 
cd /opt/redis-5.0.7/utils
./install_server.sh
 
回车四次，下一步需要手动输入
 
Please select the redis executable path [] /usr/local/redis/bin/redis-server      
 
ln -s /usr/local/redis/bin/* /usr/local/bin/

3.2，关闭防火墙，查看Redis端口

[root@redis194 ~]#systemctl stop firewalld
[root@redis194 ~]#systemctl disable firewalld
[root@redis194 ~]#setenforce 0
[root@redis194 ~]#/etc/init.d/redis_6379 start
/var/run/redis_6379.pid exists, process is already running or crashed
[root@redis194 ~]#netstat -natp |grep 6379
tcp        0      0 192.168.135.194:6379    0.0.0.0:*               LISTEN      7031/redis-server 1 
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      7031/redis-server 1 
[root@redis194 ~]#redis-cli

3.3 修改master节点redis配置文件（192.168.135.194）

vim /etc/redis/6379.conf
bind 0.0.0.0                        #70行，修改bind 项，0.0.0.0监听所有网段
daemonize yes                        #137行，开启守护进程
logfile /var/log/redis_6379.log        #172行，指定日志文件目录
dir /var/lib/redis/6379                #264行，指定工作目录
appendonly yes                        #700行，开启AOF持久化功能
 
/etc/init.d/redis_6379 restart

3.4，修改slave节点Redis配置文件（slave1和slave2配置相同）

vim /etc/redis/6379.conf    #配置文件位置
70 bind 0.0.0.0    #修改监听地址
137 daemonize yes  #开启守护进程
172 logfile /var/log/redis_6379.log  #指定日志文件目录
264 dir /var/lib/redis/6379   #指定工作目录
288 replicaof 192.168.130.14 6379  #添加主服务器地址 及端口
700 appendonly yes   #开启AOF持久化功能
#保存，并启动服务
 
（2）#重启slave1节点和slave2节点redis服务
/etc/init.d/redis_6379 restart
 

之后重启

3.5 验证主从效果

在Master节点上验证从节点

** 主节点创建数据验证**

** 从节点认证**

** 从节点只能读，不能写**

二，哨兵模式

在主从复制的基础上起到主节点自动故障转移的作用

1，作用及原理

哨兵是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的Master并将所以slave连接到新的Master。所以整个运行哨兵的集群的数量不得少于3个节点

1，哨兵模式的作用

监控：哨兵会不断的检查主节点和从节点是否运作正常

自动故障转移：当主节点不能正常工作时，哨兵会自动开始故障转移操作，它会将失效节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

通知：哨兵可以将故障转移的结果发送给客户端。

2，哨兵模式的结构

哨兵结构由两部分组成，哨兵节点和数据节点

1，哨兵节点：哨兵系统由一个或者多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。

2，数据节点：主节点和从节点都是数据节点。

哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，
所以节点上都需要部署哨兵模式，哨兵模式会监控所有的Redis工作节点是否正常，
当Master 出现问题的时候，因为其他节点与主节点事情联系，因此会投票，
投票过半就认为这master的确出现问题，然后会通知哨兵间，
然后从slave中选取一个作为新的Master。

3，故障转移机制

1. 由哨兵节点定期监控发现主节点是否出现了故障
2. 每个哨兵节点每隔1秒向主节点，从节点及其它哨兵节点发送一次ping命令做一次心跳检查。
3. 如果主节点在一定时间范围内不回复或者是回复一个错误的消息，那么这个哨兵就会认为这个主节点主观下线了（单方面的）。
4. 当超过半数哨兵节点认为该主节点主观下线了，这样就客观下线了
5. 当主节点出现故障，此时哨兵节点会通过“选举算法”实现选举机制共同选举出一个哨兵节点为leader，来负责处理主节点的故障转移和通知。
6. 所以整个运行哨兵的集群的数量不得少于3个节点。

由leader哨兵节点执行故障，过程如下：

1. 将某一个从节点升级为新的主节点，让其他从节点指向新的主节点。
2. 若源主节点恢复也变从节点，并指向新的主节点；
3. 通知客户端主节点已经更换。

需要特别注意的是

客观下线是主节点才有的概率，如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

3.1，主节点选举

1. 过滤掉不健康的（已下线的），没有回复哨兵ping响应的从节点。
2. 选择配置文件中从节点优先级配置最高的。(replica-priority,默认值为100)
3. 选择复制偏移量最大，也就是复制最完整的从节点。

3.2，哨兵模式的部署

哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式

3.3，修改Redis哨兵模式的配置文件（所以节点操作）

#所有节点配置一样，如下所示
vim /opt/redis-5.0.7/sentinel.conf
 17 protected-mode no      #关闭保护模式
 21 port 26379             #Redis哨兵默认的监听端口
 26 daemonize yes           #指定sentinel为后台启动
 36 logfile "/var/log/sentinel.log"  #指定日志存放路径
 65 dir "/var/lib/redis/6379"        #指定数据库存放路径
 84 sentinel monitor mymaster 192.168.48.11 6379 2  #指定该哨兵节点监控192.168.48.11:6379这个主节点，该主节点的名称是mymaster,最后的2的含义与主节点的故障判定有关:至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
113 sentinel down-after-milliseconds mymaster 30000  #判定服务器down掉的时间周期，默认30000毫秒(30秒)
146 sentinel failover-timeout mymaster 180000        #146行，故障节点的最大超时时间为180000 (180秒 )
#保存配置文件
#先启动master，再启动slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

3.4，启动哨兵模式

#注意：先启master，再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

3.5查看哨兵信息

3.6 故障模拟

查看并杀死master节点的redis-server

查看哨兵信息

3.6 小节

哨兵模式基于主从复制。但主从复制在单点故障后无法自动恢复，导致服务无法实现高可用；
哨兵模式基于主从复制基础之上，添加哨兵节点检测；
当master宕机后，哨兵节点会通过投票选举方式，选举出新的master服务，保证服务的高可用性

四，Redis集群模式

1，什么事Redis集群模式？

Redis集群模式就是，可以解决写的操作无法负载均衡，存储收到单机限制，以及故障自动切换功能的一种集群。

集群由多个节点组成，Redis的数据分布在这些节点中。

集群中的节点分为主节点和从节点，只有主节点复制读写和集群信息的维护，从节点只进行复制主节点数据和状态信息。

2，集群的作用

** 1，数据分区：数据分区（或者数据分片）是集群最核心的功能。**

1. 集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；
2. 另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。
3. Redis单机内存大小受限问题。

2，高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任意节点发送故障时，集群仍然可以对外提供服务。

3，集群模式的数据分片介绍

1. Redis引入了哈希槽的概念。
2. Redis集群由16384个哈希槽
3. 集群的每一个节点负责一部分哈希槽
4. 每个key通过CRC算法后对16384取余来决定放置哪个槽位。
5. 再通过这个槽位到对应的节点，然后直接跳转到这个对应的节点上进行存取操作。

总的来说：就是cluster集群是分布式的，它可以将多个master当做一个整体来存放数据。并且cluster中有16384个slot（哈希槽），集群中的master来平分这些槽位。当需要由数据来存储到集群汇中时，需要使用CRC16算法得出一个结果，再将这个结果对16384取余，最后得到对应的槽位，根据槽位选定最顶存放的master节点。

如果有新的master节点加入，那么槽位该怎么分呢？

cluster集群会将现有得到每个slot移除一部分，每个master移除的solt加起来等于自己等下的即可；然后将槽位给到新加的master中。

slave节点怎么复制master节点的？

每个slave节点对应着自己的master，不仅同步的是master的数据，还同步master的槽位，当master宕机后，slave立马上来进行顶替。

如果slave节点也挂了，并且master节点还没有恢复，那么有一整个16384个槽位缺少了这一部分，就会导致整个集群无法使用。

4，Redis集群模式部署

Redis集群一般需要6个节点，三主三从。本次实验使用一台设备模拟三主三从。

4.1 服务器上部署好Redis服务

Redis集群一般需要6个节点，三主三从

本文使用一个服务器，模拟三主三从。

#在当前服务器配置6个redis服务
cd /etc/redis/
mkdir -p /etc/redis/redis-cluster/redis600{1..6}
cd redis-cluster/redis6001
#复制配置文件及程序到目录中
cp /opt/redis-5.0.7/redis.conf ./
cp /opt/redis-5.0.7/src/redis-cli ./
cp /opt/redis-5.0.7/src/redis-server ./

4.2 配置集群功能配置文件

[root@localhost redis6001]# vim redis.conf 
  69 #bind 127.0.0.1      #将其注释，即监听所有端口
  88 protected-mode no    #关闭保护模式
  92 port 6001            #为了区分，将端口更改，6个不能相同
  136 daemonize yes          #开启守护进程
  699 appendonly yes      #开启AOF持久化
  832 cluster-enabled yes #开启集群功能
  840 cluster-config-file nodes-6001.conf  #群集名称文件设置
  846 cluster-node-timeout 15000  #群集超时时间设置
  
#先配置好6001的配置文件，然后将这个配置文件拷贝到另外6002-6006中，并且，修改端口

#!/bin/bash
for i in {2..6}
do
rm -rf /etc/redis/redis-cluster/redis600$i/redis.conf
cp /etc/redis/redis-cluster/redis6001/redis.conf /etc/redis/redis-cluster/redis600$i
sed -i "s/port 6001/port 600$i/" /etc/redis/redis-cluster/redis600$i/redis.conf
sed -i "s/nodes-6001.conf/nodes-600${i}.conf/" /etc/redis/redis-cluster/redis600$i/redis.conf
done
#执行脚本一键替换其它的配置文件

** 修改6002-6006的配置文件**

4.3 启动Redis节点

#!/bin/bash
for i in {1..6}
do
cd /etc/redis/redis-cluster/redis600$i
redis-server redis.conf
done
#分别进入6个节点，进行服务启动redis-server redis.conf

4.4 启动端口

redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
# -replicas 1   表示每个主节点有1个从节点
#若使用6台服务器，此处节点ip请换为自己真实ip即端口号

4.5 集群测试

redis-cli -p 6001 -c
#-c 参数，节点之间可以相互跳转
cluster slots  
#查看节点的哈希槽编号范围
cluster keyslot 键名
#查看键的哈希槽编号

五，总结

1，Redis高可用有四种实现方式：持久化，主从复制，哨兵模式，集群模式

2，持久化适用于单台服务器，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因为进程退出而丢失，是最简单的一种高可用方式。

3，主从复制适用于数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。

4，哨兵模式基于主从复制，部署哨兵模式必须先部署主从复制，其在主从复制基础上提供了自动化的故障恢复，但是其写操作无法负载均衡，存储能力收到单机的限制。

5，redis集群提供了分布式存储方案解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案，其集群最低需要6个节点，三主三从，使用Redis高可用