Redis的使用及原理总结（四）：Redis 配置文件详解、主从复制、集群、缓存击穿、缓存雪崩、哨兵模式、Redis持久化、订阅发布

最新推荐文章于 2025-10-22 14:33:37 发布
原创 最新推荐文章于 2025-10-22 14:33:37 发布 · 288 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
收录于
大数据

当前文章被收录于：

大数据
3 篇文章 0 人学习
订阅专栏 查看详情

前言： 上一篇文章主要介绍Redis中级（乐观锁、Redis事务操作、Jedis操作Redis、SpringBoot集成Redis等）的知识，本篇整理高级知识（配置文件详解、集群搭建、缓存击穿、缓存雪崩、哨兵模式、Redis持久化、订阅发布等），本篇整理后对于Redis 的知识我已经全部整理完成了。对于这几篇文章，我相信已经是将 Redis 整理得很完善了。小伙伴们可以收藏这几篇文章，将来碰到问题可以直接在这几篇文章中找到解答。

预备知识

Redis 配置文件详解

  1. 对于单位的配置
    在这里插入图片描述

  2. 导入其它配置文件，可以导入多个
    在这里插入图片描述

  3. so文件是Linux下的程序函数库,即编译好的可以供其他程序使用的代码和数据。Redis 也可以配置需要加载的 so 文件
    在这里插入图片描述

  4. NETWORK： 网络配置
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

  5. GENERAL ：通用配置
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

  6. SNAPSHOTTING： 快照配置，因为 Redis 是内存数据库。在内存中的数据我们知道都是断电即失的，所以我们需要有持久化的机制。
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

  7. REPLICATION：主从复制配置
    在这里插入图片描述

  8. SECURITY ：安全配置
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

  9. CLIENTS ：限制
    在这里插入图片描述

  10. MEMORY MANAGEMENT：
    在这里插入图片描述
    在这里插入图片描述

    maxmemory-policy 六种处理策略
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
2、allkeys-lru ： 删除lru算法的key   
3、volatile-random：随机删除即将过期key   
4、allkeys-random：随机删除   
5、volatile-ttl ： 删除即将过期的   
6、noeviction ： 永不过期，返回错误

  11. APPEND ONLY MODE ：aof 配置
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

Redis 订阅发布

  • Redis 发布订阅（pub/sub）是一种消息通信模式，让发布者（pub）发送消息，订阅者（sub） 接收消息。Redis 客户端可以订阅任意数量的频道。

  • Redis 发布订阅（pub/sub）的实现原理我们简单的了解一下，通过 SUBSCRIBE 命令订阅了某个频道之后，redis - server 里面维护了一个字典。字典中的键就是一个个频道。而字典中的值则是一个链表，链表中存着所有订阅了这个频道的客户端。SUBSCRIBE 命令的关键，就是将客户端添加到指定频道的链表中。通过 PUBLISH 命令向订阅者发布消息，redis - server 会使用给定的频道作为键，找到键对应的链表，然后遍历这个链表将消息发布给所有的订阅者。Pub/Sub 字面上理解就是发布和订阅，在 Redis 中，你可以设定对某一个 key 发布消息，所有订阅这个 key 的客户端都会收到消息。这一功能最明显的用法就是实时聊天系统。

  • Redis 订阅发布使用场景：1.实时消息系统；2.实时聊天；3.订阅、关注系统；对于相对复杂的场景，我们会使用消息中间件来做。

  • 关于 Redis 发布和订阅的命令：
    在这里插入图片描述

    ## 消息接收者
127.0.0.1:6379> PSUBSCRIBE pattern1
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"			
2) "pattern1"			## 频道
3) (integer) 1

1) "pmessage"			## 消息类型
2) "pattern1"			## 频道
3) "pattern1"
4) "testMessage"		## 消息内容

    ## 消息发送者
127.0.0.1:6379> PUBLISH pattern1 testMessage  ## 向 频道 pattern1 发送消息 testMessage
(integer) 1
127.0.0.1:6379>

Redis 持久化

Redis 持久化是由 RDB 与 AOF 两种模式实现的。Redis 默认使用的是 RDB 模式。
如果只用 Redis 做缓存的话，不需要去进行持久化操作。
如果同时开启了RDB 和 AOF 两种模式，当 Redis 重启的时候，那么在恢复数据的时候优先使用 AOF 文件来恢复原始数据，因为通常情况下，AOF 文件保存的数据要比 RDB 文件保存的数据更加完整。
RDB 更适合备份数据库（AOF 不断在变化不好备份），快速重启，并且不会有 AOF 可能潜在的 bug，所有生产环境中建议两种模式都使用。
关于性能的建议：
1.因为 RDB 文件只用作后备用途，建议只在从机上持久化 RDB 文件，而且 15 分钟备份一次就可以了，只保留 save 900 1 这条规则就可以了。
2.如果开启 AOF 的话，好处就是在最恶劣的情况下也不会丢失超过 2 秒的数据，启动脚本比较简单，只加载自己的 AOF 文件就可以了，代价有两个。一个是带来了持续的 IO 操作，另一个是 AOF 重写（rewrite）的最后将重写（rewrite）过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF 重写（rewrite） 的频率，AOF 重写基础大小默认值 64 M太小，可以将其设置到 5G 以上，默认超过原大小 100% 重写可以改到适当的数值。
3.如果不开启 AOF 的话，也可以通过 主从复制（Master-Slave Replication）来实现高可用。这样可以省下一大笔 IO，也减少了重写时带给系统的波动。代价就是如果 主机 与 从机同时宕机，会丢失十几分钟的数据，启动脚本也要比较主机 与 从机中的RDB 文件，载入比较新的哪一个。
我们来了解一下这两种模式！

  • RDB（Redis DataBase）：在指定时间间隔内将内存中的数据集通过快照的形式写入磁盘，恢复数据的时候是将快照文件直接读到内存中。Redis 会单独创建一个子进程来进行持久化的操作，会先将数据写到一个临时文件中，等持久化的过程都结束了，再用临时文件替换掉上次持久化好的文件。整个过程中间，主进程是没有执行任何 IO 操作的，保证了高性能。对于需要大规模数据的恢复，并且对数据恢复的完整性要求不是非常严格的话，那么 RDB 方式要比 AOF 方式更加的高效。在主从复制中，rdb 就是备用的，放在从机上面，不占主机的内存。
    优点：对于大规模数据的恢复更加高效。
    缺点：因为 save规则需要一定时间来触发，如果这段时间意外宕机那么最后一次修改的数据就会丢失。还有就是在创建子进程的时候，会占用一定的内存空间。
  1. 在配置文件中设置了持久化规则
    在这里插入图片描述
  2. 触发机制
    - 满足设置的 save 规则时，会自动触发 RDB 文件生成机制。
    - 执行 flushall 命令的时候，也会触发 RDB 文件生成机制。
    - 退出 Redis 的时候（shutdown），也会触发 RDB 文件生成机制。
  3. 生成 rdb 文件
    在这里插入图片描述
  4. 恢复 rdb 文件
    • 只需要将 rdb 文件放入 Redis 启动目录即可，Redis 在启动的时候会自动检查并恢复 dump.rdb 文件中的数据。
    • 也可以通过 config get dir 命令来查看需要将 rdb文件 存放的位置。
  • AOF（Append Only File）：将所有写操作、Redis执行过的所有指令通过日志的方式记录下来（读操作不记录），只能追加文件不允许改写文件，Redis 启动的时候会读取该文件重新构建数据。在这个模式下 Redis 构建文件就是将所有记录的指令与写操作重新执行一次来达到恢复数据的目的。简单来说，.aof 文件 与 .sql 文件类似。
    优点：如果配置为每次修改都同步，数据的完整性会更好。如果配置为每秒同步一次，可能会丢失最后一秒的数据。
    缺点：相对于数据文件来说，aof 文件的大小远远大于 rdb 文件的大小。aof 运行的效率也比 rdb 低。
  1. 配置 AOF
    - aof 默认时关闭的，需要将配置文件中的 appendonly no 修改为 appendonly yes
    - 没有其它需要的时候，其它的配置保持默认配置即可
    - 重启Redis之后就会生成 aof 文件了
  2. 修复 AOF 文件
    需要注意的是，如果 aof 文件被破坏。可以使用 redis-check-aof --fix 文件名来修复文件。需要注意的是，aof 文件的修复方式就是删除掉出错的数据！
  3. 重写机制
    因为 aof 默认是允许文件无限追加的，这样文件就会越来越大。
    配置文件中 auto-aof-rewrite-percentage 100与 auto-aof-rewrite-min-size 64mb 是配置重写规则的。
    如果aof 文件大于 64mb 的时候，就会触发重写机制，会创建一个子进程来将我们的文件进行重写。

Redis 集群

  • 搭建集群的原因：
    一般来说，要将 Redis 运用到工程项目中，只使用一台 Redis 是万万不能的，原因如下：
    1.从结构上来说，单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。
    2.从容量上来说，单个 Redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为256G，也不能将所有的内存用作 Redis 存储内存，一般来所，单台 Redis 最大使用内存不应该超过20G。
    因此集群的搭建是解决这些问题很好的办法，也是提高应用的高并发、高扩展、高可用的基础。在项目中使用 Redis 起码得有三台服务器，一主二从。原因在下面会体现出来。

Redis 主从复制

  • 主从复制是什么？
    主从复制，是指将一台 Redis 服务器的数据，复制到其它的 Redis 服务器。前者称为主节点（master/leader），后者称为从节点（slave/follower）。数据的复制是单向的，只能从主节点到从节点，主节点只做写的操作，而从节点只做读的操作。在默认的情况下，每台 Redis 服务器都是主节点。且一个主节点可以由多个从节点，也可以没有从节点。但是一个从节点只有一个主节点。

  • 主从复制的作用：
    1.数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
    2.故障恢复：当主节点出现问题的时候，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
    3.负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（也就是 Redis 写数据的时候应用连接主节点，读 Redis 数据的时候应用连接从节点），分担服务器负载；尤其是写少读多的情况下，通过多个从节点分担读负载，可以大大的提高 Redis 服务器的并发量。
    4.高可用基石：除了上述的作用之外，主从复制还是哨兵模式和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

  • 环境配置：
    对于环境配置，我们只需要配置从节点，因为默认情况下所有 Redis 服务器都是主节点。永久配置的话需要在配置文件中进行配置，如何配置在上面配置文件详解中介绍了。下面通过命令设置的，都是暂时的配置。只是为了方便演示。
    <对于学习的小伙伴，想要在一台服务器上允许多个 Redis 服务的话，需要修改配置文件中 4 个配置。第一是 端口号，第二是 pid 的名字，第三是 log文件的名字，最后是 dump.rdb 的名字。需要保证这几个服务的配置不相同才可以>
    我们可以通过 info replication 来查看当前节点的信息。
    在这里插入图片描述
    了解一下两种模式：
    在这里插入图片描述
    在这里插入图片描述
    上面这两种模式，都是可以实现主从复制的。

    配置从节点，在从节点通过 SLAVEOF 命令选择一台服务器当主节点。

    # 从节点
	127.0.0.1:6380> SLAVEOF 127.0.0.1 6379			# 选择一台机器为主节点
	OK
	127.0.0.1:6380> info replication				# 查看当前 Redis 服务的主从复制状态
	# Replication
	role:slave										# 当前角色是 从节点
	master_host:127.0.0.1
	master_port:6379
	master_link_status:up
	master_last_io_seconds_ago:2
	master_sync_in_progress:0
	slave_repl_offset:14
	slave_priority:100
	slave_read_only:1
	replica_announced:1
	connected_slaves:0
	master_failover_state:no-failover
	master_replid:f1e1f330d95b9d876b3d6a2aaf090a3a36412057
	master_replid2:0000000000000000000000000000000000000000
	master_repl_offset:14
	second_repl_offset:-1
	repl_backlog_active:1
	repl_backlog_size:1048576
	repl_backlog_first_byte_offset:1
	repl_backlog_histlen:14
	127.0.0.1:6380> 

     #主节点
127.0.0.1:6379> info replication					# 查看当前 Redis 服务的主从复制状态
# Replication
role:master											# 当前角色是 主节点
connected_slaves:1									# 该主节点下有一个从节点
slave0:ip=127.0.0.1,port=6380,state=online,offset=1778,lag=1		# 从节点的信息
master_failover_state:no-failover
master_replid:f1e1f330d95b9d876b3d6a2aaf090a3a36412057
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1778
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1778
127.0.0.1:6379>

    SLAVEOF no one 命令的使用，手动版的主从切换。

    # 当主节点断开连接的时候，我们可以使用 SLAVEOF no one 让自己变成主节点。其它的节点可以手动连接到最新的这个主节点。这个时候如
# 果主节点修复了，也只能再重新连接。

    整理一下配置好主从节点后需要注意的细节：
    - 主节点可以执行写操作，从节点只能进行读操作。
    - 如果主节点宕机了，从节点依旧是连接到主节点的。主节点宕机后，只是不能执行写操作了，对于从节点的读操作是没有影响的。如果这个时候主节点恢复正常了，从节点依旧是可以直接获取到主节点恢复之后写入的信息。
    - 如果不是在配置文件中进行的永久配置，重启之后就会变成主机。当然如果又把这个节点变成从节点，那么立马就会从主节点获取值。

  • 复制原理
    从节点（slave）启动后成功连接到 主节点（master）后会发送一个 sync 命令。主节点接收到命令后，启动后台的存盘进程，同时收集所有接收到用于修改数据集的命令，在后台进程执行完毕之后，主节点将传送整个数据文件到从节点，并完成一次完全同步。
    复制分为全量复制和增量复制。全量复制是指从节点在接收到数据库文件数据后，将其存盘并加载到内存中。而增量复制是指主节点继续将所有收集到的修改命令依次传给从节点，使其完成同步。
    只要从节点重新连接主节点的时候，一次完全同步也就是全量复制将会被自动执行。所以只要连接上主节点，我们肯定可以获得主节点上的所有数据。

Redis 哨兵模式

  • 概述
    哨兵模式是一种解决主从切换问题的方案。主从切换技术是指当主服务器宕机后，需要手动把一台从服务器切换为主服务器，需要进行人工干预，费事费力的同时还会导致一段时间的服务不可用。这不是一种好的解决方法，因此更多时候我们考虑使用哨兵模式。Redis 从 2.8 版本开始正式提供了 Sentinel （哨兵） 架构来解决这个问题。
    哨兵模式可以再后台监控主机是否故障，如果主机发生故障根据投票数自动将从库变成主库。哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行，其原理是 哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

  • 问题： 如果哨兵宕机了呢？
    通过这个问题，我们肯定意识到一个哨兵的模式是不够健壮的。因此推出了现在常用的 Redis 集群模式。除去监控各个 Redis 服务之外，哨兵之间还会互相监控。
    在这里插入图片描述
    假设主服务器宕机，哨兵1 先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称之为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间会进行一次投票，投票结果由一个哨兵发起，进行 failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换为主机的操作，这个过程称为客观下线。

  • 配置实现
    1.配置哨兵配置文件 sentinel.conf

    	# Example sentinel.conf
	# 哨兵sentinel实例运行的端口 默认26379
	port 26379
	# 哨兵sentinel的工作目录
	dir /tmp
	# 哨兵sentinel监控的redis主节点的 ip port
	# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
	# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
	# sentinel monitor <master-name> <ip> <redis-port> <quorum>
	sentinel monitor mymaster 127.0.0.1 6379 2
	# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
	# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
	# sentinel auth-pass <master-name> <password>
	sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
	# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
	# sentinel down-after-milliseconds <master-name> <milliseconds>
	sentinel down-after-milliseconds mymaster 30000
	# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成				failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
	# sentinel parallel-syncs <master-name> <numslaves>
	sentinel parallel-syncs mymaster 1
	# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
	#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
	#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
	#3.当想要取消一个正在进行的failover所需要的时间。 
	#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置		为指向master，但是就不按parallel-syncs所配置的规则来了
	# 默认三分钟
	# sentinel failover-timeout <master-name> <milliseconds>
	sentinel failover-timeout mymaster 180000
	# SCRIPTS EXECUTION
	#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
	#对于脚本的运行结果有以下规则：
	#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
	#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
	#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
	#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
	#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚		本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
	#通知脚本
	# shell编程
	# sentinel notification-script <master-name> <script-path>
	sentinel notification-script mymaster /var/redis/notify.sh

	# 客户端重新配置主节点参数脚本
	# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
	# 以下参数将会在调用脚本时传给脚本:
	# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
	# 目前<state>总是“failover”,
	# <role>是“leader”或者“observer”中的一个。
	# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
	# 这个脚本应该是通用的，能被多次调用，不是针对性的。
	# sentinel client-reconfig-script <master-name> <script-path>
	sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配置！

    2.启动哨兵 redis-sentinel kconfig/sentinel.conf

    [root@iZuf60pmf5vkz1ry012dc7Z bin]# redis-sentinel kconfig/sentinel.conf 
50103:X 22 Aug 2021 22:15:17.690 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
50103:X 22 Aug 2021 22:15:17.690 # Redis version=6.2.5, bits=64, commit=00000000, modified=0, pid=50103, just started
50103:X 22 Aug 2021 22:15:17.690 # Configuration loaded
50103:X 22 Aug 2021 22:15:17.691 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.5 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 50103
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

50103:X 22 Aug 2021 22:15:17.691 # Sentinel ID is 90a94e5026035a321f523084f6990ef4c180c308
50103:X 22 Aug 2021 22:15:17.691 # +monitor master myredis 127.0.0.1 6379 quorum 1

    3.哨兵模式总结
    如果 Master 节点断开了，这个时候会在从机上随机选择一个服务器。随机选择中包含了一个投票算法，有兴趣可以了解一下。如果Master 节点再投票完成后又回来了，只能归并到新的主机下当一个从机，这就是哨兵模式的规则。
    优点：
    1.哨兵集群，基于主从复制模式，所有的主从配置优点它都有。
    2.主从可以切换，故障可以转移，系统的可用性就会更好。
    3.哨兵模式就是主从模式的升级，手动到自动，更加健壮。
    缺点：
    1.Redis 不好进行在线扩容，集群容量一旦达到上线，在线扩容就会很麻烦。
    2.实现哨兵模式的配置其实是很麻烦的，其中有很多的选择。

Redis 缓存穿透和雪崩

  • Redis 缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面，但同时，也带来了一些问题。其中，最为重要的问题，就是数据一致性问题。从严格意义上来说，这个问题是没办法解决的。如果对数据的一致性要求很高，那么就不能使用缓存。另外还有一些经典的问题就是缓存穿透、缓存雪崩和缓存击穿，这些问题在业内也有一些比较流行的解决方案。
  • 缓存穿透
    缓存穿透概念很简单，用户想要查询一个数据，发现 Redis 内存数据库中没有，也就是缓存没有命中，于是向持久层数据库查询，发现也没有，于是这次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求访问持久层数据库，这样会给持久层数据库带来很大的压力，这时候就相当于出现了缓存穿透。
    解决方案
    布隆过滤器： 布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制器层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。
    缓存空对象： 当 存储层不命中后，即使返回空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，这样也就保护了后端数据源。但是这种方法会存在两种问题：1. 如果空值能够被缓存起来，这就意味着缓存需要更多的空间储存更多的键，因为这中间可能会有很多空值的键。2. 即使对空值设置了过期时间，还是会存在缓存层的数据会有一段时间与存储层的数据不一致，这对于需要保持一致性的业务会有影响。
  • 缓存击穿
    概念： 这里需要注意和缓存穿透的区别，缓存击穿是指一个 Key 非常热，在不停的扛着高并发，高并发集中对一个点进行访问，就如同子弹都打在了一个点上，当这个 Key 失效的瞬间，持续的高并发就穿过缓存直接请求到了持久层数据库，就像在一堵墙上敲出来了一个洞。这类数据一般都是热点数据，由于缓存过期，会同时访问数据库来查询最新的数据并且回写缓存，会导致持久层数据库瞬间压力过大。
    解决方案
    设置热点数据永不过期： 在缓存层面来看，没有设置过期时间就不会出现因为热点Key过期后产生的问题。
    加互斥锁： 使用分布式锁，保证每个 Key 同时只有一个线程去查询后端服务，其它线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。
  • 缓存雪崩
    概念： 缓存雪崩是指在某一时间段内，缓存集中过期失效，也有可能 Redis 服务器宕机或者断网了。产生雪崩的原因之一，比如在写本篇文章的时候，马上就要到双十一的零点抢购时刻，预计这批商品火爆期在凌晨一点就会退热，所以只缓存了一小时。到凌晨一点的时候，这批商品的缓存过期了，而对这批商品的访问查询自然就落在了持久层数据库上，对于持久层数据库而言就会产生周期性的压力波峰。当用户量突然暴增的时候，就有可能出现持久层数据库挂掉的情况。
    解决方案
    Redis 高可用： 这个思想的含义就是，既然 redis 有可能挂掉，那我多增设几台 Redis。这样就算一台宕机了其它的还可以继续工作，其实就是搭建集群。最有效的就是异地多活。
    限流降级： 这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个Key只允许一个线程查询数据和写缓存，其它线程等待。
    数据预热： 数据预热的含义就是在正式部署之前，先把可能的热点数据预先访问一遍，这样部分热点数据就会加载到缓存中。在即将发生大并发前手动触发加载缓存不同的Key，设置不同的过期时间，可以让缓存过期的时间尽量的均匀一些。

后续

以上总结的第四篇，主要是 redis 高级知识的总结，可以深度的了解 Redis。如有错误之处，欢迎大家指正！更多技术分享，请关注公众号：XC_Message。

标签
#redis #nosql
redis配置文件
11-27
redis缓存数据库，引入属性文件，开启事务，可以通过transcational注解控制，
分布式缓存Redis之配置文件redis.conf详解
ZhangRui的博客
12-07 2310
写在前面  本学习教程所有示例代码见GitHub：https://github.com/selfconzrr/Redis_Learning  使用配置文件启动服务器：src/redis-server redis.conf  主要配置项：Redis支持很多的参数，但都有默认值。*********************** General######################daemonize:
redis（基础 && redis缓存）
m0_64863860的博客
11-11 594
一，redis（基础一，redis（基础目录。
Redis常见配置说明
weixin_44651555的博客
10-16 382
参数说明 redis.conf 配置项说明如下： Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程 daemonize no 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定 pidfile /var/run/redis.pid 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对
Redis 配置文件详解redis.conf 从入门到实战
hello.reader
06-17 1762
Redis 是一款高性能的内存数据库，通常以配置文件的形式进行部署与调优。虽然 Redis 在启动时可不依赖配置文件，但为了实现稳定、安全、高效的生产环境部署，推荐使用官方提供的 `redis.conf` 或 `redis-full.conf`。
redis配置文件详解
qq_44749491的博客
11-29 1万+
一文解析redis配置文件
Redis-redis发布订阅、主从复制、哨兵模式、缓存穿透与雪崩学习理解
小孔靠得住的博客
01-18 1492
redis发布订阅、主从复制、哨兵模式、缓存穿透与雪崩学习理解
linux学习笔记（51）Redis发布订阅 主从复制 缓存 雪崩
最新发布
似流水般平静而坚定。
10-22 1389
Redis主从复制与哨兵模式解析 摘要：Redis主从复制实现数据冗余和故障恢复，主节点负责写操作，从节点负责读操作，支持全量和增量同步。哨兵模式自动监控主节点状态并在故障时切换从节点为主节点，提升系统可用性。Redis缓存存在穿透、击穿和雪崩问题，需针对性解决。事务操作通过WATCH+MULTI+EXEC实现，但不支持回滚，复杂场景推荐使用Lua脚本保证原子性。实际应用中，简单操作可使用事务，复杂逻辑应选用Lua脚本，配合WATCH实现乐观锁控制。
Redis完全指南：从基础功能到缓存管理与高可用性设计
tatasix的博客
11-06 1738
本文详细介绍了Redis的核心功能、应用场景和优化策略。从五大数据类型及其底层结构，到特殊数据类型的使用方法，再到RDB与AOF持久化方式，文章逐一解析了每个Redis特性。同时，对主从复制、哨兵模式和集群配置提供了详尽说明，帮助构建高可用架构。针对缓存管理中的缓存击穿、缓存雪崩等问题，文章列举了多种应对措施，如热点数据预热、分布式锁和限流等。通过掌握这些知识，读者能够灵活运用Redis在高并发场景下实现高效、稳定的数据存储和缓存管理。
Redis学习其三（订阅发布，主从复制，哨兵模式）
2303_80236475的博客
07-18 708
它可以自动监控 Redis 主节点和从节点的运行状态，当主节点出现故障时，自动将一个从节点晋升为主节点，其他从节点指向新的主节点进行数据复制，从而保证系统的高可用性。相较于缓存穿透，缓存击穿的目的性更强，一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。当从机断电宕机后，若不是使用配置文件配置的从机，再次启动后作为主机是无法获取之前主机的数据的，若此时重新配置称为从机，又可以获取到主机的所有数据。因为是单机多服务，一主（79）二从（80，81）。
redis面试题总结--redis作用和支持场景、数据类型、持久化方案、高可用（主从复制、哨兵、Redis Cluster）、事务机制、乐观锁悲观锁、数据删除淘汰策略、发布订阅、雪崩穿透击穿
yang_xiao_wu_的博客
07-04 1311
Redis现在支持十种数据类型：string（字符串），hash（哈希），list（列表），set（集合），zset（有序集合），stream（流），geospatial（地理），bitmap（位图），bitfield（位域），hyperloglog（基数统计）使用分布式锁，当发现缓存失效的时候，不是立即从数据库加载数据。指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。
Redis学习笔记(六)——发布订阅、主从复制及缓存击穿、穿透、雪崩
虚心学习，和气编码
03-14 1210
这篇应该是现阶段Redis学习的最终篇了，整个Redis的学习经过了两周半，基本命令也全撸了一遍，但是觉得掌握的还是不好，具体体现为对Redis的概念，含义，使用处于一个不太熟练的状态，很可惜工作的项目也没有过多的使用Redis，所以我尽量在笔记中记录的详细一些，这一篇呢，要进行最后的收尾了，学习一下发布订阅与一些老生常谈的面试问题。
Redis发布订阅Redis主从复制，缓存雪崩
yang13676084606的博客
11-21 439
RedisRedis发布订阅Redis主从复制概念环境配置一主二从哨兵模式Redis缓存穿透和雪崩缓存穿透缓存击穿（量太大，缓存过期！）缓存雪崩 Redis发布订阅 参考：b站博主遇见狂神说写的笔记。博主连接: link. Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。微信、 微博、关注系统！ Redis 客户端可以订阅任意数量的频道。 订阅/发布消息图： 第一个：消息发送者， 第二个：频道 第三个：消息订阅者！ 命令 测试 订阅段
Redis数据库（六）：主从复制和缓存穿透及雪崩
weixin_47040031的博客
06-26 1244
数据预热的含义就是在正式部署之前，先把可能的数据先预先访问一遍，这样部分可能大量访问的数 据就会加载到缓存中，在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间， 让缓存失效的时间点尽量均匀。缓存穿透的就是用户想要查询一个数据，发现Redis中没有，也就是缓存没有命中，于是向持久层数据库发起查询，发现也没有这个数据，于是本次查询失败。平时在redis数据库中设置的数据，关闭系统了，还能看见就是进行了持久化，把内存中的数据存到磁盘上，等重新启动数据库，再从磁盘中把数据拷到内存中。
redis--主从复制，哨兵模式，缓存穿透，缓存雪崩
weixin_44387195的博客
11-03 592
redis--主从复制，哨兵模式，缓存穿透，缓存雪崩一、主从复制1.为什么会有主从复制2.主从复制的作用3.复制原理二、哨兵模式1.概述：2.单哨兵模式3.多哨兵模式4.优缺点5.哨兵模式的全部配置三、缓存穿透1.什么是缓存穿透2.解决方案四、缓存击穿1.概述2.解决方案五、缓存雪崩1.概述2解决方案 一、主从复制 1.为什么会有主从复制 通过持久化功能，redis保证了即使在服务器重启的情况下数据也不会丢失，但是如果由于数据存储在一台服务器上的，如果这台服务器出现故障，比如硬盘坏了，也会导致数据的丢失。
Redis（五）—— 配置文件、持久化、Redis集群、穿透/击穿/雪崩
qq_44886213的博客
07-28 962
redis进阶： 1）详细介绍redis-server配置文件 2）两种持久化方式RDB，AOF 3）redis实现消息中间件——发布与订阅 4）主从复制 5）哨兵策略 6）雪崩
Redis（三）：Redis配置、持久化、发布订阅、主从配置、缓存穿透和雪崩
Clawww的学习笔记
05-22 550
Redis 配置 Redis 的配置文件位于 Redis 安装目录下，文件名为 redis.conf(Windows 名为 redis.windows.conf。 配置文件 unit单位 对大小写不敏感 # Redis configuration file example # 当需要需要内存大小的时候 可以指定内存大小 # Note on units: when memory size is needed, it is possible to specify # 它通常的形式是1k 5GB 4M等等
基于《狂神说Java》Redis--学习笔记
wudidahuanggua的博客
06-19 2133
本笔记仅做学习与复习使用，不存在刻意抄袭。给各位学友强烈推荐《遇见狂神说》他的整套Java学习路线使我获益匪浅！！!
Redis完整笔记——上到主从复制配置分析，下到基本数据类型
5akura's Blog
05-13 5291
文章目录Redis一、Nosql为什么使用Nosql什么是NosqlNosql特点NoSQL的四大分类KV键值对文档型数据库（bson格式）列存储数据库图关系数据库二、Redis入门Redis是什么？Redis能干什么？环境搭建window搭建Linux搭建性能测试工具—redis-benchmark基础知识三、五大数据类型Redis-keyString(字符串)List(列表)Set(集合)HashZset(有序集合)四、三种特殊数据类型Geospatial(地理位置)Hyperloglog(基数统计)B
我把面试问烂了的⭐Redis面试题⭐总结了一下（带答案，万字总结，精心打磨，建议收藏）
热门推荐
java程序鱼的博客
08-11 2万+
我把面试问烂了的⭐Redis⭐面试题总结了一下（带答案，万字总结，精心打磨，建议收藏）
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值