redis进阶

B站狂神说

持久化

RDB redis database

redis会单独创建（fork）一个子进程，来进行持久化，会先将数据写入到一个临时文件中，等到持久化过程都结束了，再用这个临时文件去替换上次持久化话好的文件。整个过程中不需要进行IO操作，确保了极高的性能。

优点

• 适合大规模的数据恢复
• 对数据的完整性要求不高

缺点

• 需要一定的时间间隔进行操作，如果再未持久化前宕机，会丢失自上次持久化之后的数据
• fork进程会占用一定的内存空间

触发条件

• save 在redis中执行save命令
• flushAll 执行flushAll命令
• save规则满足的情况下，会自动触发
• 退出redis时，也会自动触发

数据恢复

持久化的数据会以dump.rdb文件存储，默认就是在redis的启动目录下 /usr/local/bin
如果向对数据进行回复，只需要将dump.rdb文件放到启动目录下即可 （在redis进程中，键入config get dir可以获得）
基本上可以自动恢复

AOF append only file

使用日志的形式，记录每一次的写操作，然后在重启的时候，按照AOF的记录，将操作全部再执行一遍。有三种模式# appendfsync always、appendfsync everysec、appendfsync no 一直持久化、每秒进行一次、以及从不持久化。默认关闭AOF。如果开启，就将appendonly no 改为yes。其文件以appendonly.aof保存在bin目录下。如果AOF和RDB同时开启，会优先加载AOF文件（因为数据更加完整）

AOF文件错误

AOF文件如果出现错误，是无法启动redis的，此时需要借助redis提供的工具，进行修复
redis-check-aof --fix appendonly.aof
修复之后可以启动，可能会丢失一部分数据（错误的）
或者直接删除aof文件也可以

优缺点

优点：

• 每一次修改都同步，数据的完整性更好
• 每秒同步一次，可能会丢失一秒的数据
• 从不同步，效率最高
  缺点：
• 相对于数据文件来说，aof远远大于RDB，修复的速度也更慢
• 效率比rdb低，使用的io，内存消耗也大，所以默认使用的是rdb

重写

AOF有默认的最大文件限制，如果开启重写，那么当文件到达最大之后，就会重新fork一个子进程，进行AOF文件进行重写

小结

仔细学习

发布订阅模型

SUBSCRIBE chanel 关注一个拼频道
UNSUBSCRIBE chanel 取关一个频道
publish chanel message 向某个频道中发布一条信息
PSUBSCRIBE pattern 订阅给定模式的所有频道
PUNSUBSCRIBE pattern 取关给定模式的所有频道
当关注一个频道之后，如果该频道有人发布消息，则会自动接收消息

应用

• 实时消息系统
• 实时聊天（频道当作聊天室，将消息回显给所有人即可）
• 订阅、关注系统

主从复制

指将一台redis服务器的数据，复制到其他的redis服务器，前者为主节点（master/leader），后者为从节点（slave/flower），数据的复制是单向的，只能由主节点复制到从节点。每台主机默认都是主节点

作用

1. 数据冗余：实现了数据的热备份，是持久化之外的一种数据冗余方式
2. 数据恢复：当主节点出现问题后，可以由从节点提供服务，实现快速的故障修复，实际上是一种服务的冗余
3. 负载均衡：在主从复制的基础上，配合读写分离，由主节点提供写服务，从节点提供读服务，分担服务器负载，尤其在写少读多的场景下，可以大大提高redis服务器的并发量
4. 高可用基石：主从复制是哨兵模式和集群能够实施的基础，所以是redis高可用的基础

单机伪集群的搭建

需要复制多个redis.conf文件，在多个连接下，分别打开

需要修改的配置文件有：

• 端口号 port
• pid文件名称 pidfile /var/run/redis_6380.pid
• log日志名称 logfile “6380.log”
• rdb文件名称 dbfilename dump6380.rdb

查看redis主从信息：连接客户端后 info replication

修改从机信息，选择其主机：slaveof ip port

这里使用的是命令行配置，只是暂时的。如果需要永久（开启即是从机），需要到配置文件中去配置，在主从配置那一块

# replicaof <masterip> <masterport> //配置所属主机的ip和端口号
# masterauth <master-password>	//如果主机有密码 验证主机密码

一旦配置成功，从机只能进行读操作，只有主机能够进行写操作

主从复制

在不开启哨兵模式的情况下，当主机宕机之后，从机会继续保持从机身份，当主机恢复之后，仍然是正常工作。当从机宕机之后，如果是命令行配置，就会又变为主机身份，需要重新配置（如果是文件配置就直接生效）。当从机重新连接时，会进行一次全量复制，之后进行增量复制。 所以我们是一定能从从机中看到主机中存储的数据的。
在从机连接主机之后，会向主机发送一个sync同步命令，master接到命令之后，会启动后台的存盘进程，收集所有的修改数据命令，等进程执行结束之后，主机将所有数据文件发送给从机，完成一次完全同步。
全量复制：在从机连接主机时，接收到主机的数据文件后，将其存盘加载
增量复制：之后主机后继续收集新的数据库修改命令，将其穿个slave，完成同步

主从复制的两种模式

• A为主机，B、C分别为两台A的从机
• A为主机，B为A的从机，C又为B的从机：此时B仍然是从机身份，一旦A宕机，B还是从机，而从机是无法写入的。但是C依旧可以拿到A中的数据

哨兵模式

手动修复

主机宕机之后，可以手动将一台从机设置为主机 slaveof no one ，之后再将其他从机的主机设置为新的主机，实现恢复。但是当之前的主机恢复之后，就无法继续担任主机，只能重新设置。

哨兵模式

• 首先配置哨兵模式启动的配置文件 bin/sentinel.conf ，其中配置 sentinel monitor 哨兵名称 监控的host 监控port 1（表示投票） 只需要监控主机即可，会自动发现从机
• 开启哨兵进程 在bin目录下，redis-sentinel 文件夹/sentinel.conf
• 主机宕机之后，会进行重新投票，选举一个从机作为主机，其他从机连接到此主机下。当之前主机恢复之后，也是作为从机，挂载到主机之下
  哨兵一般也会有集群，防止某个哨兵进程挂掉后，失去哨兵的作用，哨兵之间也会互相进行监视。如果有多个哨兵对redis集群进行监视时，哨兵会每隔一段时间对自己的监视对象发送请求，查看是否在线，如果不在线，会先主观的判断为下线，只有当其他哨兵都认为下线时，才会认为客观下线，然后进行故障转移，对从机进行重新选举

缓存穿透、击穿和雪崩

缓存穿透

在某段时间内大量访问缓存中没有，MYSQL中也没有的数据，造成空查询，对数据库造成很大的压力，容易崩溃

解决方案

• 布隆过滤器：他是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合就直接丢弃，从而避免了对底层存储系统的压力
• 缓存空对象：在持久层中如果没有命中，就在缓存中存储一个key，值为空，设置过期时间，之后再查询就会从缓存中进行查询，从而保护了后端数据源。但是，可能会造成存储的空key过多，浪费空间，也有可能会造成缓存和数据库的数据不一致

缓存击穿

对于热点key，会有大量的请求来查询。一般缓存会有一个过期时间，在缓存过期的一瞬间，有大量的查询穿过缓存，直接访问数据库。
解决方案

• 设置缓存永不过期：但是可能会造成缓存不一致，同时，当redis内存满之后，会自动清除缓存，重新写入
• 设置分布式锁：对后端数据库设置锁，在查询时，只有一个线程能够直接查询到数据库，而其他线程会根据回写结果在缓存中查询，从而保护后端数据库。但将高并发压力转移到了分布式锁上，对分布式锁的考验非常大

缓存雪崩

数据库中的缓存在某个时间点同时过期。如双抢购，上线之后所有商品过期时间可能一样，失效后大量请求直接查询数据库，造成宕机。或者说是断电，redis直接失效，也会出现雪崩。
解决方案

• 异地多活：多增设几台redis，保证redis不会同时宕机，保证redis的高可用性
• 限流降级：在缓存失效之后，通过加锁、或队列来对数据库访问的线程数进行控制，降低效率来保证服务器正常工作。或者在需要需要用到高并发的情况前，停掉一些其他服务，来保证服务器的性能
• 数据预热：在项目正式部署之前，先将可能的数据预先访问一遍，数据就会先缓存起来，在大并发访问前手动触发加载缓存不同的key，设置key过期时间，让过期时间尽量不同时发生，防止雪崩的发生