redis的性能管理、主从复制和哨兵模式

一、redis的性能管理

redis的数据时缓存在内存中的

查看系统内存情况

info memory

redis的性能管理、主从复制和哨兵模式_第1张图片

used_memory:853688 redis中数据占用的内存

used_memory_rss:10522624 redis向操作系统申请的内存

used_memory_peak:853688 redis使用内存的峰值

系统巡检:硬件巡检、数据库 nginx redis docker k8s等软件巡检

内存碎片率:used_memory_rss/used_memory=内存碎片率

系统已经分配给了redis,但是redis未能够有效利用的内存

查询比率:

redis-cli info memory | grep ratio

allocator_frag_ratio:1.26

分配器碎片的比例,redis的主进程调度时产生的内存。比例要越小越好,值越高说明内存的浪费越多

allocator_rss_ratio:4.54

分配器占用物理内存的比例,告诉你主进程调度执行时占用了多少物理内存

rss_overhead_ratio:1.36

RSS是向系统申请的内存空间,redis占用物理空间额外的开销比例,比例要越低越好,表示redis实际占用的内存和向系统申请的内存越接近,额外的开销越低

mem_fragmentation_ratio:15.16

内存碎片的比例,越低越好,内存的使用率越高,

清理碎片:

自动清理碎片:

vim /etc/redis/6379.conf

最后一行插入:

activedefrag yes

开启自动清理

要设置redis最大内存阀值

一旦到达阀值,自动清理碎片,开启key的回收机制

567行

设置占用最大内存

maxmemory 1gb

一定要设置占用内存的阀值

598行

设置开启key的回收机制:

key回收策略:

maxmemory-policy volatile-lru

使用redis内置的LRU算法,把已经设置了过期时间的键值对中淘汰数据,移除最近最少使用的键值对(只是针对设置过期时间的键值对)

maxmemory-policy volatile-ttl

已经设置了过期时间的键值对,从当中挑选一个即将过期的键值对(针对有设置过期时间的键值对)

maxmemory-policy volatile-random

从已经设置的过期的键值对当中,挑选数据随机淘汰键值对(对设置了过期时间的键值对进行随意移除)

allkeys-lru

根据LRU算法当中,对所有的键值对进行淘汰,移除最少使用的键值对(针对所有的键值对)

allkeys-random

从所有键值对中,任意选项数据进行淘汰

maxmemory-policy noeviction

键值键值对回收(不删除任何键值对,知道redis把内存塞满,写不了了,报错为止)

在工作中一定要给redis占用内存设置阀值

手动配置:

redis-cli memory purge

redis的性能管理、主从复制和哨兵模式_第2张图片

工作中reids占用内存效率问题如何处理:

1、日常巡检中,对redis的占用情况做监控

2、设置redis占用系统内存的阀值,避免占用系统全部内存

3、内存碎片清理,手动和自动清理

4、配置合适的key回收机制

redis雪崩:

也是缓存雪崩:大量的应用请求无法在redis缓存中处理,请求会全部发送到后台数据库,

数据库本身并发能力就差,一旦高并发,数据库会很快崩溃

导致雪崩的原因:

redis集群大面积故障

redi缓存中,大量数据同时过期,大量的请求无法得到处理

redis实例宕机。

解决方法:

事前:高可用架构,防止整个缓存故障。只从复制和哨兵模式。redis集群

事中:在国内用的比较多的方式:HySTRIX,熔断,降级,限流三个手段来降低雪崩发生过后的损失

事后:redis备份。快速缓存预热

redis的缓存击穿:

导致原因:

主要是热点数据缓存过期,或者被删除,多个请求并发访问热点数据,请求也是转发到数据库,导致数据库的性能快速下降

经常被请求的缓存数据,最好设置为永不过期

redis缓存穿透:

缓存中没有数据,数据库也诶呦对应数据,但是有用户一直在发起这个都没有的请求,而且请求的数据格式很大。一般是黑客再利用漏洞攻击,以压垮应用数据库

键值对还在,但是值被替换了,原有的请求找不到之后,同样也会去请求后台的数据库,也是击穿的一种

redis的集群

高可用方案:

  1. 持久化
  2. 高可用 主从复制 哨兵模式 集群

主从复制时redis实现高可用的基础,哨兵模式和集群都是在主从复制的基础上实现高可用的

主从复制实现数据的多级备份,以及读写分离(主负责写,从负责读)

缺点:故障无法自动恢复。需要人工干预,写操作无法实现负载均衡

主从复制的工作原理:

  1. 主节点 master 从节点slave组成,数据的复制时单向的,只能从主节点到从节点

架构配置:

主从复制:

主 20.0.0.41

从1  20.0.0.42

从2 20.0.0.43

关防火墙和安全机制

修改master节点的配置文件 

vim /etc/redis/6379.conf

 bind 0.0.0.0                      #70行,修改监听地址为0.0.0.0(生产环境中,尤其是多网卡最好填写物理网卡的IP)

redis的性能管理、主从复制和哨兵模式_第3张图片

 daemonize yes                     #137行,开启守护进程,后台启动

 logfile /var/log/redis_6379.log   #172行,指定日志文件存放目录

redis的性能管理、主从复制和哨兵模式_第4张图片

 dir /var/lib/redis/6379           #264行,指定工作目录

redis的性能管理、主从复制和哨兵模式_第5张图片

 appendonly yes                    #700行,开启AOF持久化功能

redis的性能管理、主从复制和哨兵模式_第6张图片

/etc/init.d/redis_6379 restart     #重启redis服务

改两个slave节点的配置文件 

#修改slave1的配置文件

vim /etc/redis/6379.conf

 bind 0.0.0.0                        #70行,修改监听地址为0.0.0.0(生产环境中需要填写物理网卡的IP)

 daemonize yes                       #137行,开启守护进程,后台启动

 logfile /var/log/redis_6379.log     #172行,指定日志文件目录

redis的性能管理、主从复制和哨兵模式_第7张图片

 dir /var/lib/redis/6379             #264行,指定工作目录

redis的性能管理、主从复制和哨兵模式_第8张图片

 replicaof 20.0.0.41 6379       #288行,指定要同步的Master节点的IP和端口

 appendonly yes                      #700行,修改为yes,开启AOF持久化功能

redis的性能管理、主从复制和哨兵模式_第9张图片

/etc/init.d/redis_6379 restart  #重启redis

netstat -natp | grep redis      #查看主从服务器是否已建立连接

redis的性能管理、主从复制和哨兵模式_第10张图片

tail -f /var/log/redis_6379.log

redis的性能管理、主从复制和哨兵模式_第11张图片

实验测试:

主节点创建数据,从节点是否同步

只有主节点能读写,从节点只能读

查看主从状态信息:

redis-cli info replication

redis的性能管理、主从复制和哨兵模式_第12张图片

哨兵模式:

先有主从然后再有哨兵,在主从复制的基础只上,实现主节点故障的自动切换。

哨兵模式的原理:

是一个分布式系统,每个节点上都有哨兵,用于在主从结构之间,对每台redis服务进行服务监控

主节点出现故障时,从节点通过投票的方式选择一个新的master

哨兵模式也需要至少三个节点

哨兵模式的结构:
哨兵节点:监控,不存储任何数据

数据节点:主节点和从节点,都是数据节点

redis工作机制:
哨兵监控的是redis的节点,不是监控哨兵

每个哨兵每隔一秒,通过ping命令的方式,检测主从之间的心跳线

主节点在一定时间内没有回复,或则回复了错误消息。这个时候,哨兵会主观的任务主节点下线了。如果有超过半数的哨兵节点认为主节点下线了,在个时候才会认为主节点是客观下线

哨兵节点通过raft算法(选举算法),每个节点共同投票,选举出一个新的master。然后新的master,来实现主节点的转义和故障恢复通知

主节点选举的过程:

  1. 已经下线的从节点,不会被选为主节点
  2. 选择配置微文件中,从节点优先级最高的,replica-priority 100
  3. 选择一个复制数据最完整的从节点

redis的性能管理、主从复制和哨兵模式_第13张图片

哨兵模式,源码包里自带

主从配置方式一致:

vim /opt/redis-5.0.7/sentinel.conf

17行
protected-mode no

取消注释

关闭保护模式

21行

哨兵模式默认端口

redis的性能管理、主从复制和哨兵模式_第14张图片

26行

指定哨兵模式是否后台运行 改成yes

redis的性能管理、主从复制和哨兵模式_第15张图片

36行

是日志文件

redis的性能管理、主从复制和哨兵模式_第16张图片

65行

设置工作目录:

redis的性能管理、主从复制和哨兵模式_第17张图片

84行

指定初始的主服务器

redis的性能管理、主从复制和哨兵模式_第18张图片

这里的2表示至少需要2台服务器认为主已经下线,才会进行主从切换

 113行

判断服务器宕掉的服务周期

redis的性能管理、主从复制和哨兵模式_第19张图片

146行

故障节点的最大超时时间

redis的性能管理、主从复制和哨兵模式_第20张图片

配置完之后

重启服务

要先启master 再启slave

都在redis原码包目录下启动的

要在reids原码包目录下,启动

redis-sentinel sentinel.conf &

监控哨兵集群

查看整个集群的哨兵情况:

redis-cli -p 26379 info Sentinel

redis的性能管理、主从复制和哨兵模式_第21张图片

模拟故障:

先杀进程或暂停节点

然后投票选举一个master

redis的性能管理、主从复制和哨兵模式_第22张图片

测试结果,新master创建数据,slave同步数据

故障恢复,重启源master服务器

你可能感兴趣的:(redis,开发语言,缓存,架构,运维,数据库,redis)