redis
Redis应⽤场景
1 | 1.缓存-键过期 |
Redis的安装部署
1.Redis官⽹
1 | https://redis.io/download |
2.版本选择
1 | 2.x ⾮常⽼ |
3.规划⽬录
1 | /data/soft 下载⽬录 |
4.安装命令
1 | mkdir /data/soft -p |
5.编写配置⽂件
1 | mkdir -p /opt/redis_6379/{conf,logs,pid} |
6.启动命令
1 | redis-server /opt/redis_6379/conf/redis_6379.conf |
7.检查
1 | ps -ef|grep redis |
8.连接 redis
1 | [root@db01 ~]# redis-cli |
9.关闭命令
1 | 第⼀种: |
10.system 启动配置
1 | groupadd redis -g 1000 |
Redis全局命令
1.Redis 数据格式
1 | key:value |
2.写⼊测试命令
1 | set k1 v1 |
3.查看所有的**key-**注意!!!此操作未满18岁,请在⽗⺟陪同下操 作!!!
1 | 线上⽣产禁⽌执⾏!!! |
4.查看有多少个key
1 | DBSIZE |
5.查看某个key是否存在
1 | EXISTS k1 |
6.删除KEY
1 | DEL k1 |
7.键过期
设置过期时间 :
1 | EXPIRE k1 10 |
查看key是否过期 :
1 | TTL k1 |
取消过期时间 :
1 | 第⼀种⽅法: |
字符串操作
1.设置⼀个key
1 | set k1 v1 |
2.查看⼀个key
1 | get k1 |
3.设置多个key
1 | MSET k1 v1 k2 v2 k3 v3 |
4.查看多个key
1 | MGET k1 k2 k3 |
5.天然计数器
1 | 加1: |
列表操作
1.插⼊列表
1 | 从左边压⼊数据: |
2.查看列表⻓度
1 | LLEN list1 |
3.查看列表内容
1 | LRANGE list1 0 -1 |
4.删除列表元素
1 | RPOP list1 |
5.删除整个列表
1 | DEL list1 |
HASH操作
1.mysql数据格式如何缓存到redis
1 | mysql数据格式: |
2.创建⼀个HASH数据
1 | HMSET user:1 name boss job it age 18 |
3.查看hash⾥的指定字段的值
1 | select name from user where id = 1 ; |
4.查看hash⾥的所有字段的值
1 | select * from user where id = 1 ; |
集合操作
1.创建集合
1 | SADD set1 1 2 3 |
2.查看集合成员
1 | SMEMBERS set1 |
3.查看集合的交集
1 | 127.0.0.1:6379> SINTER set1 set2 |
4.查看集合的差集
1 | 127.0.0.1:6379> SMEMBERS set1 |
5.查看集合的并集
1 | 127.0.0.1:6379> SUNION set1 set2 |
有序集合
1.添加有序集合
1 | ZADD bj67 100 wei |
2.计算成员个数
1 | ZCARD bj67 |
3.计算某个成员分数
1 | ZSCORE bj67 wei |
4.按照升序查看成员名次
1 | ZRANK bj67 cookzhang |
5.按照降序查看成员名次
1 | ZREVRANK bj67 wei |
6.删除成员
1 | ZREM bj67 cookzhang |
7.返回指定排名范围的成员
1 | 127.0.0.1:6379> ZRANGE bj67 0 -1 |
8.返回指定分数范围的成员
1 | 127.0.0.1:6379> ZRANGEBYSCORE bj67 50 100 |
9.增加成员分数
1 | ZINCRBY bj67 50 wei |
持久化
1.RDB持久化和AOF持久化
1 | RDB: 类似于快照,当前内存⾥的数据的状态持久化到硬盘 |
2.配置RDB持久化
1 | save 900 1 |
3.RDB持久化结论:
1 | 没配置save参数时: |
⽇志内容:
1 | 8952:M 13 Apr 2020 17:33:12.947 # User requested shutdown... |
4.AOF持久化配置
1 | appendonly yes |
5.AOF重写机制
1 | 执⾏的命令 aof记录 redis⾥的数据 |
6.AOF和RDB读取实验
实验背景 :
1 | aof和rdb同时存在,redis重启会读取哪⼀个数据? |
实验步骤:
1 | set k1 v1 |
实验结论:
1 | 当aof和rdb同时存在的时候,redis会优先读取aof的内容 |
7.AOF模拟故障
损坏实验结论:
1 | 1.aof修复命令不要⽤,因为他的修复⽅案⾮常粗暴,⼀⼑切,从出错的地⽅到最后全部删除 |
kill -9 实验 :
1 | for i in {1..10000};do redis-cli set key_${i} v_${i} && echo "${i} is ok";done |
结论:
1 | 1.aof相对⽐较安全,最多丢失1秒数据 |
8.如果设置了过期时间,恢复数据后会如何处理?
1 | 1.aof⽂件会记录下过期时间 |
9.AOF RDB如何选择
1 | https://redis.io/topics/persistence |
redis⽤户验证
1.配置密码认证功能
1 | requirepass 123456 |
2.使⽤密码
第⼀种:
1 | [root@db01 ~]# redis-cli |
第⼆种:
1 | [root@db01 ~]# redis-cli -a '123456' get k1 |
3.为什么redis的密码认证这么简单?
1 | 1.redis⼀般都部署在内⽹环境,默认是相对⽐较安全的 |
禁⽤或重命名危险命令
1.禁⽤危险命令
1 | rename-command KEYS "" |
2.重命名危险命令
1 | rename-command KEYS "QQ526195417" |
主从复制
1.快速部署第⼆台Redis服务器
1 | rsync -avz 10.0.0.51:/opt/redis* /opt/ |
报错总结:
1 | 1.在db01上执⾏了命令 |
2.db01插⼊测试命令
1 | for i in {1..1000};do redis-cli set key_${i} v_${i} && echo "${i} is ok";done |
3.配置主从复制
⽅法1:临时⽣效
1 | redis-cli -h 10.0.0.52 SLAVEOF 10.0.0.51 6379 |
⽅法2:写进配置⽂件永久⽣效
1 | SLAVEOF 10.0.0.51 6379 |
4.主从复制流程
1.简单流程
1 | 1.从节点发送同步请求到主节点 |
5.取消复制
1 | SLAVEOF no one |
6.主从复制注意
1 | 1.从节点只读不可写 |
7.安全的操作
1 | ⼀定要做好数据备份,⽆论是主节点还是从节点,操作前最好做下备份 |
Redis Sentinel(哨兵)
1.哨兵的作⽤
1 | 1.解决主从复制需要⼈为⼲预的问题 |
2.⽬录和端⼝规划
1 | redis节点 6379 |
3.部署3台redis单节点主从关系
db01操作
1 | pkill redis |
db02和db03操作
1 | ssh-keygen |
4.配置主从复制
1 | redis-cli -h 10.0.0.52 slaveof 10.0.0.51 6379 |
5.部署哨兵节点**-3**台机器都操作
1 | mkdir -p /data/redis_26379 |
关键配置解释:
1 | sentinel monitor myredis 10.0.0.51 6379 2 |
6.哨兵注意
1 | 1.哨兵发起故障转移的条件是master节点失去联系,从节点挂掉不会发起故障转移 |
7.验证主机点
1 | redis-cli -h 10.0.0.51 -p 26379 SENTINEL get-master-addr-by-name myredis |
8.哨兵的常⽤命令
1 | redis-cli -h 10.0.0.51 -p 26379 SENTINEL get-master-addr-by-name myredis |
9.模拟故障转移
模拟⽅法:
1 | 关闭redis当前的主节点 |
流程:
1 | 1)在从节点列表中选出⼀个节点作为新的主节点,选择⽅法如下: |
结论:
1 | 主节点挂掉,哨兵会选举新的主节点 |
10.故障修复重新上线
1 | 启动单节点 |
11.哨兵加权选举
查看权重
1 | redis-cli -h 10.0.0.51 -p 6379 CONFIG GET slave-priority |
暗箱操作:假如选中53作为最新的master
1 | redis-cli -h 10.0.0.51 -p 6379 CONFIG SET slave-priority 0 |
检查:
1 | redis-cli -h 10.0.0.51 -p 6379 CONFIG GET slave-priority |
主动发⽣选举
1 | redis-cli -h 10.0.0.51 -p 26379 sentinel failover myredis |
Redis集群-最新版5.x
1.哨兵的不⾜
1 | 1.主库写压⼒太⼤ |
2.集群的重要概念
1 | 1.Redis集群,⽆论有⼏个节点,⼀共只有16384个槽位 |
3.⽬录规划
1 | 主节点 6380 |
4.db01的操作
1 | #1.发送SSH认证,⽅便后⾯传输 |
5.db02的操作
1 | #1.替换db01发送过来的⽂件并修改IP地址 |
6.db03的操作
1 | #1.替换db01发送过来的⽂件并修改IP地址 |
7.集群⼿动发现节点
1 | redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.52 6380 |
8.集群⼿动分配槽位
1.槽位规划
1 | db01:6380 5461 0-5460 |
2.分配槽位
1 | redis-cli -h 10.0.0.51 -p 6380 CLUSTER ADDSLOTS {0..5460} |
3.查看集群状态
1 | redis-cli -h 10.0.0.51 -p 6380 CLUSTER NODES |
9.⼿动分配复制关系
1.先获取集群节点信息
1 | redis-cli -h 10.0.0.52 -p 6381 CLUSTER nodes |
2.过滤删除不必要的信息
1 | 6380的ID 10.0.0.51 |
3.配置复制关系
1 | redis-cli -h 10.0.0.51 -p 6381 CLUSTER REPLICATE db02的6380的ID |
4.检查复制关系
1 | redis-cli -h 10.0.0.51 -p 6381 CLUSTER NODES |
集群写⼊数据
1.尝试插⼊⼀条数据
1 | [root@db01 ~]# redis-cli -h 10.0.0.51 -p 6380 |
2.⽬前的现象
1 | 1.在db01的6380上插⼊数据提示错误 |
3.问题原因
1 | 因为集群模式有ASK规则,加⼊-c参数后,会⾃动跳转到⽬标节点处理并由⽬标节点返回信息。 |
验证集群hash是否⾜够随机⾜够平均
1.写⼊测试命令
1 | for i in {1..1000};do redis-cli -c -h 10.0.0.51 -p 6380 set k_${i} v_${i} && echo "${i} is ok";done |
2.验证⾜够平均
1 | [root@db01 ~]# redis-cli -c -h 10.0.0.51 -p 6380 DBSIZE |
3.验证⾜够随机
1 | redis-cli -c -h 10.0.0.51 -p 6380 keys \* > keys.txt |
4.允许节点的槽个数误差在**2%**以内的依据
1 | [root@db01 ~]# redis-cli --cluster rebalance 10.0.0.51:6380 |
5.检查集群健康状态
1 | [root@db01 ~]# redis-cli --cluster info 10.0.0.51:6380 |
使⽤⼯具⾃动部署redis集群-通⽤ ruby法
1.安装依赖-只要在db01上操作
1 | yum install -y rubygems |
2.还原集群环境
1 | redis-cli -c -h 10.0.0.51 -p 6380 flushall |
3.快速部署Redis集群
1 | cd /opt/redis/src/ |
使⽤⼯具⾃动部署redis集群-⾼科技版
1.还原集群状态
1 | redis-cli -c -h 10.0.0.51 -p 6380 flushall |
2.快速部署Redis集群
1 | redis-cli --cluster create 10.0.0.51:6380 10.0.0.52:6380 10.0.0.53:6380 10.0.0.51:6381 10.0.0.52:6381 10.0.0.53:6381 --cluster-replicas 1 |
3.检查集群
1 | redis-cli --cluster info 10.0.0.51:6380 |
使⽤⼯具扩容
1.需要考虑的问题
1 | 1.迁移时槽的数据会不会迁过去 |
2.如何设计实验验证迁移过程是否受影响
1 | 1.迁移过程中,⼀个窗⼝读数据,⼀个窗⼝写数据 |
3.创建新节点
1 | mkdir -p /opt/redis_{6390,6391}/{conf,logs,pid} |
4.扩容步骤
1 | #重新分配槽位 |
5.验证命令
写命令
1 | for i in {1..1000};do redis-cli -c -h 10.0.0.51 -p 6380 set k_${i} v_${i} && echo ${i} is ok;sleep 0.5;done |
读命令
1 | for i in {1..1000};do redis-cli -c -h 10.0.0.51 -p 6380 get k_${i};sleep 0.5;done |
使⽤⼯具收缩
1.缩容命令
1 | #重新分配槽 |
2.检查命令
1 | redis-cli --cluster info 10.0.0.51:6380 |
3.归⼀再分配法
- 归⼀
1 | 把要缩容节点的数据都扔到其中⼀个节点 |
- 分配
1 | 然后利⽤集群重新负载均衡命令重新分配 |
模拟故障转移
1.关闭主节点,测试集群是否依然可⽤
1 | 10.0.0.51:6381> CLUSTER NODES |
2.主动发起故障转移
1 | redis-cli -c -h 10.0.0.51 -p 6380 CLUSTER FAILOVER |
迁移过程意外中断如何修复
1.模拟场景:迁移时⼈为中断,导致槽的状态不对
1 | [5754->-f765d849975ddfda7029d16be717ddffcc4c4bc7] |
2.⼿动修复
1 | redis-cli -c -h 10.0.0.52 -p 6380 CLUSTER SETSLOT 5754 STABLE |
3.使⽤⼯具修复-⽣产建议使⽤⼯具修复
1 | redis-cli --cluster fix 10.0.0.51:6380 |
Redis常⽤运维⼯具
1.使⽤redis-cli数据迁移
1 | 4.x以前的数据迁移使⽤第三⽅⼯具 |
2.分析key⼤⼩
使⽤redis-cli分析
1 | redis-cli --bigkeys |
使⽤第三⽅分析⼯具:
1 | 安装命令 : |
⽣成测试数据
1 | redis-cli set txt $(cat txt.txt) |
⽣成rdb⽂件
1 | redis-cli bgsave |
使⽤⼯具解析RDB⽂件
1 | cd /data/redis_6379/ |
过滤分析
1 | awk -F"," '{print $4,$3}' redis_6379.rdb.csv |sort -r |
3.性能测试
1 | redis-benchmark -n 10000 -q |
Redis内存管理
1.⽣产上⼀定要配置Redis内存限制
1 | maxmemory NG |
2.内存回收机制
1 | 1.noevicition 默认策略,不会删除任务数据,拒绝所有写⼊操作并返回客户端错误信息,此时只响应读操作 |
3.⽣产上redis限制多⼤内存
1 | 先空出来系统⼀半内存 |
4.优化建议
1 | 1.专机专⽤,不要跑其他的服务 |