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