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台

高可用方案：

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

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

主从复制实现数据的多级备份，以及读写分离（主负责写，从负责读）

缺点：故障无法自动恢复。需要人工干预，写操作无法实现负载均衡。只有主能够写。

主从复制：和mysql的主从复制类型，主可以写，写入住的数据通过RDB方式数据同步到从服务器。从不能更新到主。也是哨兵模式的基础

主从复制的工作原理：

1. 主节点 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，来实现主节点的转义和故障恢复通知

主节点选举的过程：

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

主从+哨兵

哨兵模式，源码包里自带

**主从配置方式一致：**三台可以同时配置

进入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同步数据