redis的性能管理和雪崩

redis的性能管理

redis的数据是缓存在内存当中的

系统巡检：

硬件巡检、数据库、nginx、redis、docker、k8s

运维人员必须要关注的redis指标

在日常巡检中需要经常查看这些指标使用情况

info memory
#查看redis使用内存的指标
used_memory:11285512
#数据占用的内存（单位是字节）
used_memory_rss:24285184
#向操作系统申请的内存（单位是字节）
used_memory_peak:23952088
#redis使用内存的峰值（单位是字节）内存碎片率：used_mem0ry_rss/used_memory
#系统已经分配给了redis，但是未能够有效利用的内存

如何查看内存碎片率？

内存碎片率：used_mem0ry_rss/used_memory
#系统已经分配给了redis，但是未能够有效利用的内存redis-cli info memory | grep ratio
#查看内存碎片率allocator_frag_ratio:1.03
#分配器碎片比例。由redis主进程调度时产生的内存，比例越小越好，值越高，内存浪费越多。
allocator_rss_ratio:1.80
#表示分配器占用物理内存的比例，主进程调度过程中占用了多少物理内存
rss_overhead_ratio:1.13
#RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
mem_fragmentation_ratio:2.16
#内存碎片的比例。值越低越好。表示内存的使用率越高

如何来进行清理碎片？

自动清理碎片
vim /etc/redis/6379.conf
最后一行插入
activedefrag yes
#自动清理碎片
/etc/init.d/redis_6379.conf restart
#重启redis服务手动清理碎片
redis-cli memory purge
#手动清理碎片

设置redis的最大内存阈值

vim /etc/redis/6379.conf
567行
maxmemory 1gb
#一旦到达阈值会开始自动清理，开启key的回收机制

key的回收机制是什么？

就是回收键值对

key回收的策略

vim /etc/redis/6379.conf598行
maxmemory-policy volatile-lru
#使用redis内置的LRU算法。把已经设置了过期时间的键值对淘汰出去。移除最近最少使用的键值对（只是针对已经设置了过期时间的键值对）maxmemory-policy volatile-ttl
#在已经设置了过期时间的键值对中，挑选一个即将过期的键值对（针对的是有设置生命周期的键值对）。maxmemory-policy volatile-random
#在已经设置了过期时间的键值对中，挑选数据然后随机淘汰一个键值对（对设置了过期时间的键值对进行随机移除）allkeys-lru
#根据redis内置的lru算法，对所有的键值对进行淘汰。移除最少使用的键值对。（针对所有的键值对）allkeys-random
#在所有键值对中，任意选择数据进行淘汰maxmemory-policy noeviction
#禁止对键值对回收（不删除任何键值对，知道redis把内存塞满，写不下，报错为止）

工作用要么保证数据完整性使用maxmemory-policy noeviction 要么使用maxmemory-policy volatile-ttl挑选一个即将过期的键值对清除

在工作当中一定要给redis占用内存设置阈值否则会将整个系统内存占满为止

redis的雪崩

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

什么情况可能会导致雪崩出现？

1、 redis集群大面积故障

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

3、 redis实例宕机

防止雪崩出现的方法

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

事中：在国内用得较多的方式：HySTRIX有三种方式：熔断、降级、限流。可以使用这三个手段来降低雪崩发生之后的损失。确保数据库不死即可，慢可以，但是不能没有响应。

事后：redis数据备份的方式来恢复数据或使用快速缓存预热的方式

redis的缓存击穿

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

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

redis缓存穿透

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

可能是黑客在利用漏洞攻击，压垮应用数据库。

redis的集群架构

高可用方案：

1、 持久化

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

主从复制

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

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

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

主从复制的工作原理

1、 主节点（master）和从节点（slave）组成。数据的复制时单项的，只能从主节点到从节点。

主从复制节点最少要有三台

主从复制的数据流向和工作流程图：

1、 从与主建立连接。从会发送一个syn command，请求和主建立连接

2、 主节点收到请求之后，不管slave是第一次连接还是重新连接。主节点都会启动一个后台进程。执行BGsave。

3、 主节点会把所有修改数据记录的命令也加载到缓存和数据文件之中。

4、 数据文件创建完毕之后，是由主系欸但把数据文件传送给从节点，从节点会把数据文件保存到硬盘当中后再加载到内存中去。

主从复制推荐使用AOF，通过AOF文件实现实时持久化，主从节点都开启AOF持久化服务。从节点同步的就是aof文件。

主从复制工作流程图：

主从复制实验

实验准备：
20.0.0.26  master
20.0.0.27  slave1
20.0.0.28  slave2
三台机器都需要安装redis服务做完后拍个快照systemctl stop firewalld
setenforce 0
#关闭三台机器的防火墙和安全机制主节点：
vim /etc/redis/6379.conf
修改网段 0.0.0.0
daemonize yes
700行
开启aof模式
/etc/init.d/redis_6379 restart从节点1：
vim /etc/redis/6379.conf
修改网段 0.0.0.0
288行
replicaof <masterip> <masterport>
replicaof 20.0.0.26 6379
#指向主的ip和端口
700行
开启aof模式
/etc/init.d/redis_6379 restart
开启了指向后从节点将变为只读模式从节点2：
vim /etc/redis/6379.conf
修改网段 0.0.0.0
288行
replicaof <masterip> <masterport>
replicaof 20.0.0.26 6379
#指向主的ip和端口
700行
开启aof模式
/etc/init.d/redis_6379 restart
开启了指向后从节点将变为只读模式主节点：
tail -f /var/log/redis_6379.log
#查看主节点日志，看是否指向成功验证效果：
主从都登录redis
主节点：
set test1 1
#创建一个键值对
主上创建成功后到两台从节点查看一下看是否可以查看到从节点：
set test2 2
#在从节点上测试是否为只读模式
报错，说明搭建成功从节点已经设置为只读模式了实验完成！redis-cli info replication
#查看主从配置信息停止一个从节点来测试。停机期间插入的数据，服务重启后依旧可以同步

哨兵模式

哨兵模式依赖于主从模式，先有主从再有哨兵

哨兵模式是在主从复制的基础上实现主节点故障的自动切换

哨兵模式的工作原理

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

哨兵模式的投票机制

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

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

哨兵模式的结构

哨兵节点和数据节点

哨兵节点：监控，不存储数据

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

哨兵模式的工作机制

哨兵模式的架构和工作机制图：

哨兵1节点会对应监控从节点1和从节点2

哨兵2节点会对应监控主节点和从节点2

哨兵3节点会监控主节点和从节点1

哨兵节点会互相监控架构内的其他节点主机

哨兵模式的投票机制：

1、 每个哨兵节点每隔1秒，通过ping命令的方式检测主从之间的心跳线。

2、 当主节点在一定时间内没有回复或者回复了错误的信息。哨兵会主观的认为主节点下线了。

3、 当有超过半数的哨兵节点认为主节点下线了，才会认为主节点是客观下线了

主节点选举过程：

哨兵节点会通过redis自带的raft算法(选举算法)，每个节点共同投票，选举出一个新的master。

新的master来实现主节点的转移和故障恢复通知

1、 已经下线的从节点，不会被选择为主节点

2、 选择配置文件当中，从节点优先级最高的 replica-priority 100

3、 选择一个复制数据最完整的从节点

哨兵模式监控的是节点不是哨兵

故障恢复可能会优点延迟

最好是以复制数据最完整的从节点作为新的主节点

哨兵模式实验

主节点：
cd redis-5.0.7
vim sentinel.conf
#哨兵模式的配置文件17行
protected-mode no
#解除注释daemonize yes
#开启后台运行逃兵模式36行
logfile "/var/log/sentinel.log"
#指定日志文件的存放位置65行
dir"/var/lib/redis/6379"
#指定数据库存放的位置85行
sentinel monitor mymaster 20.0.0.26 6379 2
#声明主节点的IP和端口号.2代表至少要有2台服务认为主已经下线才会进行主从切换。一般配置为主从服务器的一半113行
sentinel down-after-milliseconds mymaster 30000
#服务器宕机的最小时间。单位是毫秒。30秒之内如果主节点但没有响应，主观认为主下线了。时间可以改可以自定义146行
sentinel failover-timeout mymaster 180000
#服务器宕机的最大时间，180秒之内如果主节点但没有响应，从节点开始投票，客观认为主下线了。时间可以改可以自定义两台从节点配置和主节点配置一致即可三台配置完成后需要先起主节点再起从节点三台主机在redis的源码包中启动哨兵模式
redis-sentinel sentinel.conf &
#启动哨兵模式。&表示后台运行主节点：
redis-cli -p 26379 info Sentinel
#查看整个集群的哨兵情况查看主从信息：
tail -f /var/log/redis_6379.log
#查看主节点日志，查看主从信息模拟故障切换：
可能会有延迟不是立刻切换
ps-elf | grep redis
#查看主节点
kill -9 redis的主进程或者/etc/init.d/redis_6379 stop停止redis都可以测试测试新主是否可以正常插入数据
测试两从是否可以数据同步
测试旧主机是否还有插入数据旧主失去写的功能，新主增加写的功能。从2的配置文件指向了新的主
而旧主的配置文件中指向自己的配置将会消失

小模式用哨兵，大模式用集群

总结

运维人员日常巡检中关注的指标

#查看redis使用内存的指标
used_memory:11285512
#数据占用的内存（单位是字节）
used_memory_rss:24285184
#向操作系统申请的内存（单位是字节）
used_memory_peak:23952088
#redis使用内存的峰值（单位是字节）

内存碎片：

内存碎片率：used_mem0ry_rss/used_memory
#系统已经分配给了redis，但是未能够有效利用的内存redis-cli info memory | grep ratio
#查看内存碎片率allocator_frag_ratio:1.03
#分配器碎片比例。由redis主进程调度时产生的内存，比例越小越好，值越高，内存浪费越多。
allocator_rss_ratio:1.80
#表示分配器占用物理内存的比例，主进程调度过程中占用了多少物理内存
rss_overhead_ratio:1.13
#RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
mem_fragmentation_ratio:2.16
#内存碎片的比例。值越低越好。表示内存的使用率越高

如何清理碎片：

自动清理碎片
vim /etc/redis/6379.conf
最后一行插入
activedefrag yes
#自动清理碎片
/etc/init.d/redis_6379.conf restart
#重启redis服务手动清理碎片
redis-cli memory purge
#手动清理碎片

如何设置阈值：

vim /etc/redis/6379.conf567行maxmemory 1gb
#一旦到达阈值会开始自动清理，开启key的回收机制

工作用要么保证数据完整性使用maxmemory-policy noeviction 要么使用maxmemory-policy volatile-ttl挑选一个即将过期的键值对清除

在工作当中一定要给redis占用内存设置阈值否则会将整个系统内存占满为止

redis的缓存击穿：

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

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

主从复制：

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

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

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

哨兵模式：

哨兵模式监控的是节点不是哨兵

故障恢复可能会优点延迟

最好是以复制数据最完整的从节点作为新的主节点

拓展

运维人员必须要关注的redis指标：

在日常巡检中需要经常查看这些指标使用情况

info memory
#查看redis使用内存的指标
used_memory:11285512
#数据占用的内存（单位是字节）
used_memory_rss:24285184
#向操作系统申请的内存（单位是字节）
used_memory_peak:23952088
#redis使用内存的峰值（单位是字节）

如何查看内存碎片率？

内存碎片率：used_mem0ry_rss/used_memory
#系统已经分配给了redis，但是未能够有效利用的内存redis-cli info memory | grep ratio
#查看内存碎片率allocator_frag_ratio:1.03
#分配器碎片比例。由redis主进程调度时产生的内存，比例越小越好，值越高，内存浪费越多。
allocator_rss_ratio:1.80
#表示分配器占用物理内存的比例，主进程调度过程中占用了多少物理内存
rss_overhead_ratio:1.13
#RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例。比例越低越好。redis实际占用的物理内存和向系统申请的内存越接近额外的开销就越低
mem_fragmentation_ratio:2.16
#内存碎片的比例。值越低越好。表示内存的使用率越高

redis占用的内存效率问题如何解决？

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

2、 给redis设置一个占用系统内存的阈值，避免占用系统的全部内容

3、 内存碎片清理，分为手动和自动两种模式

4、配置一个合适的key的回收机制。一般都是设置写满报错的方式（maxmemory-policy noeviction），通过运维人员手动维护。或者挑选一个即将过期的键值对清除（maxmemory-policy volatile-ttl）。

redis的缓存击穿

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

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