redis的深度理解

上篇博客我们说到了redis的基本概念和基本操作,本篇我们就更深入去了解一些redis的操作和概念,我们就从red的主从同步、redis哨兵模式和redis集群三个方面来了解redis数据库

一、主从同步

像MySQL一样,redis是支持主从同步的,而且也支持一主多从以及多级从结构。 主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担。 redis的主从同步是异步进行的。

1.主从同步原理

从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作,也就是将主服务器的数据写入RDB文件中。在数据持久化期间,主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上,然后再将其读取到内存中。这个动作完成后,主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
另外,要说的一点是,即使有多个从服务器同时发来SYNC指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个从服务器。

2.部署主从同步(一主两从)

部署环境

192.168.91.5       redis-master
192.168.91.149     redis-slave-1
192.168.91.150     redis-slave-2

关闭防火墙和selinux
systemctl stop firewalld         
systemctl disable firewalld       #关闭防火墙
setenforce 0      #关闭selinux

 修改master配置文件

# vim /usr/local/redis/redis.conf

bind 0.0.0.0
protected-mode no

修改slave配置文件

#vim /usr/local/redis/redis.conf

bind 0.0.0.0
protected-mode no
replicaof 192.168.91.5

 重启redis服务,再netstat -nlpt查看一下端口即可

二、哨兵模式

哨兵模式是用于监控redis主从复制中Master状态的工具,所以我们的哨兵模式都是基于主从复制的基础去做的

1.作用

检测Master状态,如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave, Master-Slave切换后,sentinel的监控目标会随之调换 

2.工作模式

1):每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令 

2):如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值,则这个实例会被 Sentinel 标记为主观下线。 

3):如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 

4):当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线 

ps:quorum 的值一般设置为哨兵个数的二分之一加1,例如 3 个哨兵就设置 2。

3.主观下线和客观下线

主观下线:Subjectively Down,简称 SDOWN,指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。 
客观下线:Objectively Down, 简称 ODOWN,指的是多个 Sentinel(哨兵) 实例在对Master Server做出 SDOWN  判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的Master  Server下线判断,然后开启failover(故障转移)

4.配置哨兵模式

vim /usr/local/redis/sentinel.conf

daemonize yes                                #设置哨兵放后台运行
logfile "/var/log/sentinel.log"                    #设置哨兵日志
sentinel monitor mymaster 192.168.91.5 6379 2        #当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了。 (slave上面写的是master的ip,master写自己ip)
protected-mode no             #将加密保护关闭
sentinel down-after-milliseconds mymaster 3000          #单位毫秒
sentinel failover-timeout mymaster 10000           #若sentinel在该配置值内未能完成failover(故障转移)操作(即故障时master/slave自动切换),则认为本次failover失败。

[root@redis-master redis]# ./src/redis-sentinel sentinel.conf   #开启哨兵模式

三、redis集群

1.使用redis集群的原因

1.首先Redis单实例主要有单点,容量有限,流量压力上限的问题。
Redis单点故障,可以通过主从复制replication,和自动故障转移sentinel哨兵机制。但Redis单Master实例提供读写服务,仍然有容量和压力问题。

2.并发问题
redis官方声称可以达到 10万/每秒,每秒执行10万条命令
假如业务需要每秒100万的命令执行呢?
解决方案如下
正确的应该是考虑分布式,加机器,把数据分到不同的位置,分摊集中式的压力。那么一堆机器做一件事.还需要一定的机制保证数据分区,并且数据在各个主Master节点间不能混乱。

总结:
redis cluster:主要是针对海量数据+高并发+高可用的场景,海量数据,如果你的数据量很大,那么建议就用redis cluster

2.redis集群特点

1.所有的redis节点彼此互联(PING-PONG机制)。
2.客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
3.节点的fail是通过集群中超过半数的节点检测失效时才生效。
4.Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

3.数据分布存储原理

Redis 集群使用数据分片来实现:Redis 集群中内置了 16384 个哈希槽,当需要在 Redis 集群中放置一个 key-value 时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数(集群使用公式 CRC16(key) % 16384),这样每个key 都会对应一个编号在 0-16384 之间的哈希槽,那么redis就会把这个key 分配到对应范围的节点上了。同样,当连接三个节点任何一个节点想获取这个key时,也会这样的算法,然后内部跳转到存放这个key节点上获取数据。

4.集群部署

准备环境 

1.准备三机器,关闭防火墙和selinux
2.制作解析并相互做解析。
注:规划架构两种方案,一种是单机多实例,这里我们采用多机器部署:
三台机器,每台机器上面两个redis实例,一个master一个slave,第一列做主库,第二列做备库
#记得选出控制节点

redis-cluster1 192.168.91.5   7000、7001
redis-cluster2 192.168.91.149   7002、7003
redis-cluster3 192.168.91.150   7004、7005

安装redis(三台机器都需要操作)

yum -y install gcc automake autoconf libtool make    #安装编译工具
wget https://download.redis.io/releases/redis-6.2.0.tar.gz      #下载
tar xzvf redis-6.2.0.tar.gz -C /usr/local        #解压
mv /usr/local/redis-6.2.0 /usr/local/redis        #改名
cd /usr/local/redis
make                      #编译
mkdir /usr/local/redis/data        #创建存放数据的目录

创建节点目录:按照规划在每台redis节点的安装目录中创建对应的目录(以端口号命名)

[root@redis-cluster1 redis]# pwd
/usr/local/redis

[root@redis-cluster1 redis]# mkdir cluster #创建集群目录
[root@redis-cluster1 redis]# cd cluster/
[root@redis-cluster1 cluster]# mkdir 7000 7001 #创建节点目录

[root@redis-cluster2 redis]# mkdir cluster
[root@redis-cluster2 redis]# cd cluster/
[root@redis-cluster2 cluster]# mkdir 7002 7003

[root@redis-cluster3 redis]# mkdir cluster
[root@redis-cluster3 redis]# cd cluster/
[root@redis-cluster3 cluster]# mkdir 7004 7005

拷贝配置文件到节点目录中

[root@redis-cluster1 cluster]# cp /data/redis/redis.conf 7000/
[root@redis-cluster1 cluster]# cp /data/redis/redis.conf 7001/

[root@redis-cluster2 cluster]# cp /data/redis/redis.conf 7002/
[root@redis-cluster2 cluster]# cp /data/redis/redis.conf 7003/

[root@redis-cluster3 cluster]# cp /data/redis/redis.conf 7004/
[root@redis-cluster3 cluster]# cp /data/redis/redis.conf 7005/

修改集群redis配置文件。(主要是端口、ip、pid文件,三台机器相同操作)

[root@redis-cluster1 7000]# vim redis.conf 

bind 192.168.116.172               #每个实例的配置文件修改为对应节点的ip地址
port 7000                    #监听端口,运行多个实例时,需要指定规划的每个实例不同的端口号
daemonize yes #redis后台运行
pidfile /var/run/redis_7000.pid           #pid文件,运行多个实例时,需要指定不同的pid文件
logfile /var/log/redis_7000.log           #日志文件位置,运行多实例时,需要将文件修改的不同。
dir /data/redis/data            #存放数据的目录
appendonly yes           #开启AOF持久化,redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中,当redis重新启动时,会从该文件恢复出之前的状态。
appendfilename "appendonly.aof"           #AOF文件名称
appendfsync everysec        #表示对写操作进行累积,每秒同步一次

以下为打开注释并修改
cluster-enabled yes #启用集群
cluster-config-file nodes-7000.conf                 #集群配置文件,由redis自动更新,不需要手动配置,运行多实例时请注修改为对应端口
cluster-node-timeout 5000             #单位毫秒。集群节点超时时间,即集群中主从节点断开连接时间阈值,超过该值则认为主节点不可以,从节点将有可能转为master
cluster-replica-validity-factor 10               #在进行故障转移的时候全部slave都会请求申请为master,但是有些slave可能与master断开连接一段时间了导致数据过于陈旧,不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。
cluster-migration-barrier 1         #一个主机将保持连接的最小数量的从机,以便另一个从机迁移到不再被任何从机覆盖的主机
cluster-require-full-coverage yes     #集群中的所有slot(16384个)全部覆盖,才能提供服务

注:所有节点配置文件全部修改切记需要修改的ip、端口、pid文件...避免冲突。确保所有机器都修改。

启动三台机器上面的每个节点

[root@redis-cluster1 src]# ./redis-server ../cluster/7000/redis.conf 
[root@redis-cluster1 src]# ./redis-server ../cluster/7001/redis.conf

[root@redis-cluster2 7003]# cd /data/redis/src/
[root@redis-cluster2 src]# ./redis-server ../cluster/7002/redis.conf 
[root@redis-cluster2 src]# ./redis-server ../cluster/7003/redis.conf

[root@redis-cluster3 7005]# cd /data/redis/src/
[root@redis-cluster3 src]# ./redis-server ../cluster/7004/redis.conf 
[root@redis-cluster3 src]# ./redis-server ../cluster/7005/redis.conf

查看端口

netsata -lnpt                   #查看端口

redis的深度理解_第1张图片

redis的深度理解_第2张图片

redis的深度理解_第3张图片

redis的深度理解_第4张图片

查看到这些信息之后,就说明我们的redis集群搭建成功了

四、总结redis在运维方面的经典问题

一、如何解决Redis,mysql双写一致性?
1.最经典的缓存+数据库读写的模式:
读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。
更新的时候,先更新数据库,然后再删除缓存。
2.给缓存设置过期时间,这种方案下,可以对存入缓存的数据设置过期时间,所有的写操作以数据库为准,也就是说如果数据库写成功,缓存更新失败,那么只要到达过期时间,则后面的读请求自然会从数据库中读取新值然后回填缓存。

二、缓存雪崩
数据未加载到缓存中,或者缓存同一时间大面积的失效,从而导致所有请求都去查数据库,导致数据库CPU和内存负载过高,甚至宕机。

产生雪崩的简单过程:
1、redis集群大面积故障
2、缓存失效,但依然大量请求访问缓存服务redis
3、redis大量失效后,大量请求转向到mysql数据库,mysql的调用量暴增,很快就扛不住了,甚至直接宕机
4、由于大量的应用服务依赖mysql和redis的服务,这个时候很快会演变成各服务器集群的雪崩,最后网站彻底崩溃。

解决问题:
1.缓存的高可用性
缓存层设计成高可用,防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务,例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2.缓存降级
可以利用ehcache等本地缓存(暂时支持),主要还是对源服务访问进行限流、资源隔离(熔断)、降级等。
当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级,这里会涉及到运维的配合。
降级的最终目的是保证核心服务可用,即使是有损的。
在进行降级之前要对系统进行梳理,比如:哪些业务是核心(必须保证),哪些业务可以容许暂时不提供服务(利用静态页面替换)等,以及配合服务器核心指标,来后设置整体。
3.Redis备份和快速预热
1)Redis数据备份和恢复
2)快速缓存预热
4.提前演练
最后,建议还是在项目上线前,演练缓存层宕掉后,应用以及后端的负载情况以及可能出现的问题,对高可用提前预演,提前发现问题。

三、缓存穿透
缓存穿透是指查询一个一不存在的数据。例如:从缓存redis没有命中,需要从mysql数据库查询,查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,造成缓存穿透。

解决问题:
如果查询数据库也为空,直接设置一个默认值存放到缓存,这样第二次到缓冲中获取就有值了,而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。

四、redis有哪些好处
(1) 速度快,因为数据存在内存中.
(2) 支持丰富数据类型,支持string,list,set,sorted set,hash
(3) 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行
(4) 丰富的特性:可用于缓存,消息,按key设置过期时间,过期后将会自动删除
redis相比memcached有哪些优势
(1) memcached所有的值均是简单的字符串,redis作为其替代者,支持更为丰富的数据类型
(2) redis可以持久化其数据
redis常见性能问题和解决方案
(1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件
(2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库

你可能感兴趣的:(redis,mybatis,数据库)