Redis知识梳理
2020-10-30 16:52:54 32 举报AI智能生成
Redis知识梳理
作者其他创作
大纲/内容
应用场景
1.缓存-键过期
把session数据缓存在redis里，过期删除
换用用户信息，缓存mysql部分的数据，用户先访问redis,如果redis没命中，在访问mysql，然后回写给redis
商城优惠卷过期
短信验证码过期
2.排行榜-列表&有序集合
热度/点击量
直播间礼物打赏排行榜
3.计数器-天然计数器
帖子浏览数
视频播放次数
评论次数
点赞/点踩
4.社交网络-集合
粉丝
共同好友/可能认识的人
兴趣爱好/标签
检查用户注册名是否已经被注册
5.消息队列-列表
ELK缓存日志
聊天记录
把session数据缓存在redis里，过期删除
换用用户信息，缓存mysql部分的数据，用户先访问redis,如果redis没命中，在访问mysql，然后回写给redis
商城优惠卷过期
短信验证码过期
2.排行榜-列表&有序集合
热度/点击量
直播间礼物打赏排行榜
3.计数器-天然计数器
帖子浏览数
视频播放次数
评论次数
点赞/点踩
4.社交网络-集合
粉丝
共同好友/可能认识的人
兴趣爱好/标签
检查用户注册名是否已经被注册
5.消息队列-列表
ELK缓存日志
聊天记录
数据类型
字符串
列表
集合
有序集合
哈希
数据持久化
RDB
RDB: 类似于快照，当前内存里的数据的状态持久化到硬盘
优点：压缩格式/恢复速度快
缺点：不是实时的，可能会丢数据，操作比较重量
优点：压缩格式/恢复速度快
缺点：不是实时的，可能会丢数据，操作比较重量
设置参数
save 900 1
save 300 10
save 60 10000
save 300 10
save 60 10000
注意事项
1.主从复制基于RDB
2.RDB属于重量级操作,不适合频繁保存
3.持久化数据文件名要和配置文件里定义的一样才能被识别
4.RDB文件只有一个数据文件，迁移和备份只要这一个RDB文件即可
2.RDB属于重量级操作,不适合频繁保存
3.持久化数据文件名要和配置文件里定义的一样才能被识别
4.RDB文件只有一个数据文件，迁移和备份只要这一个RDB文件即可
AOF
AOF: 类似于mysql的binlog，可以设置成每秒/每次操作都以追加的形式保存在日志文件中
优点：安全，最多只损失1秒的数据，具备一定的可读性
缺点：文件比较大，恢复速度慢
优点：安全，最多只损失1秒的数据，具备一定的可读性
缺点：文件比较大，恢复速度慢
设置参数
appendonly yes
appendfilename "redis.aof"
appendfsync everysec
appendfilename "redis.aof"
appendfsync everysec
注意事项
1.当aof和rdb同时存在的时候，redis会优先读取aof的内容
2.aof修复命令不要用，因为他的修复方案非常粗暴，一刀切，从出错的地方到最后全部删除
3.任何操作之前，先备份数据
2.aof修复命令不要用，因为他的修复方案非常粗暴，一刀切，从出错的地方到最后全部删除
3.任何操作之前，先备份数据
高可用架构
主从复制
命令
SLAVEOF 10.0.0.51 6379
SLAVEOF no one
主从复制流程
1.从节点发送同步请求到主节点
2.主节点接收到从节点的请求之后,做了如下操作
- 立即执行bgsave将当前内存里的数据持久化到磁盘上
- 持久化完成之后,将rdb文件发送给从节点
3.从节点从主节点接收到rdb文件之后,做了如下操作
- 清空自己的数据
- 载入从主节点接收的rdb文件到自己的内存里
4.后面的操作就是和主节点实时的了
2.主节点接收到从节点的请求之后,做了如下操作
- 立即执行bgsave将当前内存里的数据持久化到磁盘上
- 持久化完成之后,将rdb文件发送给从节点
3.从节点从主节点接收到rdb文件之后,做了如下操作
- 清空自己的数据
- 载入从主节点接收的rdb文件到自己的内存里
4.后面的操作就是和主节点实时的了
注意事项
1.从节点会先清空自己的数据,再导入主节点的RDB文件
2.主节点故障了,从节点不会自动切换,需要人工介入
3.无论是哨兵还是集群,都要依赖于主从复制
4.从节点只读不可写
2.主节点故障了,从节点不会自动切换,需要人工介入
3.无论是哨兵还是集群,都要依赖于主从复制
4.从节点只读不可写
哨兵
作用
1.解决主从复制需要人为干预的问题
2.提供了自动的高可用方案
2.提供了自动的高可用方案
部署流程
1.安装redis数据节点和哨兵节点
2.配置redis主从复制
3.配置哨兵监控主从复制
选举条件
1.选择权重最大的
2.选择数据最新的从节点
3.选择UUID最小的
2.选择数据最新的从节点
3.选择UUID最小的
注意事项
1.哨兵发起故障转移的条件是master节点失去联系，从节点挂掉不会发起故障转移
2.哨兵会自己维护配置文件，不需要手动修改
3.如果主从的结构发生变化，哨兵之间会自动同步最新的消息并且自动更新配置文件
4.哨兵启动完成之后，以后不要再自己去设置主从关系
2.哨兵会自己维护配置文件，不需要手动修改
3.如果主从的结构发生变化，哨兵之间会自动同步最新的消息并且自动更新配置文件
4.哨兵启动完成之后，以后不要再自己去设置主从关系
集群
作用
1.解决哨兵架构主库写压力太大的问题
2.解决哨兵架构资源利用率不高的问题
3.解决哨兵架构连接过程繁琐，效率低的问题
2.解决哨兵架构资源利用率不高的问题
3.解决哨兵架构连接过程繁琐，效率低的问题
重要概念
1.Redis集群，无论有几个节点，一共只有16384个槽位
2.所有的槽都必须被正确分配，哪怕有1个槽不正常，整个集群都不可用
3.每个节点的槽的顺序不重要，重要的是槽的数量
4.HASH算法足够平均，足够随机
5.每个槽被分配到数据的概率是大致相当的
6.集群的高可用依赖于主从复制
7.集群节点之间槽位的数量允许在2%的误差范围内
8.集群通讯会使用基础端口号+10000的端口，自动创建的，不是配置文件配置的，生产要注意的是防火墙注意要放开此端口
2.所有的槽都必须被正确分配，哪怕有1个槽不正常，整个集群都不可用
3.每个节点的槽的顺序不重要，重要的是槽的数量
4.HASH算法足够平均，足够随机
5.每个槽被分配到数据的概率是大致相当的
6.集群的高可用依赖于主从复制
7.集群节点之间槽位的数量允许在2%的误差范围内
8.集群通讯会使用基础端口号+10000的端口，自动创建的，不是配置文件配置的，生产要注意的是防火墙注意要放开此端口
集群关键参数
cluster-enabled yes
cluster-config-file nodes_6380.conf
cluster-node-timeout 15000
cluster-config-file nodes_6380.conf
cluster-node-timeout 15000
部署流程
1.安装配置启动节点
2.集群节点互相发现
3.集群节点分配槽位
4.配置集群的复制节点
扩容流程
1.安装新节点
2.重新分配槽位
3.其他节点把自己的槽分一部分给新节点
4.调整复制关系
收缩流程
1.重新分配槽位
2.要下线的节点把数据分给其他节点
3.使用工具下线节点
注意事项
1.监控集群的健康状态是否为ok
数据迁移
4.x之前
第三方工具迁移
4.x之后
使用redis-cli工具迁移
运维工具
分析key大小
自带命令
检查集群状态
检查集群是否平均负载
自动修复集群错误状态
故障案例
1.内存满了,触发了淘汰机制
1.默认不做任何处理,也不接受写的请求
2.随机删除KEY
3.随机删除有过期时间的key
4.按过期时间顺序删除key
2.集群迁移过程中断,导致槽位的状态不对
1.使用工具恢复槽的状态
2.使用命令恢复槽的状态
3.初始化集群的时候,分配槽位分配错了
1.使用工具重新分配
4.办公室刷帖导致封锁
1.后台开发刷贴工具,使用Redis的计数器+N
5.优惠卷不过期
1.提前问开发要需要监控的key
2.编写脚本,如果这些key出现了不过期,就报警
2.编写脚本,如果这些key出现了不过期,就报警
6.被黑客利用Redis漏洞入侵
1.本质是利用了redis的热更新配置，可以动态的设置数据持久化的路径和持久化文件名称
2.首先攻击者可以远程登陆redis，然后将攻击者的ssh公钥当作一个key存入redis里
3.利用动态修改配置，将持久化目录保存成/root/.ssh
4.利用动态修改配置,将持久化文件名更改为authorized_keys
5.执行数据保存命令，这样就会在生成/root/,ssh/authorized_keys文件
6.而这个文件里包含了攻击者的密钥，所以此时攻击者可以免密登陆远程的服务器了
2.首先攻击者可以远程登陆redis，然后将攻击者的ssh公钥当作一个key存入redis里
3.利用动态修改配置，将持久化目录保存成/root/.ssh
4.利用动态修改配置,将持久化文件名更改为authorized_keys
5.执行数据保存命令，这样就会在生成/root/,ssh/authorized_keys文件
6.而这个文件里包含了攻击者的密钥，所以此时攻击者可以免密登陆远程的服务器了
0 条评论
下一页
