Redis配置、持久化、发布订阅、集群、缓存穿透和雪崩

本篇文章是看B站狂神Redis教程做的笔记，我没有视频中所有讲解的都是实验，且狂神是在虚拟机中完成的教学，我用的环境是Windows，所以笔记有部分缺陷和不同。
想要想教程详情戳这里→https://www.bilibili.com/video/BV1S54y1R7SB?p=1

Redis.conf详解

Redis的启动就是通过配置文件来启动，即Redis启动前就会加载Redis.conf配置文件，下面来具体解读redis.windows.conf

单位（unit单位对大小写不敏感）

包含（类似于学习Spring时，可以使用import包含其他的配置文件）

网络（只列举了常用的）

IP:默认为127.0.0.1

是否受保护：

端口号：

通用配置

daemonize yes  #以守护进程的方式运行，默认为no，需手动开启为yes
pidfile /var/run/redis.pid  #如果守护进程的方式开启为yes，说明以后台的方式运行，我们就需要指定一个pid文件

日志：

databases 16  #默认数据库数量，默认是16个
always-show-logo yes  #是否显示logo，默认是开启的

快照（在持久化中会用到）

持久化：在规定的时间内执行多少次操作，会持久化到文件 .rdb .aof

redis是内存数据库，如果没有持久化，那么数据断电即失！

save 900 1  #900s至少有一个key进行修改，就进行持久化操作
save 300 10  #300s至少有10个key进行修改，就进行持久化操作
save 60 10000  #60s至少有10000个key进行修改，就进行持久化操作
#也可以设置根据需求自己设置持久化参数

stop-writes-on-bgsave-error yes  #持久化出错了还要不要继续工作，默认开启
rdbcompression yes  #是否压缩rdb文件，默认开启，需要消耗CPU资源
rdbchecksum yes  #保存rdb文件时，是否检查校验
dbfilename dump.rdb  #rdb文件名称
dir ./  #rdb文件保存目录

REPLICATION 复制，在讲解主从复制时讲解

安全

redis默认是没有密码的

127.0.0.1:6379> config get requirepass  #获取redis的密码
1) "requirepass"
2) ""

可以通过命令设置密码

127.0.0.1:6379> config set requirepass 123456  #将密码设置为123546
OK

在设置了密码后，需先登录验证才能进入

127.0.0.1:6379> config get requirepass  #没有权限
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123456  #验证成功
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"

限制（CLIENTS）

maxclients 10000  #设置能连接上redis的最大客户端的数量
maxmemory <bytes> #redis配置最大的内存容量
maxmemory-policy noeviction  #内存到达上限的处理策略
	1、volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
	2、allkeys-lru ： 删除lru算法的key   
	3、volatile-random：随机删除即将过期key   
	4、allkeys-random：随机删除   
	5、volatile-ttl ： 删除即将过期的   
	6、noeviction ： 永不过期，返回错误

APPEND ONLY模式 aof配置

appendonly no #默认不开启aof模式，因为默认是使用rdb持久化的，在大部分情况下rdb基本够用了
appendfilename "appendonly.aof"  #aof持久化文件的名字

# appendfsync always  #每次修改都会写入（同步），比较消耗性能
appendfsync everysec  #默认值，每秒执行一次同步，可能会丢失一秒的数据
# appendfsync no  #不执行同步，操作系统自己同步数据，速度最快

#以下配置在持久化中讲解
no-appendfsync-on-rewrite no  #
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes 

RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话将的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作。这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！

rdb保存的文件是dump.rdb

修改配置文件中，rdb的触发机制

rdb的触发机制包括三种：①save的规则满足的请款下，会自动触发rdb规则；

②执行flushAll命令，会触发rdb规则；③退出redis，也会产生rdb文件

备份就会自动生成dump.rdb

如何恢复rdb文件

只需要将dupm.rdb文件放在redis启动目录下

优点：①适合大规模的数据恢复；②对数据的完整性要求不高

缺点：①需要一定的时间间隔进行操作，如果redis意外宕机，最后一次修改数据就没有了；②fork进程的时候，会占用一定的内存空间

AOF（Append Only File）

追加文件，将所有命令都记录下来，在恢复时将所有的命令再执行一遍

以日志的形式来记录每一个写操作，将Redis执行过的所有命令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

aof保存的是appendonly.aof文件

配置

aof默认是不开启的，我们需要手动进行配置

注意：当修改了配置文件并重启redis服务器后，appendonly.aof文件仍未生成时，需要在客户端使用命令”config set appendonly yes“来开启，也可以使用命令” config set save “” “来关闭rdb，当然可以同时开启aof和rdb。

当aof配置文件有错误，这时redis是无法启动的，我们需要修复这个配置文件

aof的重写规则说明：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

当文件大于64M，太大了，会重新fork一个新的进程将文件进行重写

优点：①三种同步策略，a.每一次修改都同步，文件的完整性更好;b.每秒同步，可能会丢失一秒数据；c.从不同步，效率最高

缺点：①相对于数据文件来说，aof远大于rdb，内存占用较大；②修复的速度比rdb慢；③因为aof是IO读写操作，所以aof为运行效率比rdb慢，所有redis默认的配置就是rdb持久化。

Redis发布订阅

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。

Redis客户端可以订阅人员数量的频道

订阅/发布消息图

一共三个角色：①消息发送者；②频道；③消息订阅者

下图展示了频道1channel1，以及订阅这个频道的三个客户端——client2，client5和client1之间的关系：

当有新消息通过publish命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端：

命令

这些命令被广泛用于构建即时通信应用，比如网络聊天室（chatroom）和实施广播，实时提醒等。

实验

订阅消息（此时发布者未发布消息）

127.0.0.1:6379> SUBSCRIBE maize  #订阅频道maize
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "maize"
3) (integer) 1
  #此处一直光标闪烁，监听发布者发布的消息

发布消息 （发布者发布了一条消息）

127.0.0.1:6379> publish maize helloworld  #maize为消息，helloworld为发布的消息内容
(integer) 1

订阅

127.0.0.1:6379> SUBSCRIBE maize
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "maize"
3) (integer) 1
1) "message"  #订阅者接收到了消息
2) "maize"  #频道
3) "helloworld"  #发布的消息内容
  #此处光标仍然闪烁，等待下一次发布者发布消息

Redis主从复制

主从复制的作用主要包括：

1、数据冗余：主从复制实现了数据的热内分，时持久化之外的一种数据冗余方式；

2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余；

3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时连接主节点，读Redis数据时应用连接从节点），分担服务器负载路由器是在写少读多的场景下，通过多个从节点分担读负载，可以大量提高Redis服务器的并发量；

4、高可用基石：除了上述作用以外，主从复制还是哨兵和集群都能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis应用于工程项目中，只使用一台Redis是万万不能的，原因如下：

1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理多有的请求负载，压力较大；

2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存。一般来说，单台Redis最大使用内存不应该超过20G

环境配置

只配置从库，不配置主库（因为Redis服务默认就是一个主库）

127.0.0.1:6379> info replication  #查看当前库的信息
# Replication
role:master  #角色：从机
connected_slaves:0  #从机的个数（此处0表示没有从机）
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0  

单机多服务集群搭建步骤：

复制三个配置文件，修改对应的信息：①端口；②pid名字；③log文件名字；④rdb名字

windows下搭建步骤可见：https://blog.csdn.net/weixin_45617512/article/details/108284355

命令

SLAVEOF host port  #将那台主机上的哪台端口号作为自己的主机
imfo replication  #查看集群信息

查看主从关系

#主机
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1  #有一台从机
slave0:ip=127.0.0.1,port=6383,state=online,offset=2214,lag=1  #从机端口号为6383
master_repl_offset:2214
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:2213

#从机
127.0.0.1:6383> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380  #主机为6380
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:2424
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

永久的主从关系是通过配置文件配置，使用命令配置的只是暂时的

细节

主机可以写，从机不能写，主机中所有的信息和数据，都会自动被从机保存！

当主机断开连接时，从机依旧连接到主机（不会自动断开，也不会自动成为主机），但是没有写操作，如果主机又重新获得连接，从机依旧可以直接获取到主机写入的信息

当从机断开连接时，使用命令配置的主从关系也就断开，从机只保存直到断开瞬间的主机写入的信息，再次获得连接时，已经没有直接成为从机，而是像新启动的节点一样是一个主机。再将其配置为主机的从机时，也可以拿到主机所写入的信息。

当主节点断开，可以使用SLAVEOF no one使自己成为主节点，如果原始主节点重新获得连接，需重新配置主从关系。

复制原理

Slave启动成功连接到Master后会发送一个sync同步命令

Master接到命令，启动后台的存盘进程，同时手机所有接收到的用于修改数据集命令，在后台进程执行完毕后，master将传送整个数据文件slave，并完成一个完全同步

全量复制：而slave服务在接收到数据文件数据后，将其存盘并加载到内存中

增量复制：Master继续将新的所有收集到的修改命令一次传给slave，完成同步

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务器不可用。这不是一种推荐的方式，更多时候，我们更优先考虑哨兵模式。Redis从2.8开始正是提供了Sentinel（哨兵）架构来解决这个问题。

哨兵模式能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

哨兵模式是一种特殊的模式，首先Redis提供了哨兵命令，哨兵是一个独立的进程，作为进程它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

优点：①哨兵集群，基于主从复制模式，所有的主从配置优点，它全有；②主从可以切换，故障可以转移，系统的可用性就会更好；③哨兵模式就是主从模式的升级，手动到自动，更加健壮

缺点：①Redis不好在线扩容，集群容量一旦到达上限，在线扩容十分麻烦；②实现哨兵模式的配置比较麻烦。

Redis缓存穿透和雪崩（面试高频）

缓存穿透（查询不到）

概念

缓存穿透的概念很简单，用户想要查询一个数据，发现Redis缓存数据中没有，也就是缓存没有命中，于是向持久层数据库查询，仍然没有，于是本次查询失败。当用户很多的时候，缓存没有命中（秒杀中可能出现这种情况），于是都去请求了持久层数据库，这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方案

布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数已hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

缓存空对象

当存储层不命中后，即使返回空对象也将其存储起来，同时会设置一个过期时间，之后再访问这个数据库，将会从缓存中获取，保护了后端数据源。

缺点

1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多空值的键。

2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据有一段时间窗口的不一致，这对于一些需要保持一致性的业务是有很大的影响的。

缓存击穿（查询量太大，缓存过期）

概述

这里需要注意和缓存穿透的区别，缓存击穿是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在时效的瞬间，持续的大并发就穿破缓存，直接请求数据库。

当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询数据，并写回缓存，会导致数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题

加互斥锁

分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

概念

缓存雪崩是指在某一时间段，缓存集中过期时效，Redis宕机！

产生雪崩的原因之一：在写文本时，马上就要到双十二零点，很快迎来一波抢购，这组商品时间比较几种的放入缓存中，假设缓存一小时，那么到凌晨一点时，这批上皮内的缓存就会过期了，而对这批商品的访问查询都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求就会达到存储层，存储层的调用量就会暴增，造成存储层也挂掉的情况。

解决方案

Redis高可用

这个思想的含义是，既然redis有可能挂掉，那么多增加几台redis，这样一台挂掉之后其他的还可以继续工作，就是搭建redis集群的思想（异地多活）

限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对于某个key只允许一个线程查询数据和写缓存，其他的线程等待。

或者停掉一些服务，比如双十一先停掉了退款服务。

数据预热

缓存雪崩是指在某一时间段，缓存集中过期时效，Redis宕机！

产生雪崩的原因之一：在写文本时，马上就要到双十二零点，很快迎来一波抢购，这组商品时间比较几种的放入缓存中，假设缓存一小时，那么到凌晨一点时，这批上皮内的缓存就会过期了，而对这批商品的访问查询都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求就会达到存储层，存储层的调用量就会暴增，造成存储层也挂掉的情况。

解决方案

Redis高可用

这个思想的含义是，既然redis有可能挂掉，那么多增加几台redis，这样一台挂掉之后其他的还可以继续工作，就是搭建redis集群的思想（异地多活）

限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对于某个key只允许一个线程查询数据和写缓存，其他的线程等待。

或者停掉一些服务，比如双十一先停掉了退款服务。

数据预热

数据预热的含义就是在正是部署之前，我先把可能的数据预先访问一遍，这样部分可能大量访问的数据就加载到缓存中，在即将发生大并发访问之前，手动触发加载缓存不同的key，设置不同的过期时间你，让缓存时效的时间点尽量均匀。

欢迎指正哦~😊