一、Redis 持久化机制深度剖析
在 Redis 的应用中，持久化是一项关键特性，它确保了即使在服务器崩溃、重启或其他意外情况下，数据也能得以保存和恢复。Redis 提供了多种持久化方式，每种方式都有其独特的优势和适用场景，理解并合理运用这些持久化机制，对于构建可靠的 Redis 应用至关重要。
（一）RDB 持久化
RDB（Redis Database）持久化是 Redis 默认的持久化方式，它将 Redis 在某一时刻的内存数据以快照的形式保存到磁盘上，生成一个二进制的.rdb 文件 。
触发条件：
手动触发：可以通过执行 SAVE 或 BGSAVE 命令来手动触发 RDB 持久化。SAVE 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕，期间服务器无法处理任何命令请求；而 BGSAVE 命令则会在后台创建一个子进程来进行 RDB 文件的生成，主进程可以继续处理客户端请求，这是生产环境中常用的手动触发方式。
自动触发：通过在 redis.conf 配置文件中设置 save 参数来自动触发。例如，“save 900 1” 表示在 900 秒内如果至少有 1 次写操作，就会触发 BGSAVE 命令进行 RDB 快照；“save 300 10” 表示 300 秒内至少有 10 次写操作时触发；“save 60 10000” 则表示 60 秒内至少有 10000 次写操作时触发 。
优点：
文件紧凑：RDB 文件是经过压缩的二进制文件，体积小，非常适合用于数据备份和灾备，便于存储和传输。例如，可以将 RDB 文件定期备份到远程存储，如 AWS S3 或阿里云 OSS，以防止数据丢失。
恢复速度快：在 Redis 重启时，加载 RDB 文件恢复数据的速度相对较快，因为它只需读取一个紧凑的二进制文件，而不需要像 AOF 那样重放大量的写命令。这对于需要快速恢复数据的场景，如电商系统的缓存预热，非常重要。
对性能影响小：由于 BGSAVE 是由子进程执行的，主进程在生成快照期间可以继续处理客户端请求，对 Redis 的性能影响较小 。
缺点：
数据丢失风险：RDB 是定期生成快照，在两次快照之间的数据如果 Redis 宕机，将会丢失。例如，如果设置了每 15 分钟生成一次 RDB 快照，而在第 14 分钟时发生宕机，那么这 14 分钟内的数据将会丢失。
资源消耗大：生成 RDB 快照时需要 fork 一个子进程，这个过程会消耗较多的 CPU 和内存资源，尤其是在数据量较大的时候，可能会导致服务器短暂的性能下降。
适用场景：
数据备份：由于 RDB 文件的紧凑性和易于传输的特点，非常适合用于定期的数据备份，如每天凌晨生成一次 RDB 快照并备份到远程存储。
快速恢复场景：对于那些可以容忍一定数据丢失，但需要快速恢复数据的场景，如非核心业务的缓存数据，RDB 是一个不错的选择。
Java 调用 Redis 进行 RDB 保存示例： 使用 Jedis 客户端库，可以很方便地在 Java 代码中手动触发 RDB 持久化：
import redis.clients.jedis.Jedis; public class RedisRDBExample { public static void main(String[] args) { try (Jedis jedis = new Jedis("localhost", 6379)) { // 插入一些测试数据 jedis.set("key1", "value1"); jedis.set("key2", "value2"); // 手动触发RDB持久化 String response = jedis.bgsave(); System.out.println("RDB Snapshot response: " + response); // 获取最后一次RDB持久化的时间 String lastSaveTime = jedis.info("Persistence").split("rdb_last_save_time:")[1].split("\n")[0]; System.out.println("Last RDB save time: " + lastSaveTime); } } }
上述代码中，首先创建了一个 Jedis 实例连接到本地的 Redis 服务器，然后插入了两条测试数据，接着调用 jedis.bgsave () 方法手动触发 RDB 持久化，并输出响应结果和最后一次 RDB 持久化的时间。
（二）AOF 持久化
AOF（Append Only File）持久化则是通过记录 Redis 服务器执行的每一条写操作命令，将这些命令以追加的方式写入到一个日志文件（默认名为 appendonly.aof）中，以此来实现数据的持久化 。
写命令追加机制：当 Redis 执行一个写命令时，会将该命令追加到 AOF 缓冲区中，然后根据配置的持久化策略，将缓冲区中的命令写入到 AOF 文件中。例如，当执行 “SET key value” 命令时，这个命令会被追加到 AOF 文件的末尾。
持久化策略：
always：每执行一条写命令，就立即将其同步到 AOF 文件中。这种策略数据安全性最高，但由于每次写操作都要进行磁盘 I/O，会严重影响 Redis 的性能，因此在生产环境中很少使用。
everysec：每秒将 AOF 缓冲区中的命令同步到 AOF 文件中。这是 AOF 的默认持久化策略，在性能和数据安全性之间取得了较好的平衡，即使服务器宕机，最多也只会丢失 1 秒的数据。
no：由操作系统决定何时将 AOF 缓冲区中的命令同步到 AOF 文件中，Redis 不主动进行同步操作。这种策略性能最高，但数据安全性最低，可能会丢失大量数据。
优点：
数据安全性高：由于 AOF 记录了每一条写操作命令，只要 AOF 文件没有损坏，就可以通过重放这些命令来恢复数据，最大限度地减少了数据丢失的风险，非常适合对数据完整性要求极高的场景，如金融交易系统。
可读性强：AOF 文件是文本格式，内容为一条条的 Redis 写命令，易于阅读和分析，方便进行数据恢复和调试。例如，可以通过查看 AOF 文件来了解 Redis 的操作历史，排查问题。
缺点：
文件体积大：随着时间的推移和写操作的不断增加，AOF 文件会越来越大，因为它记录了所有的写命令，这不仅会占用大量的磁盘空间，还会导致在恢复数据时重放命令的时间变长。
性能开销大：由于每次写操作都要追加到 AOF 文件中，并且在采用 “always” 或 “everysec” 策略时会进行磁盘 I/O 操作，所以 AOF 对 Redis 的性能有一定的影响，尤其是在高并发写操作的场景下。
适用场景：
数据完整性要求高的场景：如电商订单系统、金融账户系统等，任何数据的丢失都可能导致严重的后果，此时 AOF 持久化是首选。
需要对命令进行审计的场景：由于 AOF 文件记录了所有的写命令，可以方便地对 Redis 的操作进行审计，追踪数据的变化和操作历史。
Java 调用 Redis 进行 AOF 持久化示例： 在 Java 中使用 Jedis 启用 AOF 持久化并进行写操作：
import redis.clients.jedis.Jedis; public class RedisAOFExample { public static void main(String[] args) { try (Jedis jedis = new Jedis("localhost", 6379)) { // 启用AOF持久化 jedis.configSet("appendonly", "yes"); // 执行写操作 jedis.set("aof_key", "aof_value"); System.out.println("AOF enabled and data written."); } } }
上述代码通过 jedis.configSet ("appendonly", "yes") 启用了 AOF 持久化，然后执行了一个 SET 写操作，这个操作会被追加到 AOF 文件中。
（三）混合持久化
Redis 4.0 引入了混合持久化机制，它结合了 RDB 和 AOF 的优点，旨在提供更高效的数据持久化和恢复方案 。
原理：在进行 AOF 重写时，会将重写这一刻之前的内存数据以 RDB 快照的形式写入到 AOF 文件的开头，而之后的写操作命令则继续以 AOF 的方式追加到文件末尾。这样在恢复数据时，首先会加载 RDB 部分的数据，快速恢复大部分数据，然后再重放 AOF 部分的命令，将数据恢复到最新状态，既利用了 RDB 恢复速度快的优势，又保证了数据的完整性。
启用方式：在 redis.conf 配置文件中，通过设置 “aof-use-rdb-preamble yes” 来启用混合持久化模式。
适用场景：适用于对数据恢复速度和数据完整性都有较高要求的场景，如大型互联网应用的缓存和数据存储。它可以在保证数据安全的前提下，大大缩短 Redis 重启后的恢复时间，提高系统的可用性。例如，在一个大型电商平台中，使用混合持久化可以确保在服务器重启后，能够快速恢复商品缓存数据，减少对用户购物体验的影响。
二、Redis 哨兵模式：高可用的守护者
在分布式系统中，高可用性是确保服务持续稳定运行的关键因素。Redis 哨兵模式作为一种高可用解决方案，通过自动化的故障检测和转移机制，为 Redis 主从集群提供了强大的保障。它能够实时监控主从节点的运行状态，在主节点出现故障时，迅速将从节点晋升为新主节点，确保系统的不间断运行，极大地提高了 Redis 服务的可靠性和稳定性 。
（一）哨兵模式核心功能
监控（Monitoring）：哨兵节点会持续不断地检查 Redis 主节点和从节点是否正常运行。它通过定期向这些节点发送 PING 命令，来检测节点的网络连接状态以及是否能够正常响应请求。例如，默认情况下，每个哨兵每隔 1 秒就会向主节点、从节点及其余哨兵节点发送一次 PING 命令进行心跳检测 。
通知（Notification）：当被监控的 Redis 节点出现问题时，比如主节点下线、从节点与主节点断开连接等情况，哨兵可以通过预先设定的 API 向管理员或者其他应用程序发送通知，以便及时采取应对措施 。
自动故障转移（Automatic Failover）：这是哨兵模式的核心功能。当主节点发生故障时，哨兵会自动启动故障转移流程。它会从现有的从节点中挑选一个合适的节点晋升为新的主节点，并让其他从节点开始复制新的主节点，同时将故障主节点标记为从节点，当故障主节点恢复后，它会自动成为新主节点的从节点 。
配置提供者（Configuration Provider）：哨兵充当了 Redis 客户端的服务发现来源。客户端连接到哨兵系统，通过询问哨兵可以获取负责给定服务的当前 Redis 主节点的地址。当发生故障转移时，哨兵会及时向客户端报告新主节点的地址，使得客户端能够动态地获取到最新的主节点信息，保证与正确的主节点进行通信交互 。
（二）哨兵模式架构与配置
最小化部署架构：为了避免单点故障，哨兵模式的最小化部署需要至少 3 台机器。角色分配如下：1 台主节点（Master），负责处理所有的写请求；2 台从节点（Slave），用于复制主节点的数据，并处理读请求；3 台哨兵节点（Sentinel），通常与 Redis 节点部署在同一台机器上，以减少资源开销 。
配置步骤：
主从节点配置：
主节点（Master）配置（redis-master.conf）：
port 6379 daemonize yes logfile "/var/log/redis/redis-master.log"
上述配置中，port指定了 Redis 主节点的端口号为 6379，daemonize yes表示以守护进程方式运行 Redis，logfile指定了日志文件的路径 。
从节点（Slave）配置（redis-slave1.conf）：
port 6380 daemonize yes logfile "/var/log/redis/redis-slave1.log" replicaof 192.168.1.100 6379 # 指向主节点IP和端口
这里port设置从节点端口为 6380，replicaof配置项指定了主节点的 IP 地址和端口号，使从节点能够复制主节点的数据 。
哨兵节点配置：每个哨兵节点都需要独立配置，以
sentinel1.conf为例：
port 26379 daemonize yes logfile "/var/log/redis/sentinel1.log" sentinel monitor mymaster 192.168.1.100 6379 2 # 监控主节点，2表示需2个哨兵同意故障转移 sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判定为宕机 sentinel failover-timeout mymaster 10000 # 故障转移超时时间 sentinel parallel-syncs mymaster 1 # 故障转移时允许同步的从节点数
port指定哨兵节点的端口为 26379，sentinel monitor定义了要监控的主节点信息，包括主节点名称、IP 地址、端口号以及判断客观下线所需的哨兵同意数；sentinel down-after-milliseconds指定了判定节点主观下线的超时时间；sentinel failover-timeout设置了故障转移的超时时间；sentinel parallel-syncs表示故障转移时允许同时向新主节点同步数据的从节点数量 。 3.启动命令：
启动主从节点：
redis-server /path/to/redis-master.conf redis-server /path/to/redis-slave1.conf
启动哨兵节点：
redis-sentinel /path/to/sentinel1.conf
实际案例：3 台机器的部署：
机器与角色分配： | 机器 IP|Redis 角色 | 哨兵节点端口 | |----|----|----| |[192.168.1.100](192.168.1.100)|Master (6379)|Sentinel (26379)| |[192.168.1.101](192.168.1.101)|Slave1 (6380)|Sentinel (26380)| |[192.168.1.102](192.168.1.102)|Slave2 (6381)|Sentinel (26381)|
验证哨兵状态：可以使用
redis-cli -h 192.168.1.100 -p 26379 info sentinel命令来查看哨兵状态，输出示例如下：
# Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=192.168.1.100:6379,slaves=2,sentinels=3
通过这些配置和操作，就可以搭建起一个基本的 Redis 哨兵模式集群 。
（三）哨兵模式工作流程与注意事项
工作流程：
故障检测流程：
主观下线（Subjectively Down, SDOWN）：每个哨兵节点都会定期向主节点、从节点以及其他哨兵节点发送 PING 命令进行心跳检测。如果某个哨兵节点在配置的超时时间（由
sentinel down-after-milliseconds配置项决定）内没有收到目标节点的有效响应（如 PONG、LOADING、MASTERDOWN），该哨兵就会将目标节点标记为主观下线 。例如，当主节点宕机时，Sentinel1 和 Sentinel2 在 5 秒（假设配置为 5 秒）内未收到主节点的响应，它们会将主节点标记为主观下线 。客观下线（Objectively Down, ODOWN）：当一个哨兵将主节点标记为主观下线后，它会向集群中其他哨兵节点发送
SENTINEL is-master-down-by-addr命令，询问其他哨兵是否也认为该主节点下线。如果超过配置的 “确认阈值”（由sentinel monitor配置项中的quorum决定，通常为哨兵节点总数的半数以上）的哨兵节点都报告该主节点为 “主观下线”，则该主节点会被标记为 “客观下线”，此时可确认主节点确实故障，触发后续故障转移流程 。
故障转移流程：
选举领导者哨兵：一旦主节点被判定为客观下线，哨兵集群需要选举出一个领导者哨兵来负责执行本次故障转移操作。选举使用了 Raft 算法的思想，每个发现主节点客观下线的哨兵都会要求其他哨兵选举自己为领导者，第一个获得多数票（超过半数 + quorum 投票）的哨兵成为领导者 。
选择新主节点：领导者哨兵会从剩余的从节点中，根据一系列规则筛选出一个最合适的作为新的主节点。筛选规则包括：首先过滤掉不健康（连接失败 / 响应超时）的从节点；然后选择
slave-priority（从节点优先级，值越小优先级越高，默认 100）最高的从节点；如果优先级相同，则选择复制偏移量（replication offset，偏移量越大说明数据越新）最大的从节点；如果偏移量也相同，则选择 RunID 最小的从节点 。提升新主节点：领导者哨兵向选中的从节点发送
SLAVEOF NO ONE命令，使其升级为主节点 。切换从节点：领导者哨兵向其他从节点发送
SLAVEOF new_master_ip new_master_port命令，让它们开始复制新的主节点 。通知客户端：哨兵通过发布订阅机制，将新主节点的地址信息发布出去，客户端通过订阅相关频道，获取新主节点的地址，从而实现自动切换到新的主节点进行数据读写操作 。
注意事项：
网络分区问题：在网络分区的情况下，哨兵可能会因为部分节点之间的网络通信中断而误判主节点宕机。为了避免这种情况，需要合理配置超时时间，确保在短暂的网络波动时不会触发不必要的故障转移 。
节点数量：哨兵节点的数量应该为奇数个，并且至少为 3 个，这样可以避免在分布式场景下的投票平局问题，同时也能防止因单个哨兵节点故障导致整个哨兵系统失效 。
客户端兼容性：客户端需要支持哨兵协议，例如 Jedis、Lettuce 等常见的 Redis 客户端库都提供了对哨兵模式的支持。在使用时，需要确保客户端正确配置了哨兵节点的地址和主节点名称等信息 。
监控告警：建议通过
sentinel.log文件和 Prometheus + Grafana 等监控工具，实时监控哨兵的运行状态和关键指标，如节点的存活状态、故障转移次数、网络延迟等，并设置合理的告警规则，以便在出现问题时能够及时发现和处理 。
三、Redis 集群：分布式存储的利器
在当今数字化时代，数据量呈爆炸式增长，单机 Redis 的存储和处理能力逐渐难以满足大规模数据应用的需求。Redis 集群作为一种分布式解决方案，应运而生，它通过将数据分布在多个节点上，实现了数据的水平扩展，大大提升了存储容量和处理性能，为应对海量数据和高并发访问提供了强有力的支持 。
（一）集群特点与数据分片
数据分片：Redis 集群采用哈希槽（Hash Slot）的方式来实现数据分片。Redis 集群共有 16384 个哈希槽，每个键值对根据其键的哈希值（使用 CRC16 算法计算）对 16384 取模，得到一个 0 到 16383 之间的槽位编号，从而确定该键值对应该存储在哪个哈希槽中。例如，对于键 “user:1:info”，通过 CRC16 算法计算其哈希值后对 16384 取模，假设结果为 5000，那么该键值对就会被存储到编号为 5000 的哈希槽对应的节点上 。每个主节点负责一部分哈希槽，通过这种方式，将数据均匀地分布到集群中的各个节点上，实现了数据的分布式存储 。
高可用性：Redis 集群中的每个主节点都可以有一个或多个从节点。当主节点出现故障时，从节点会自动晋升为新的主节点，继续提供服务，确保数据的可用性和系统的稳定性。这种自动故障转移机制类似于哨兵模式，但在 Redis 集群中，故障转移是由集群内部的节点自主完成的，无需额外的哨兵节点 。
自动故障转移：当主节点被集群中的多数节点判定为下线（客观下线）时，其对应的从节点会发起选举，选举出一个新的主节点。选举过程基于 Raft 算法的思想，每个从节点都会向其他主节点请求投票，获得多数票（超过半数 + quorum 投票）的从节点将成为新的主节点 。例如，在一个包含 5 个主节点的集群中，如果某个主节点故障，其从节点需要获得至少 3 个主节点的投票才能成为新主节点 。
可扩展性：Redis 集群具有良好的可扩展性，可以方便地添加或删除节点。当需要添加新节点时，通过
redis-cli --cluster reshard命令，可以将部分哈希槽从现有节点迁移到新节点，实现数据的重新分布和集群的扩容；当需要删除节点时，也可以通过类似的方式将该节点上的哈希槽迁移到其他节点，然后将该节点从集群中移除 。
（二）集群搭建与客户端连接
集群搭建步骤：
安装 Redis：从 Redis 官方网站（https://redis.io/download）下载最新版本的 Redis 安装包，解压并编译安装。例如，在 Linux 系统中，可以使用以下命令：
wget http://download.redis.io/releases/redis-6.2.6.tar.gz tar xzf redis-6.2.6.tar.gz cd redis-6.2.6 make sudo make install
配置节点：假设要搭建一个包含 6 个节点（3 主 3 从）的 Redis 集群，分别为节点 1（7000 端口）、节点 2（7001 端口）、节点 3（7002 端口）、节点 4（7003 端口）、节点 5（7004 端口）、节点 6（7005 端口）。为每个节点创建一个独立的配置文件，如
redis-7000.conf：
port 7000 daemonize yes pidfile /var/run/redis_7000.pid cluster-enabled yes cluster-config-file nodes-7000.conf cluster-node-timeout 5000 appendonly yes
其中，cluster-enabled yes表示启用集群模式，cluster-config-file nodes-7000.conf指定集群配置文件，cluster-node-timeout 5000设置节点超时时间为 5000 毫秒 。按照同样的方式配置其他节点的配置文件，只需修改端口号和配置文件名即可 。
启动节点：使用
redis-server命令分别启动这 6 个节点：
redis-server redis-7000.conf redis-server redis-7001.conf redis-server redis-7002.conf redis-server redis-7003.conf redis-server redis-7004.conf redis-server redis-7005.conf
创建集群：使用
redis-cli --cluster工具创建集群，并指定每个主节点的从节点数量为 1：
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
执行上述命令后，redis-cli会自动分配哈希槽，并将从节点与主节点进行关联 。
验证集群状态：通过
redis-cli -c -p 7000 cluster nodes命令查看集群节点状态，确保所有节点都已正确加入集群，并且哈希槽分配均匀 。输出结果类似如下：
127.0.0.1:7000@17000 myself,master - 0 0 1 connected 0-5460 127.0.0.1:7001@17001 master - 0 1619488378943 2 connected 5461-10922 127.0.0.1:7002@17002 master - 0 1619488379949 3 connected 10923-16383 127.0.0.1:7003@17003 slave 127.0.0.1:7002@17002 - 0 1619488379446 3 connected 127.0.0.1:7004@17004 slave 127.0.0.1:7000@17000 - 0 1619488378441 1 connected 127.0.0.1:7005@17005 slave 127.0.0.1:7001@17001 - 0 1619488380456 2 connected
客户端连接：在 Java 中，使用 Jedis 客户端连接 Redis 集群的示例代码如下：
import redis.clients.jedis.HostAndPort; import redis.clients.jedis.JedisCluster; import java.util.HashSet; import java.util.Set; public class RedisClusterClient { public static void main(String[] args) { // 定义Redis集群节点 Set<HostAndPort> jedisClusterNodes = new HashSet<>(); jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7000)); jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7001)); jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7002)); try (JedisCluster jedisCluster = new JedisCluster(jedisClusterNodes)) { // 执行Redis操作 jedisCluster.set("cluster_key", "cluster_value"); String value = jedisCluster.get("cluster_key"); System.out.println("Value from Redis Cluster: " + value); } catch (Exception e) { e.printStackTrace(); } } }
上述代码中，首先创建了一个包含 3 个节点的Set<HostAndPort>集合，然后使用这个集合创建了JedisCluster对象，通过该对象就可以执行各种 Redis 操作，如设置键值对和获取值 。
四、缓存穿透：问题与解决方案
在 Redis 的应用中，缓存穿透是一个不容忽视的问题，它可能会对系统性能产生严重的影响，甚至导致系统崩溃。当缓存穿透发生时，大量无效请求绕过缓存直接访问数据库，会给数据库带来巨大的压力，增加数据库的负载，降低系统的响应速度，进而影响用户体验 。因此，有效地解决缓存穿透问题，对于保障系统的稳定运行和性能优化至关重要 。
（一）缓存穿透现象及原因
缓存穿透是指查询一个在缓存和数据库中都不存在的数据，导致每次请求都绕过缓存，直接访问数据库的现象 。在正常的缓存使用流程中，当客户端发起请求时，首先会查询缓存，如果缓存中存在数据，则直接返回；如果缓存未命中，则查询数据库，若数据库中存在数据，则将数据写入缓存并返回，若数据库中也不存在数据，则直接返回空值或错误信息 。但在缓存穿透的情况下，由于请求的数据在缓存和数据库中都不存在，且通常出于容错考虑，从数据库查询不到数据时不会写入缓存，这就使得每次相同的请求都会重复访问数据库，缓存失去了应有的作用 。
其产生的原因主要有以下两点：
业务代码或数据问题：业务代码中可能存在逻辑错误，导致查询了一些不合理或根本不存在的数据。例如，在根据用户 ID 查询用户信息时，由于前端校验不严，用户输入了一个不存在的 ID，或者代码中对 ID 的生成或处理出现错误，导致查询了一个无效的 ID 。
恶意攻击：恶意攻击者故意构造大量不存在的数据请求，对系统进行攻击。例如，通过编写脚本，不断发送请求，查询不存在的商品 ID、用户 ID 等，以此来消耗数据库资源，造成数据库压力过大，甚至导致系统瘫痪 。
（二）缓存空值
缓存空值是一种简单直接的解决缓存穿透的方案 。当从数据库查询到数据不存在时，将查询结果（通常为 null）缓存到 Redis 中，并设置一个较短的失效时间 。这样，当下次再有相同的请求时，直接从缓存中获取到 null 值并返回，避免了重复查询数据库 。
具体实现：在 Java 代码中，使用 Jedis 客户端实现缓存空值的示例如下：
import redis.clients.jedis.Jedis; public class CacheNullValueExample { private static final String REDIS_KEY_PREFIX = "cache_null_"; private static final int NULL_CACHE_EXPIRE_SECONDS = 60; // 空值缓存过期时间，60秒 public static String getValueFromCacheOrDB(String key, Jedis jedis) { String cacheKey = REDIS_KEY_PREFIX + key; String value = jedis.get(cacheKey); if (value != null) { return value; } // 模拟从数据库查询数据 String dbValue = getValueFromDatabase(key); if (dbValue != null) { jedis.setex(cacheKey, 3600, dbValue); // 缓存正常数据，过期时间3600秒 return dbValue; } else { jedis.setex(cacheKey, NULL_CACHE_EXPIRE_SECONDS, ""); // 缓存空值 return null; } } private static String getValueFromDatabase(String key) { // 这里是实际从数据库查询的逻辑，暂时返回null模拟查询不到数据 return null; } public static void main(String[] args) { try (Jedis jedis = new Jedis("localhost", 6379)) { String result = getValueFromCacheOrDB("test_key", jedis); System.out.println("Result: " + result); } } }
优缺点：
优点：实现简单，不需要引入额外的组件或复杂的算法，对现有系统的侵入性较小；能够有效地减少数据库的查询次数，降低数据库的压力，特别是对于那些查询频率较高且数据相对稳定的业务场景，效果显著 。
缺点：会占用一定的缓存空间，当存在大量不存在的数据被请求时，可能会导致缓存空间浪费；如果在空值缓存的有效期内，数据被写入数据库，可能会出现数据不一致的情况 。例如，在空值缓存有效期内，业务系统将数据插入数据库，但缓存中仍然返回空值 。
（三）布隆过滤器
布隆过滤器是一种高效的概率型数据结构，用于判断一个元素是否在一个集合中，它可以有效地解决缓存穿透问题 。其原理是通过多个哈希函数将一个元素映射到位数组（Bitmap）中的多个位置，并将这些位置置为 1 。当查询一个元素时，使用相同的哈希函数计算出相应的位置，如果这些位置上的值都为 1，则认为该元素可能存在；如果有任何一个位置上的值为 0，则可以确定该元素一定不存在 。
使用步骤：
初始化：在系统启动时，将数据库中已存在的数据的键值通过多个哈希函数计算，映射到位数组中，并将相应位置置为 1 。例如，假设有一个包含 1000 个商品 ID 的数据库，在系统启动时，将这 1000 个商品 ID 通过 3 个哈希函数映射到位数组中 。
查询：当有请求到来时，先通过布隆过滤器判断请求的数据是否可能存在 。如果布隆过滤器判断数据不存在，则直接返回，无需查询数据库；如果判断数据可能存在，则继续查询缓存和数据库 。例如，当请求查询商品 ID 为 1001 的商品信息时，先通过布隆过滤器判断，如果布隆过滤器判断该 ID 不存在，则直接返回商品不存在的信息，不再查询缓存和数据库 。
Java 实现示例：使用 Guava 库实现布隆过滤器的示例代码如下：
import com.google.common.hash.BloomFilter; import com.google.common.hash.Funnels; import java.nio.charset.Charset; public class BloomFilterExample { private static final int EXPECTED_ELEMENTS = 100000; // 预计元素数量 private static final double FALSE_POSITIVE_RATE = 0.01; // 误判率 private static BloomFilter<String> bloomFilter = BloomFilter.create( Funnels.stringFunnel(Charset.forName("UTF-8")), EXPECTED_ELEMENTS, FALSE_POSITIVE_RATE ); public static void main(String[] args) { // 初始化布隆过滤器，添加一些存在的元素 bloomFilter.put("element1"); bloomFilter.put("element2"); // 模拟查询 if (bloomFilter.mightContain("element1")) { System.out.println("element1 might exist"); } else { System.out.println("element1 definitely does not exist"); } if (bloomFilter.mightContain("nonexistent_element")) { System.out.println("nonexistent_element might exist"); } else { System.out.println("nonexistent_element definitely does not exist"); } } }
优缺点：
优点：空间效率高，布隆过滤器使用位数组存储数据，相比于其他数据结构，占用的内存空间非常小；查询速度快，查询时间复杂度为 O (k)，其中 k 是哈希函数的数量，能够快速判断数据是否存在，有效地减少了无效请求对数据库的访问 。
缺点：存在误判率，由于哈希冲突的存在，布隆过滤器可能会将一些不存在的数据误判为存在，即存在假阳性（False Positive）的情况 。例如，可能会将 ID 为 999999 的商品误判为存在，但实际上该商品在数据库中并不存在；不支持删除操作，标准的布隆过滤器不支持删除已插入的元素，因为删除一个元素可能会影响其他元素的判断结果 。如果需要支持删除操作，需要使用更复杂的计数布隆过滤器等扩展版本 。
五、总结与展望
在 Redis 的世界里，持久化、哨兵、集群和缓存穿透解决方案构成了其稳固的技术基石，对于面试和实际开发都具有举足轻重的意义。
持久化机制是 Redis 数据安全的保障，RDB 以其紧凑的快照文件和快速恢复的优势，适用于对数据恢复速度要求较高且能容忍一定数据丢失的场景，如非核心业务的缓存数据备份；AOF 则凭借记录每一条写操作命令的特性，实现了数据的高安全性和完整性，成为金融、电商等对数据一致性要求极高领域的首选；而混合持久化巧妙地融合了 RDB 和 AOF 的长处，在提高恢复速度的同时保证了数据的完整，为大型互联网应用提供了高效的持久化方案 。在面试中，深入理解持久化机制的原理、优缺点和适用场景，能够展现出对 Redis 核心功能的深刻掌握，为面试官留下专业的印象；在实际开发中，根据业务需求合理选择持久化方式，能够确保数据的安全存储和高效恢复，提升系统的稳定性和可靠性 。
