redis进阶

---

redis配置文件（redis.conf)

1.配置文件对单位大小写不敏感
2.配置文件可include包含其他文件
3.通用配置

bind 127.0.0.1     #绑定ip

port 6379      #端口设置

daemonize     yes       #以守护进程方式运行，默认是no，需要手动改为yes。

loglevel notice   #日志配置
logfile ""   #生成的文件名

4.快照

#3600s内，如果至少1个key进行修改，将持久化
save 3600 1
save 300 100
save 60 10000

#持久化出错是否继续工作
stop-writes-on-bgsave-error yes

#是否压缩rdb文件
rdbcompression yes

#保存rdb文件时进行错误的校验
rdbchecksum yes

dir ./  #rdb文件保存的目录

5.security
可设置redis密码，默认无

6.aof配置

appendonly no   #默认不开启aof模式，默认使用rdb方式持久化

appendfilename "appendonly.aof"  #持久化文件的名字

#appendfsync always     #每次修改都会sync
appendfsync everysec      #每秒执行一次sync,可能丢失这1s的数据
#appendfsync  no   #不执行sync,此时操作系统自己同步，速度最快

redis持久化

redis是内存数据库，服务器进程一旦退出，服务器中的数据库状态也会消失，所以需要持久化

RDB(Redis DataBade)

rdb保存的文件是dump.rdb

触发机制
1.sava规则满足的情况下，会自动触发rdb机制
2.执行flushall命令，也会触发rdb规则
3.退出redis，也会产生rdb文件

优点：
1.适合大规模的数据恢复
2.对数据的完整性要求不高
缺点：
1.需要一定的时间间隔进程操作，如果redis宕机，最后一次修改的数据不会保存
2.fork进程会占用一定内存空间

AOF（Append Only File)

将所有命令都记录下来，恢复的时候把文件全部执行一遍
以日志的形式记录每个写操作，将redis执行的所有指令记录下来，只追加文件但不可修改文件，redis启动之初会读取文件重新构建，redis重启会根据日志文件内容将写指令从前到后执行一次以完成数据的恢复工作。
Aof保存的是appendonly.aof文件。
默认不开启，需要手动配置，将appendonly改为yes即可，重启后生效
如果aof文件有错位，redis是启动不了的，需要修复这个aof文件，redis提供了一个工具redsi-check-aof --fix 文件（appendonly.aof)

特点
redis.conf文件里面

#appendfsync always   #每次修改都会sybc，消耗性能
appendfsnc everysec  #每秒执行一次sync，可能丢失这一秒的数据
#appendfsync no   #不执行sync,这个时候操作系统自己同步数据，速度最快。

1.相对于数据文件来说，aof远远大于rdb,修复的速度也比rdb慢
2.aof运行效率比rdb慢，所以redis默认配置就是rdb持久化

拓展

订阅发布

redis订阅是一种消息通信模式：发送者发送消息，订阅者接收消息

订阅

发布

原理

主从复制

概念：

主从复制，是指将一台redis服务器的数据，复制到其他redis服务器，前者称为主节点，后者称为从节点；数据的复制是单向的，只能从主节点到从节点。master以写为主，slave以读为主。默认情况下，每台redis服务器都是主节点，且一个主节点可以有多个从节点，但一个从节点只能有一个主节点

环境配置

[root@xia bin]# redis-server kconfig/redis.conf
[root@xia bin]# redis-cli -p 6379
127.0.0.1:6379> clear
127.0.0.1:6379> info replication  #查看当前库信息
# Replication
role:master    #角色
connected_slaves:0    #没有从机
master_failover_state:no-failover
master_replid:0677ca8eb50526bc730c3446c5ac6b89997c8f6f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

拷贝从的配置文件

cp redis.conf redis80.conf

port 6380

pidfile /var/run/redis_6380.pid

logfile "6380.log"

dbfilename dump6380.rdb

一主二从

默认情况下，每台redis服务器都是主节点，故只配置从机即可。
认主机

slaveof 127.0.0.1 6379

这样命令行配置只是暂时的主从机，要想永久，需要在配置文件中配置。
主机可以写，从机只能读，主机中所有信息和数据，都会自动被从机保存。
主机断开，从机依旧连接到主机，如果主机回来，从机依旧可以获取主机写操作

两种模式

第二种模式如果主节点断了，slaveof no one（手动）,使自己成为主节点。

哨兵模式（自动选举老大）

主从切换技术的方法是：当主服务器宕机后，需要手动将一台服务器切换为从服务器，还要人工干预，费时费力，还会造成一段时间服务不可用。故基本采用哨兵模式。

哨兵模式：

哨兵模式的配置

在redis.conf的同级目录下创建sentinel.conf
,后在其里面写入（基础配置）

sentinel monitor myredis 127.0.0.1 6379 1

最后的一，代表主机挂了，slave投票看谁接替成为主机，票数最多的，成为主机

启动哨兵

redis-sentinel xconfig/sentinel.conf

如果master节点断了，会随机选择一个服务器
如果主机回来，只能归并到新的主机下，当从机。

Redis缓存穿透和雪崩（面试高频,工作常用)

1.雪崩
当某一个时刻出现大规模的缓存失效的情况，那么就会导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。
造成雪崩的原因有两个：第一种可能是Redis宕机，第二种可能是采用了相同的过期时间。
解决方法：
2.缓存击穿
缓存雪崩是大规模的key失效，而缓存击穿是一个热点的Key，有大并发集中对其进行访问，突然间这个Key失效了，导致大并发全部打在数据库上，导致数据库压力剧增。这种现象就叫做缓存击穿。
解决方法：1.设置热点数据永不过期 2.设置分布式锁，保证对于每个key同时只有一个线程去查询后端服务。
3.缓存穿透
我们使用Redis大部分情况都是通过Key查询对应的值，假如发送的请求传进来的key是不存在Redis中的，那么就查不到缓存，查不到缓存就会去数据库查询。假如有大量这样的请求，这些请求像“穿透”了缓存一样直接打在数据库上，这种现象就叫做缓存穿透。
解决方法：1.设置布隆过滤器 2.缓存空对象