redis的性能管理、主从复制和哨兵模式
一、redis的性能管理
redis的数据时缓存在内存中的
查看系统内存情况
info memory
used_memory:853688 redis中数据占用的内存
used_memory_rss:10522624 redis向操作系统申请的内存
used_memory_peak:853688 redis使用内存的峰值
系统巡检：硬件巡检、数据库 nginx redis docker k8s等软件巡检
vim /etc/redis/6379.conf
要设置redis最大内存阀值
一旦到达阀值，自动清理碎片，开启key的回收机制
567行
设置占用最大内存
**maxmemory 1gb #设置redis占用系统的阈值 *****资源限制重点
一定要设置占用内存的阀值
内存碎片率：used_memory_rss/used_memory=内存碎片率
内存碎片化率=redis
系统已经分配给了redis，但是redis未能够有效利用的内存
查询比率：
redis-cli info memory | grep ratio
allocator_frag_ratio:1.27
分配器碎片的比例，redis的主进程调度时产生的内存。比例要越小越好，值越高说明内存的浪费越多
allocator_rss_ratio:6.07
分配器占用物理内存的比例，告诉你主进程调度执行时占用了多少物理内存
rss_overhead_ratio:1.18
RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例，比例要越低越好，表示redis实际占用的内存和向系统申请的内存越接近，额外的开销越低
mem_fragmentation_ratio:12.72
内存碎片的比例，越低越好，内存的使用率越高，
清理碎片：
自动清理碎片：
vim /etc/redis/6379.conf
最后一行插入：
activedefrag yes
开启自动清理
要设置redis最大内存阀值
一旦到达阀值，自动清理碎片，开启key的回收机制
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 在外面
memory purge 在里面
工作中reids占用内存效率问题如何处理：
1、日常巡检中，对redis的占用情况做监控
2、设置redis占用系统内存的阀值，避免占用系统全部内存
3、内存碎片清理，手动和自动清理
4、配置合适的key回收机制
redis的集群
redis集群的三种模式 主从复制 奇数（1主2从） 哨兵模式 奇数 （1主2从） cluster 集群 6台 生产中9台
高可用方案：
- 持久化
- 高可用 主从复制 哨兵模式 集群
主从复制时redis实现高可用的基础，哨兵模式和集群都是在主从复制的基础上实现高可用的
主从复制实现数据的多级备份，以及读写分离（主负责写，从负责读）
缺点：故障无法自动恢复。需要人工干预，写操作无法实现负载均衡。只有主能够写。
主从复制：和mysql的主从复制类型，主可以写，写入住的数据通过RDB方式数据同步到从服务器。从不能更新到主。也是哨兵模式的基础
主从复制的工作原理：
- 主节点 master 从节点slave组成，数据的复制时单向的，只能从主节点到从节点
哨兵：故障自动化恢复，主从复制完成之后，从服务器会变成只读模式
故障切换时，主故障变成从，也会进入只读模式。
缺点：从节点一旦故障，读会受到影响
集群：把每两台服务器作为主从模式，形成一个大的主从的集群
解决了写操作的负载均衡。较为完善的高可用方案
缺点：保证高可用，对数据的完整性要求不高
主从复制：
主节点和从节点
数据的复制是单向的，由主复制到从
主从复制的流程：
部署主从复制
192.168.183.11 redis 主
192.168.183.12 从1
192.168.183.13 从2
关防火墙和安全机制
yum -y install ntpdate 只要涉及多台都要做服务器同步
ntpdate ntp.aliyun.com
修改master节点的配置文件
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行,修改监听地址为0.0.0.0（生产环境中，尤其是多网卡最好填写物理网卡的IP）
daemonize yes #137行，开启守护进程，后台启动
appendonly yes #700行，开启AOF持久化功能
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）
replicaof 20.0.0.41 6379 #288行,指定要同步的Master节点的IP和端口
appendonly yes #700行,修改为yes，开启AOF持久化功能
/etc/init.d/redis_6379 restart #重启redis
netstat -natp | grep redis #查看主从服务器是否已建立连接
tail -f /var/log/redis_6379.log
实验测试：
主节点创建数据，从节点是否同步
只有主节点能读写，从节点只能读
查看主从状态信息：
redis-cli info replication
哨兵模式：
先有主从然后再有哨兵，在主从复制的基础只上，实现主节点故障的自动切换。
哨兵模式的原理：
是一个分布式系统，每个节点上都有哨兵，用于在主从结构之间，对每台redis服务进行服务监控
主节点出现故障时，从节点通过投票的方式选择一个新的master
哨兵模式也需要至少三个节点
哨兵模式的结构：
哨兵节点：监控，不存储任何数据
数据节点：主节点和从节点，都是数据节点
redis工作机制：
哨兵监控的是redis的节点，不是监控哨兵
每个哨兵每隔一秒，通过ping命令的方式，检测主从之间的心跳线
主节点在一定时间内没有回复，或则回复了错误消息。这个时候，哨兵会主观的任务主节点下线了。如果有超过半数的哨兵节点认为主节点下线了，在个时候才会认为主节点是客观下线
哨兵节点通过raft算法（选举算法），每个节点共同投票，选举出一个新的master。然后新的master，来实现主节点的转义和故障恢复通知
主节点选举的过程：
- 已经下线的从节点，不会被选为主节点
- 选择配置微文件中，从节点优先级最高的，replica-priority 100
- 选择一个复制数据最完整的从节点
主从+哨兵
哨兵模式，源码包里自带
**主从配置方式一致：**三台可以同时配置
进入opt redis-5.0.7
vim /opt/redis-5.0.7/sentinel.conf
17行
protected-mode no
取消注释
关闭保护模式
21行
哨兵模式默认端口
26行
指定哨兵模式是否后台运行 改成yes
36行
是日志文件
65行
设置工作目录：
84行
指定初始的主服务器
这里的2表示至少需要2台服务器认为主已经下线，才会进行主从切换
113行
判断服务器宕掉的服务周期
146行
故障节点的最大超时时间
配置完之后
重启服务
要先启master 再启slave
都在redis原码包目录下启动的
要在reids原码包目录下，启动
redis-sentinel sentinel.conf &
一定先起主再起从
监控哨兵集群
查看整个集群的哨兵情况：
redis-cli -p 26379 info Sentinel
模拟故障：
先杀进程或暂停节点
然后投票选举一个master
测试结果，新master创建数据，slave同步数据
-1722497919683)]
配置完之后
重启服务
要先启master 再启slave
都在redis原码包目录下启动的
要在reids原码包目录下，启动
redis-sentinel sentinel.conf &
[外链图片转存中…(img-uAjf3a4U-1722497919683)]
一定先起主再起从
监控哨兵集群
查看整个集群的哨兵情况：
redis-cli -p 26379 info Sentinel
模拟故障：
先杀进程或暂停节点
[外链图片转存中…(img-VrXO1Y15-1722497919683)]
然后投票选举一个master
[外链图片转存中…(img-XiihnBUD-1722497919683)]
测试结果，新master创建数据，slave同步数据
