一、前期准备
至少准备三台服务器为主从复制、哨兵的实验做准备
一台主redis、两台从redis
二、Redis性能管理
2.1 查看Redis内存使用
查看Redis内存使用——info memory
2.2 内存使用率
- 1<内存碎片<1.5表示合理的
- 内存碎片大于>1.5,需要输入shutdown save命令,让Redis数据库执行保存操作并关闭redis服务
- 内存碎片<1,redis内存配置超出物理内存,需要增加可用物理内存
2.3 内回收key
内存清理策略,保证合理分配redis有限的内存资源
当达到设置的最大阈值时,需选择一种key的回收策略,默认情况下回收策略是禁止删除
配置文件中修改maxmemory-policy属性值:
vim /etc/redis/6379.conf
------598------
- maxmemory-policy noenviction
- volatile-lru:使用LRU算法已从设置过期时间的数据集合中淘汰数据(移除最近最少使用的key,针对设置了TTL的key)
- volatile-ttl:从已设置过期时间的数据集合中挑选即将过期的数据淘汰(移除最近过期的key)
- volatitle-random:从已设置过期时间的数据集合中随机挑选数据淘汰(在设置了TTL的key里随机移除)
- allkeys-lru:使用LRU算法从所有数据集合淘汰数据(移除最少使用的key,针对所有的key)
- allkeys-random:从数据集合中任意选择数据淘汰(随机移除key)
- noenviction:禁止淘汰数据(不删除直到写满时报错)
2.4 缓存的穿透、击穿和雪崩
- 穿透:黑客或者其他非正常用户频繁进行很多非正常的url访问,使得redis查询不到数据库
- 击穿:redis某个key过期了,大量访问这个key(热门key)
- 雪崩:redis某个key过期了,大量正常访问某个key
三、主从复制
3.1 主从复制的原理
- 从服务器向主服务器发送sync同步数据请求
- 主redis会fork一个子进程,然后会产生RDB文件(完全备份的文件)的过程,客户端还在持续地写入redis
- RDB文件持久化完成后,主redis会将RDB文件和缓存起来的命令推送给从服务器
- 复制、推送完后,主redis会持续地同步操作命令,会利用AOF(增备)持久化功能
- 在下一台redis接入主从复制之前会持续地利用AOF的方式来同步数据给从服务器,当出现故障时通过投票选择新的master并将所有slave连接新的master。整个哨兵集群不得少于3个节点。
3.2 主从复制的部署
3.2.1 首先关闭防火墙
3.2.2 重命名
3.2.2.1 为主服务器重命名
3.2.2.2 为从服务器1重命名
3.2.2.3 为从服务器2重命名
3.2.3 编辑hosts配置文件
3.2.3.1 为主服务器编辑hosts配置文件
3.2.3.2 为从服务器1编辑hosts配置文件
3.2.3.3 为从服务器2编辑配置hosts配置文件
3.2.4 为从服务器1远程拷贝文件
3.2.5 编译安装
3.2.6 为服务器2安装gcc、gcc-c++
3.2.7 在从服务器2上编译安装
3.2.8 切换到从服务1下运行脚本文件
3.2.9 切换到从服务2下运行脚本文件
3.2.10 在主服务器上编辑配置文件并重新启动
3.2.11 在从服务器1上编辑配置文件并重新启动
3.2.12 在从服务器2上编辑配置文件并重新启动
3.2.13 在主服务上查看日志
3.2.14 在主服务器上显示redis信息
3.2.15 完成主从复制操作
四、 redis哨兵模式
4.1 核心功能
在主从复制的基础上,引入了主节点的自动故障转移
4.2 哨兵模式的定义
哨兵模式是一个分布式系统,用于主从结构中的每台服务器进行监测。
4.3 哨兵的组成
- 哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的redis节点,不存储数据
- 数据节点:主节点和从节点都是数据节点
4.4 哨兵模式的原理
- 哨兵对主从复制集群进行监控,监控对象“所有redis的数据节点”
- 哨兵与哨兵之间相互监控,监控的对象是哨兵彼此
它的监测目的是:
- 检测彼此的存活状态
- 实现自动故障切换
4.5 故障切换原理
- 当master挂掉,哨兵会及时发现,发现之后进行投票机制选举出一个新的master服务器(一定是基数)
- 完成slave向master的主从切换
- 完成其他的从服务器对新的master配置
4.6 哨兵的实验部署
4.6.1 为主从服务器进行操作(一)
进入redis下,编辑sentinel配置文件,并且在后台运行
4.6.2 为主从服务器进行操作(二)
显示信息内容