最近在学redis，由于笔者是学运维的，所以推荐学习运维的小伙伴参考，希望对大家有帮助！
redis运维篇上篇:http://t.csdnimg.cn/MfPud
附加redis多用户管理:http://t.csdnimg.cn/DY3yx
目录
十.redis慢日志
面试题:redis慢，怎末排查
1.查看系统资源的占用情况
2.查看慢日志情况
1.查看慢日志的默认配置
127.0.0.1:6379> config get slow*
1) "slowlog-max-len"
2) "128" #最多纪录128个
3) "slowlog-log-slower-than"
4) "10000" #默认超过10毫秒就会记录
2.设置慢日志的时间
127.0.0.1:6379> config set slowlog-log-slower-than 1000 #超过1ms会被认定为慢日志
OK
127.0.0.1:6379> config get slow*
1) "slowlog-max-len"
2) "128"
3) "slowlog-log-slower-than"
4) "1000" #1ms为慢日志
3.shell批量写入数据
for i in $(seq -w 100000);do redis-cli -a redispwd set name${i} test${i};redis-cli -a redispwd get name${i};done 2>/dev/null
4.产生慢日志
127.0.0.1:6379> keys * #当查询时间大于1ms，会产生慢日志
重复keys *操作获取多条慢日志
5.查询慢日志
127.0.0.1:6379> slowlog get #默认获取最近10条慢日志
127.0.0.1:6379> slowlog get 5 #获取最近5条慢日志
127.0.0.1:6379> slowlog len #查看慢日志的条数
(integer) 20
127.0.0.1:6379> slowlog reset #清空慢日志
6.Slowlog各字段意思
127.0.0.1:6379> slowlog get
1) 1) (integer) 39 #慢日志的id，从0开始
2) (integer) 1713758193 #慢日志时间戳，慢日志产生的时间
3) (integer) 14426 #慢日志的运行时间
4) 1) "keys" #产生慢日志的命令
2) "*"
5) "127.0.0.1:46862"
6) ""
十一.redis的key的有效期
-1代表key永久生效，-2代表key被删除了
127.0.0.1:6379> set name1 test1
OK
127.0.0.1:6379> get name1
"test1"
127.0.0.1:6379> ttl name1 #key的生命周期
(integer) -1
127.0.0.1:6379> expire name1 20 #设置key的有效期为20s
(integer) 1
127.0.0.1:6379> ttl name1
(integer) 8
127.0.0.1:6379> ttl name1
(integer) -2
此时key被回收了
十二.redis禁用的危险命令
>flushall #会清空redis的所有数据
>flushdb #清空db中的所有数据
>keys * #在建过多的时候容易阻塞卡住
对禁用命令配置
vim /etc/redis.conf
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""
十三.redis压测工具
会对redis里的所有命令进行测试
redis-benchmark -a redispwd #默认的并发50个，一共10万个请求
十四.redis的两种持久化存储方式
14.1RDB持久化存储
RDB持久化存储
redis默认开启了RDB快照方式,提供持久化存储的功能
1.RDB存储方式的配置
127.0.0.1:6379> config get dir #查看存储路径的设置
1) "dir"
2) "/data/redis"
127.0.0.1:6379> config get dbfilename #查看RDB存储的文件名，默认为dump.rdb文件
1) "dbfilename"
2) "dump.rdb"
[root@bogon ~]# ls /data/redis/
dump.rdb redis.log redis.pid
127.0.0.1:6379> config get save
1) "save"
2) "3600 1 300 100 60 10000
3600:3600s 1:1个key的变化 意为每隔1小时会将变化的只存储到文件中
后面两组数类似概念:300 100 60 100000
2.验证RDB持久化存储
关闭RDB持久化存储
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
[root@bogon ~]# ls /data/redis/
dump.rdb redis.log redis.pid
[root@bogon ~]# systemctl stop redis
[root@bogon ~]# mv /data/redis/dump.rdb /data/redis/dump.rdb.bak
mv: overwrite '/data/redis/dump.rdb.bak'? y
[root@bogon ~]# ls /data/redis/
dump.rdb.bak redis.log
[root@bogon ~]# systemctl start redis
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> keys *
(empty array)
恢复数据
[root@bogon ~]# systemctl stop redis
[root@bogon ~]# mv /data/redis/dump.rdb.bak /data/redis/dump.rdb
mv: overwrite '/data/redis/dump.rdb'? y
[root@bogon ~]# systemctl start redis
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> keys *
1) "k3"
2) "k1"
3) "k2"
设置关闭RDB
[root@bogon ~]# vim /etc/redis.conf
save ""
#save 3600 1
#save 300 100
#save 60 10000
[root@bogon ~]# systemctl start redis
[root@bogon ~]# systemctl stop redis
[root@bogon ~]# rm -f /data/redis/dump.rdb
[root@bogon ~]# systemctl start redis
[root@bogon ~]# ls /data/redis/
redis.log redis.pid
验证关闭后重新登录数据存在吗
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> quit
[root@bogon ~]# systemctl restart redis
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> keys *
(empty array)
14.2redis的AOF持久化存储
默认关闭
AOF持久化存储是把命令直接写入文件中，文件会不断扩大
开启AOF持久化存储
127.0.0.1:6379> config get append* #查看AOF状态，默认关闭
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes #开启AOF存储
OK
127.0.0.1:6379> config rewrite #写入配置文件
OK
[root@bogon ~]# cat /etc/redis.conf | grep append #检查写入的AOF信息
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
[root@bogon ~]# ls /data/redis/appendonly.aof #查看AOF文件的路径
/data/redis/appendonly.aof
[root@bogon ~]# redis-cli -a redispwd #登录验证
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> quit
[root@bogon ~]# systemctl restart redis
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> keys *
1) "k2"
2) "k1"
AOF文件的重写
可以减小AOF文件的大小，数据不会减少
手动重写
[root@bogon ~]# ll /data/redis/appendonly.aof #查看AOF文件大小
-rw-r--r--. 1 root root 173 Apr 23 13:46 /data/redis/appendonly.aof
127.0.0.1:6379> bgrewriteaof #手动重写
Background append only file rewriting started
[root@bogon ~]# ll /data/redis/appendonly.aof #重写后，数据由173变为111
-rw-r--r--. 1 root root 111 Apr 23 13:55 /data/redis/appendonly.aof
自动重写
127.0.0.1:6379> config get *aof*
1) "aof-rewrite-incremental-fsync"
2) "yes"
3) "aof-load-truncated"
4) "yes"
5) "aof-use-rdb-preamble"
6) "yes"
7) "aof_rewrite_cpulist"
8) ""
9) "auto-aof-rewrite-percentage" #当增量达到100%时，会触发AOF重写
10) "100"
11) "auto-aof-rewrite-min-size" #当AOF文件达到67M时，会触发AOF重写
12) "67108864"
13) "replicaof"
14) ""
十五.redis的主从复制
redis单台服务器缺点：
1.容易数据丢失
2.缓解单台服务器的读写压力
主从复制概念:
保持主从服务器的数据一致性
主服务器可用来写入和读取，从服务器仅用来读取，通过读写分离，降低写服务器的压力
本实验基于主服务器安装启动的前提下进行
主服务器端的配置:
[root@bogon ~]# systemctl stop firewalld #关闭防火墙
[root@bogon ~]#setenforce 0 关闭selinux
[root@bogon ~]# vim /etc/redis.conf
bind 0.0.0.0
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
[root@bogon ~]# scp -r /usr/local/bin/redis-* root@192.168.145.150:/usr/local/bin/ #将主服务器redis的启动文件同步到从服务器
[root@bogon ~]# scp -r /etc/redis.conf root@192.168.145.150:/etc/ #将主服务器的主配置文件同步到从服务器
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> info #查看主从关系
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.145.150,port=6379,state=online,offset=686,lag=1
master_failover_state:no-failover
从服务器端的配置:
[root@bogon ~]# systemctl stop firewalld #关闭防火墙
[root@bogon ~]#setenforce 0 关闭selinux
[root@bogon ~]# redis-cli -v
redis-cli 6.2.1
[root@bogon ~]# vim /etc/redis.conf
bind 0.0.0.0
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
slaveof 192.168.145.149 6379 #添加主服务器的ip及端口
masterauth "redispwd" #添加主服务器的密码
[root@bogon ~]# mkdir -p /data/redis
[root@bogon ~]# redis-server /etc/redis.conf #启动从redis
[root@bogon redis]# redis-cli -a redispwd #登录从redis
127.0.0.1:6379> keys * #查看主redis的数据是否同步到从redis
1) "k1"
2) "k2"
127.0.0.1:6379> info #查看主从关系
# Replication
role:slave
master_host:192.168.145.149
master_port:6379
添加数据验证主从同步
主服务器端的配置:
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
从服务器端的配置:
127.0.0.1:6379> keys *
1) "k4"
2) "k1"
3) "k3"
4) "k2"
发现k3,k4成功同步过来了
十六.redis的哨兵模式
**注意:**本实验搭建时，需要考虑以前的实验环境，另外3个端配置时同步进行
作用:实现主从自动切换，实现redis的高可用
哨兵高可用模式搭建
为防止哨兵的单点故障，将哨兵高可用的形式，多个哨兵监控redis的状态，哨兵个数一般设置为奇数个
注意:一般哨兵的部署不要和redis在同一台，防止机器挂掉后，哨兵不起作用了
规划:
192.168.145.149 主redis 哨兵1
192.168.145.151 从1redis 哨兵2
192.168.145.152 从2redis 哨兵3
本实验基于以上的主从复制实验环境
192.168.145.149(主redis)配置:
vim /etc/redis.conf
masterauth "redispwd" #当主服务器宕机恢复时，会沦为从服务器的身份，向新的主服务器添加向主服务器同步数据时的验证密码
[root@bogon ~]# systemctl restart redis
哨兵配置:3个端均配置
[root@bogon ~]# vim /etc/sentinel.conf
bind 0.0.0.0
daemonize yes
port 26379
dir "/tmp"
logfile "sentinel.log"
sentinel monitor testmaster 192.168.145.149 6379 2
sentinel auth-pass testmaster redispwd
sentinel down-after-milliseconds testmaster 5000
sentinel failover-timeout testmaster 18000
启动哨兵:
[root@bogon ~]# /usr/local/bin/redis-sentinel /etc/sentinel.conf
[root@bogon ~]# ps -ef | grep senti
root 147598 1 0 05:49 ? 00:00:00 /usr/local/bin/redis-sentinel 0.0.0.0:26379 [sentinel]
root 147604 146592 0 05:49 pts/0 00:00:00 grep --color=auto senti
验证哨兵实现的redis高可用:
停止redis服务:
[root@bogon ~]# systemctl stop redis #停止主redis
恢复主数据库，查看其角色:
[root@bogon ~]# systemctl start redis
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> info #发现变成了151的从数据库
# Replication
role:slave
master_host:192.168.145.151
master_port:6379
验证哨兵的高可用性:
[root@bogon ~]# ps -ef | grep sen #停掉一个哨兵
root 2117 1 0 15:27 ? 00:00:06 /usr/local/bin/redis-sentinel 0.0.0.0:26379 [sentinel]
root 2289 1743 0 15:48 pts/0 00:00:00 grep --color=auto sen
[root@bogon ~]# kill -9 2117
192.168.145.151(从1redis)配置
[root@bogon ~]# redis-cli -a redispwd #登录redis查看目前的身份
127.0.0.1:6379> info
# Replication
role:slave
master_host:192.168.145.149
master_port:6379
master_link_status:up
哨兵配置:3个端均配置
[root@bogon ~]# vim /etc/sentinel.conf
bind 0.0.0.0
daemonize yes
port 26379
dir "/tmp"
logfile "sentinel.log"
sentinel monitor testmaster 192.168.145.149 6379 2
sentinel auth-pass testmaster redispwd
sentinel down-after-milliseconds testmaster 5000
sentinel failover-timeout testmaster 18000
启动哨兵:
[root@bogon ~]# /usr/local/bin/redis-sentinel /etc/sentinel.conf
[root@bogon ~]# ps -ef | grep senti
root 147598 1 0 05:49 ? 00:00:00 /usr/local/bin/redis-sentinel 0.0.0.0:26379 [sentinel]
root 147604 146592 0 05:49 pts/0 00:00:00 grep --color=auto senti
停掉主库后登录redis查看关系:
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> info #发现由从库关系升级为主库关系
# Replication
role:master
connected_slaves:1
恢复主数据库后，查看其角色:
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.145.149,port=6379,state=online,offset=102969,lag=1
slave1:ip=192.168.145.152,port=6379,state=online,offset=102969,lag=1
验证哨兵的高可用性:
[root@bogon ~]# ps -ef | grep redis #将redis服务关闭
root 2018 1 0 15:10 ? 00:00:10 redis-server 0.0.0.0:6379
root 2155 1 0 15:28 ? 00:00:11 /usr/local/bin/redis-sentinel 0.0.0.0:26379 [sentinel]
root 2320 1816 0 16:07 pts/0 00:00:00 grep --color=auto redis
[root@bogon ~]# kill -9 2018
192.168.145.152(从2redis)配置
[root@bogon ~]# redis-cli -a redispwd #登录redis查看目前的身份
127.0.0.1:6379> info
# Replication
role:slave
master_host:192.168.145.149
master_port:6379
master_link_status:up
哨兵配置:3个端均配置
[root@bogon ~]# vim /etc/sentinel.conf
bind 0.0.0.0
daemonize yes
port 26379
dir "/tmp"
logfile "sentinel.log"
sentinel monitor testmaster 192.168.145.149 6379 2
sentinel auth-pass testmaster redispwd
sentinel down-after-milliseconds testmaster 5000
sentinel failover-timeout testmaster 18000
启动哨兵:
[root@bogon ~]# /usr/local/bin/redis-sentinel /etc/sentinel.conf
[root@bogon ~]# ps -ef | grep senti
root 147598 1 0 05:49 ? 00:00:00 /usr/local/bin/redis-sentinel 0.0.0.0:26379 [sentinel]
root 147604 146592 0 05:49 pts/0 00:00:00 grep --color=auto senti
停掉主库后登录redis查看关系:
[root@bogon ~]# redis-cli -a redispwd
127.0.0.1:6379> info #发现152依然为从库
# Replication
role:slave
master_host:192.168.145.149
master_port:6379
恢复主数据库后，查看其角色:
# Replication
role:slave #发现152依然为从库
master_host:192.168.145.152
master_port:6379
master_link_status:up
验证哨兵的高可用性:
127.0.0.1:6379> info #发现从2起到的哨兵作用
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.145.142,port=6379,state=online,offset=431243,lag=1