redis的高可用(主从复制和哨兵模式)

redis的高可用(主从复制和哨兵模式

redis的性能管理:redis的数据缓存在内存当中

INFO memory:查看redis内存使用情况

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

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

used_memory_peak:1800800:redis使用内存的峰值

系统巡检:硬件巡检,数据库,nginx,redis,docker,k8s

redis-cli info memory | grep ratio:过滤内存碎片

内存碎片率:used_memory_rss/used_memory

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

allocator_frag ratio:1.19

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

allocator_rss_ratio:7.15

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

rss_overhead_ratio:0.31

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

mem_fragmentation_ratio:3.33

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

碎片可以自动清理(手动清理redis-cli memory purge和自动清理在配置文件redis最后一行添加activedefrag yes)

设置redis的最大内存阀值:(在/etc/redis/6379.conf中568行maxmemory 1gb)

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

key回收的策略:(要先设置上面的阀值

配置文件redis/5379.conf,598行增加

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占用的内存的效率问题如何解决?

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

2、设置redis占用系统内存的阀值(在/etc/redis/6379.conf中568行maxmemory 1gb),避免占用系统全部内存

3、内存碎片清理(手动清理redis-cli memory purge和自动清理在配置文件redis最后一行添加activedefrag yes

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

maxmemory-policy noeviction:禁止键值对回收(不擅长任何键值对,直到redis把内存塞满,写不了,报错为止)

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

redis雪崩(缓存雪崩):

大量的应用请求无法在redis缓存当中处理,请求会全部发送到后台数据库,数据库并发能力本身就差。一旦高并发,数据库会很快崩溃

redis集群大面积故障

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

redis实例宕机

解决方案:

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

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

数据库不死即可,慢可以,但是不能没有响应

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

redis的缓存击穿:

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

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

redis的缓存穿透:

缓存中没有数据,数据库也没有对应数据,但是有用户一直在发起这个都没有的请求,而且请求的数据格式很大

一般这种情况就是黑客利用漏洞进行攻击,压垮应用数据库

redis的集群:

1、持久化

2、高可用  主从复制  哨兵模式  集群

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

          主从复制实现数据的多机备份,以及读写分离(主服务器负责写,从服务器只能读)

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

主从复制的工作原理:

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

redis的高可用(主从复制和哨兵模式)_第1张图片

主从复制的实验:

(主)打开配置文件:vim /etc/redis/6379.conf

70行 IP地址改为0.0.0.0,让所有的主机都可以使用

137行 daemonize yes打开

700行 appendonly no打开变成yes

重启配置文件:/etc/init.d/redis_6379 restart

(从)打开配置文件:vim /etc/redis/6379.conf

70行 IP地址改为0.0.0.0,让所有的主机都可以使用

137行 daemonize yes打开

288行添加一行replicaof 192.168.233.11 6379

700行 appendonly no打开变成yes

哨兵模式:先有主从再有哨兵

在主从复制的基础之上,实现主节点故障的自动切换

哨兵模式的原理:

哨兵:分布式系统,用于在主从结构之间,对每台redis的服务进行监控

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

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

哨兵模式的结构:

哨兵节点:监控,不存储数据

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

redis的高可用(主从复制和哨兵模式)_第2张图片

主:192.168.233.11

从:192.168.233.12

从:192.168.233.13

哨兵模式的实验:

(主)cd /opt/

cd redis-5.0.7/

vim sentinel.conf

17行注释取消掉protected-mode no

26行daemonize no改成yes

36行logfile "/var/log/sentinel.log"

65行dir "/var/lib/redis/6379"

84行sentinel monitor mymaster 192.168.233.11 6379 2

启动配置文件redis-sentinel sentinel.conf &

redis-cli -p 26379 info Sentinel

ps -elf | grep redis

(从)cd /opt/

cd redis-5.0.7/

vim sentinel.conf

17行注释掉protected-mode no

26行 daemonize no改为yes

36行logfile "/var/log/sentinel.log"

65行dir "/var/lib/redis/6379"

84行sentinel monitor mymaster 192.168.233.11 6379 2

启动配置文件redis-sentinel sentinel.conf &

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