Redis 集群高可用详解及配置

关型数据库

关系型数据库：

是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据

主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库

关型数据库的优缺点

特点：

1、数据关系模型基于关系模型，结构化存储，完整性约束
2、基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作
3、采用结构化的查询语言（SQL）做数据读写
4、操作需要数据的一致性，需要事务甚至是强一致性

优点：

1、保持数据的一致性（事务处理）
2、可以进行join等复杂查询
3、通用化，技术成熟

缺点：

1、数据读写必须经过sql解析，大量数据、高并发下读写性能不足
2、对数据做读写，或修改数据结构时需要加锁，影响并发操作
3、无法适应非结构化存储
4、扩展困难
5、昂贵、复杂

非关型数据库

NoSQL 数据库：

全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储

主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点

NoSQL 数据库优缺点

特点：

1、非结构化的存储
2、基于多维关系模型
3、具有特有的使用场景

优点：

1、高并发，大数据下读写能力较强
2、基本支持分布式，易于扩展，可伸缩
3、简单，弱结构化存储

缺点：

1、join等复杂操作能力较弱
2、事务支持较弱
3、通用性差
4、无完整约束复杂业务场景支持较差

Redis 数据库介绍

Redis简介

Redis 全称：Remote Dictionary Server

Redis是一个开源的、遵循BSD协议的、基于内存的而且目前比较流行的键值数据库(key-value database)，是一个非关系型数据库

Redis 提供将内存通过网络远程共享的一种服务，提供类似功能的还有memcached，但相比memcached，redis还提供了易扩展、高性能、具备数据持久性等功能。

Redis 在高并发、低延迟环境要求比较高的环境使用量非常广泛

Redis 特性

1、速度快：10WQPS，基于内存，C语言实现
2、单线程（纯内存、非阻塞、避免线程切换和竞态消耗）
3、持久化
4、支持多种数据结构
5、支持多种编程语言
6、功能丰富：支持Lua脚本,发布订阅，事务，pipeline等功能
7、简单：代码短小精悍（单机核心代码只有23000行左右）单线程开发容易，不依赖外部库，使用简单
8、主从复制
9、支持高可用和分布式

Redis 的应用场景

1、Session共享：常见于web集群中的Tomcat或者PHP中多web服务器session共享
2、缓存：数据查询、电商网站商品信息、新闻内容
3、计数器：访问排行榜、商品浏览数等和次数相关的数值统计场景
4、微博/微信社交场合：共同好友，粉丝数，关注，点赞评论等
5、消息队列：ELK的日志缓存、部分业务的订阅发布系统
6、地理位置：基于GEO(地理信息定位),实现摇一摇，附近的人，外卖等功能

缓存的实现流程

数据更新时：

写入数据时，进行的是mysql数据的写入，如果不成功则返回；如果成功，则删除Redis对应的选项，并返回

在这里插入图片描述

数据读取是：

读取数据时，首先读取存储在内存内的Redis数据，如果读取成功则将直接返回；

如果未读取到数据则进行mysql数据的读取，读取成功则将进行写对应的Redis数据，并将写好的Redis数据进行返回；

如果mysql数据依旧没有任何获取，则将进行不带任何数据的返回

在这里插入图片描述

Redis 的安装

rpm 包进行安装

可在网上进行下载相应的rpm包，或者使用本地的镜像源

安装操作：

[root@redis1 ~]# yum install redis -y

源码安装

1、安装编译环境

[root@redis1 ~]# yum install make gcc initscripts -y

2、下载相应的源码包

在这里插入图片描述

3、进行解压

[root@redis1 ~]# tar zxf redis-7.4.0.tar.gz

4、进行编译和安装

[root@redis1 ~]# make && make install

5、修改启动的相关文件内容

[root@redis1 utils]# vim install_server.sh
#注释掉其检测启动方式，不让其检测

在这里插入图片描述

6、启动 Redis

[root@redis1 ~]# ./install_server.sh
......
Please select the redis port for this instance: [6379]	#端口号
Selecting default: 6379
Please select the redis config file name [/etc/redis/6379.conf]	#配置文件
Selected default - /etc/redis/6379.conf
Please select the redis log file name [/var/log/redis_6379.log]	#日志文件
Selected default - /var/log/redis_6379.log
Please select the data directory for this instance [/var/lib/redis/6379]  #数据目录
Selected default - /var/lib/redis/6379
Please select the redis executable path [/usr/local/bin/redis-server] #命令路径
.....
Installation successful!

7、修改其配置文件

[root@redis1 ~]# vim /etc/redis/6379.conf
......
bind * -::*
......

[root@redis1 ~]# /etc/init.d/redis_6379 restart
#重启服务

在这里插入图片描述

8、测试

[root@redis1 ~]# redis-cli
127.0.0.1:6379> info
......

Redis 的基本操作

config get *	#查看配置

select 1		#选择数据库（redisa中有0-15个数据库）

set key 数据		#写入数据

get key		#获取数据

keys * 			#查看所有key

flushdb			#清空当前数据库

flushall		#清空所有数据库

move key 1		#移动key

del key			#删除

rename oldkey newkey	#改名

expire key 10	#设置过期时间（#如果没有设定数据过期时间，数据则会一直存在 /var/lib/redis/6379/dump.rdb 内存快照中）

persist key		#设置持久化

keys user*		#查询

exists key		#判断是否存在

主从复制

主从同步过程

1、slave节点发送同步亲求到master节点

2、slave节点通过master节点的认证开始进行同步

3、master节点会开启bgsave进程发送内存rbd到slave节点，在此过程中是异步操作，也就是说master节点仍然可以进行写入动作

4、slave节点收到rdb后首先清空自己的所有数据

5、slave节点加载rdb并进行数据恢复

6、在master和slave同步过程中master还会开启新的bgsave进程把没有同步的数据进行缓存，然后通过自有的 replactionfeedslave 函数把未通过内存快照发送到slave的数据一条一条写入到slave中

在这里插入图片描述

主从同步配置

在配置多台 Redis 时建议用复制的方式节省编译时间

复制时应将 Redis 的整个目录复制至指定主机路径

复制时将 /usr/local/bin/ 下的关于 Redis 的数据一起复制

[root@redis1 ~]# scp -r /usr/local/bin 目标主机IP:/usr/local/

[root@redis1 ~]# rsync -al * /usr/local/bin 目标主机IP:/usr/local/

master 设备：

[root@redis1 ~]# vim /etc/redis/6379.conf
......
protected-mode no
#关闭其protected模式
......

root@redis1 ~]# /etc/init.d/redis_6379 restart
#重启服务

在这里插入图片描述

vlave 设备：

[root@redis1 ~]# /etc/init.d/redis_6379 restart
......
replicaof 172.25.254.10 6379
#指定其master设备IP和端口号
......

[root@redis1 ~]# /etc/init.d/redis_6379 restart
#重启服务

在这里插入图片描述

测试：

#进入master设备
[root@redis1 ~]# redis-cli
127.0.0.1:6379> info replication

在这里插入图片描述

#在mastser节点
[root@redis-node1 ~]# redis-cli
127.0.0.1:6379> set name 123

在这里插入图片描述

#在slave节点查看
[root@redis2 ~]# redis-cli
127.0.0.1:6379> get name
"123"

在这里插入图片描述

哨兵模式（高可用）

Redis 哨兵简介

在这里插入图片描述

1、Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，此功能在redis2.6+的版本已引用，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版本

2、每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(此项可配置)内未得到回应，则暂时认为对方已离线，也就是所谓的 “主观认为宕机” （主观:是每个成员都具有的独自的而且可能相同也可能不同的意识），英文名称：Subjective Down，简称 sdown

3、有主观宕机，对应的就有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是 “客观宕机” （客观:是不依赖于某种意识而已经实际存在的一切事物），英文名称是：Objectively Down，简称 odown

4、通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修改相关配置，并开启故障转移（failover）

5、Sentinel 机制可以解决master和slave角色的自动切换问题，但单个 Master 的性能瓶颈问题无法解决,类似于MySQL中的MHA功能

6、Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数

sentinel中的三个定时任务：

1、每10秒每个sentinel对master和slave执行info

（1）发现slave节点

（2）确认主从关系

2、每2秒每个sentinel通过master节点的channel交换信息(pub/sub)

（1）通过sentinel__:hello频道交互

（2）交互对节点的“看法”和自身信息

3、每1秒每个sentinel对其他sentinel和redis执行ping动作

哨兵部署

1、修改哨兵配置文件路径

[root@redis1 ~]# cd redis-7.4.0/
[root@redis1 redis-7.4.0]# cp sentinel.conf /etc/redis/
#将源码包内的哨兵配置文件复制至Redsi配置目录下

2、修改 sentinel 配置文件

[root@redis1 ~]# vim /etc/redis/sentinel.conf
protected-mode no						#关闭保护模式
port 26379								#监听端口
daemonize no							#监控页面不打入后台
pidfile /var/run/redis-sentinel.pid 	#sentinel进程pid文件
loglevel notice 						#日志级别
sentinel monitor mymaster 172.25.254.100 6379 2		#创建sentinel监控监控master主机，2表示必须得到2票
sentinel down-after-milliseconds mymaster 10000		#master中断时长，10秒连不上视为master下线
sentinel parallel-syncs mymaster 1 		#发生故障转移后，同时开始同步新master数据的slave数量
sentinel failover-timeout mymaster 180000 #整个故障切换的超时时间为3分钟

在这里插入图片描述

3、将配置文件远程传输至其它的 Redis 主机

[root@redis1 ~]# scp /etc/redis/sentinel.conf root@目标主机IP:/etc/redis/

4、开启哨兵模式

[root@redis1 ~]# redis-sentinel /etc/redis/sentinel.conf

#开启哨兵模式后，哨兵程序会调用 " /etc/redis/sentinel.conf " 文件，并更改其配置文件，如果需要重新设定哨兵模式，需将原来的哨兵配置文件删除并重新编辑

测试：

当master主机宕机时，可查看哨兵模式下的页面信息

在这里插入图片描述

当故障设备恢复后，会成为slave设备并重新指向新的master

在这里插入图片描述

解决哨兵模式存在的问题

问题：

1、在生产环境中如果master和slave中的网络出现故障，由于哨兵的存在会把master踢出去

2、当网络恢复后，master发现环境发生改变，master就会把自己的身份转换成slave

3、master变成slave后会把网络故障那段时间写入自己中的数据清掉，这样数据就丢失了。

解决方案：

1、master在被写入数据时会持续连接slave，在mater确保有2个slave连接时，才能写入

2、如果slave数量少于2个则拒绝写入

#在matster中设定
[root@redis1 ~]# redis-cli
127.0.0.1:6379> CONFIG GET min-slaves-to-write
1) "min-slaves-to-write"
2) "0"
127.0.0.1:6379> CONFIG set min-slaves-to-write 2	#设定最少链接slave数量为2
OK

#如果要永久保存，则需要写到配置文件中/etc/redis/6379.conf

Redsi Cluster （无中心化设计）

Redis Cluster简介

在哨兵sentinel机制中，可以解决redis高可用问题，即当master故障后可以自动将slave提升为master，从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问题，即单机redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素。

redis 3.0版本之后推出了无中心架构的redis cluster机制，在无中心的redis集群当中，其每个节点都会保存自己当前节点数据和整个集群状态,每个节点都和其他所有节点相连接

Redis Cluster特点如下：

1、所有Redis节点都是互联的（使用PING机制）

2、集群中某个节点是否失效，是由整个集群来决定的，当集群中超过半数的节点通过监测都显示其失效了，才能算真正的失效

3、客户端不需要proxy即可直接连接redis，应用程序中需要配置有全部的redis服务器IP

4、redis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上，读写需要到指定的redis node上进行操作，因此有多少个redis node 就相当于redis 并发扩展了多少倍，每个redis node 承担 16384/N 个槽位

5、Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使用CRC16(key) mod 16384之后的值，决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

Redis cluster架构在写入数据时会遇到的情况：

1、当写入数据时，会通过算法计算出写入的数据应该在哪个哈希槽内；

2、如果不在当前写入的主机，则会报错并提示在哪台主机进行写入；

3、可以通过python脚本来进行数据的写入，这样就可以不用来回切换主机到指定的哈希槽

Redis cluster架构：

在这里插入图片描述

假如三个主节点分别是：A, B, C 三个节点，采用哈希槽 (hash slot)的方式来分配16384个slot 的话它们三个节点分别承担的slot 区间可以是：

节点A覆盖：0－5460

节点B覆盖：5461－10922

节点C覆盖：10923－16383

在这里插入图片描述

Redis cluster 主从架构：

Redis cluster的架构虽然解决了并发的问题，但是又引入了一个新的问题，每个Redis master的高可用如何解决：

那就是对每个master 节点都实现主从复制,从而实现 redis 高可用性

在这里插入图片描述

Redis Cluster 部署

创建 redis cluster 的前提：

1、每个redis node节点采用相同的硬件配置、相同的密码、相同的redis版本

2、每个节点必须开启的参数：

（1）cluster-enabled yes

#必须开启集群状态，开启后redis进程会有cluster显示

（2）cluster-config-file nodes-6379.conf

#此文件有redis cluster集群自动创建和维护，不需要任何手动操作

3、所有redis服务器必须没有任何数据

4、先启动为单机redis且没有任何key value

所有redis主机均配置：

#修改redis配置文件
[root@redis1 ~]# vim /etc/redis/redis.conf
......
bind * -::*
#开启端口
......
masterauth "123"
#集群主从认证
......
requirepass "123"
#集群登陆密码
#使用 redis-cli 命令连接redis数据库，进入数据库内使用 “auth 密码”进行认证
......
cluster-enabled yes
#开启cluster集群功能
......
cluster-config-file nodes-6379.conf
#指定集群配置文件
......
cluster-node-timeout 15000
#节点加入集群的超时时间单位是ms
......

[root@redis-master1 ~]# systemctl restart redis.service
#重启服务

在这里插入图片描述

redis-cli --cluster 参数

[root@redis1 ~]# redis-cli --cluster help
Cluster Manager Commands:

create	host1:port1 ... hostN:portN		#创建集群
			--cluster-replicas <arg> 	#指定master的副本数

check <host:port> or <host> <port>		#检测集群信息

info <host:port> or <host> <port>		#查看集群信息

fix <host:port> or <host> <port>		#修复集群

reshard <host:port> or <host> <port>	#在线热迁移集群指定主机的slots数据

rebalance <host:port> or <host> <port>	#平衡各集群主机的slot数量

add-node new_host:new_port existing_host:existing_port	#添加主机

del-node host:port node_id				#删除主机

import host:port						#导入外部redis服务器的数据到当前集群

创建 redis-cluster 集群

创建流程如下：

[root@redis1 ~]# redis-cli --cluster create -a 123 \#创建redis集群
> 172.25.254.10:6379 172.25.254.20:6379 172.25.254.30:6379 \#添加集群设备
> 172.25.254.110:6379 172.25.254.120:6379 172.25.254.130:6379 \
> --cluster-replicas 1	#master的slave设备数为1

#集群配置文件：/var/lib/redis/nodes-6379.conf

在这里插入图片描述

检测redis集群状态：

[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379
#查看集群状态

[root@redis1 ~]# redis-cli -a 123 --cluster check 172.25.254.10:6379
#检测集群

在这里插入图片描述

写入数据：

[root@redis1 ~]# redis-cli -a 123
127.0.0.1:6379> set key1 value1
(error) MOVED 9189 172.25.254.20:6379
#提示该数据被分配到20的hash槽位上，应在20端进行写入

在这里插入图片描述

[root@redis2 ~]# redis-cli -a 123
127.0.0.1:6379> set key1 value1
OK

在这里插入图片描述

集群扩容

添加master：

[root@redis1 ~]# redis-cli -a 123 --cluster add-node 172.25.254.40:6379 172.25.254.10:6379

在这里插入图片描述

检测集群查看是否加入成功：

[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379

在这里插入图片描述

分配槽位（分配给master设备）：

[root@redis1 ~]# redis-cli -a 123 --cluster reshard 172.25.254.10:6379

在这里插入图片描述

添加slave：

[root@redis1 ~]# redis-cli -a 123 --cluster add-node 172.25.254.140:6379 172.25.254.10:6379 --cluster-slave --cluster-master-id 9ba748102ca1bcf27ff08e1b0407c1ddfbcf33ee

#（172.25.254.140:6379）指定要加入集群的设备IP；（172.25.254.10:6379）指定集群；（009571cb206a89afa6658b60b2d403136056ac09）指定master设备ID

在这里插入图片描述

检测集群查看是否加入成功：

[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379

在这里插入图片描述

集群的维护

添加节点的时候是先添加node节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相反，是先将被删除的Redis node上的槽位迁移到集群中的其他Redis node节点上，然后再将其删除，如果一个Redis node节点上的槽位没有被完全迁移，删除该node的时候会提示有数据且无法删除

移除槽位：

[root@redis1 ~]# redis-cli -a 123 --cluster reshard 172.25.254.10:6379
......
How many slots do you want to move (from 1 to 16384)? 4096
What is the receiving node ID? 9f2f2dc6c43aebd4cfc9af5d6629a3b2513c3345
......
Source node #1: 3e6122890e25ad57fc1009db1f18f0ed5295349c
Source node #2: done
......

在这里插入图片描述

查看设备的槽位是否移除成功：

[root@redis1 ~]# redis-cli -a 123 --cluster info 172.25.254.10:6379

在这里插入图片描述

移除设备：

[root@redis1 ~]# redis-cli -a 123 --cluster del-node 172.25.254.110:6379 3e6122890e25ad57fc1009db1f18f0ed5295349c

#（172.25.254.120:6379）移除设备的IP和端口；（d458f34fa900d83212c021dc1e65396e490b5495）需进行移除的设备ID

在这里插入图片描述