【NoSQL数据库】Redis学习笔记

一、缓存穿透

缓存穿透是先查Redis，发现缓存中没有数据，再查数据库。然而，如果查询的数据在数据库中也不存在，那么每次查询都会绕过缓存，直接落到数据库上。

解决方案一、缓存空数据

查询Redis缓存：首先查询Redis缓存，看看请求的数据是否已经缓存。
缓存未命中：如果Redis缓存中没有该数据，则查询数据库。
数据库查询结果为空：如果数据库中也没有该数据（即数据不存在），则将这个空结果缓存起来，并设置一个较短的过期时间。
返回结果：下一次查询相同的数据时，直接从缓存中返回空结果。

布隆过滤器是一种高效的概率数据结构，用于测试一个元素是否在一个集合中。它能够快速判断某个元素是否可能存在于集合中，但不能准确地确定元素一定存在。布隆过滤器通过牺牲一定的准确性来大幅度节省空间。

布隆过滤器的原理

哈希函数：布隆过滤器使用多个哈希函数将输入元素映射到一个位数组中的多个位置。
位数组：布隆过滤器维护一个固定大小的位数组，初始时所有位都为0。
添加元素：将一个元素添加到布隆过滤器时，通过多个哈希函数计算出多个哈希值，并将位数组中对应位置的值设为1。
查询元素：查询一个元素是否在布隆过滤器中时，使用相同的哈希函数计算出多个哈希值，并检查位数组中对应位置的值是否全部为1。如果全部为1，则说明该元素可能在集合中；如果有任何一个位置的值为0，则说明该元素肯定不在集合中。

使用布隆过滤器解决缓存穿透

布隆过滤器可以用于防止缓存穿透，因为它能够高效地判断某个查询是否对应数据库中不存在的数据。如果布隆过滤器判断某个元素肯定不存在，就可以直接返回空结果，而不必查询数据库和缓存。

二、缓存击穿

给一个key设置过期时间，当缓存中的热点数据（即频繁被访问的数据）过期时，意味着缓存系统中存储的这部分数据不再有效，并且会被移除或者需要重新加载。此时，如果有大量请求同时访问这个数据，而缓存中没有有效的数据存在，那么这些请求将直接转发到后端数据库进行查询。由于这些数据是热点数据，访问频繁，所以瞬间的大量请求可能会给后端数据库带来很大的压力，甚至导致数据库负载过高，性能下降，甚至崩溃。这种情况被称为缓存击穿。

解决方案一：互斥锁

背景问题

想象你是一家餐馆的老板，平时店里有一个公告板，上面写着每日特价菜的信息（类似于缓存）。大家都可以直接看公告板获取信息，而不需要每个人都来问你（类似于访问数据库）。

但有时候，公告板上的信息过期了（缓存失效），需要更新。这时，很多客人都同时来问你今天的特价菜是什么（大量并发请求访问数据库）。如果所有人都来问你，你就会忙不过来（数据库压力骤增）。

互斥锁解决方案

为了防止这种情况，你决定用一个办法来解决这个问题——你安排一个锁（锁机制）。

具体过程

检查公告板：每个客人来餐馆时，首先会看看公告板（检查缓存）。
尝试获取锁：如果公告板上的信息过期了（缓存失效），第一个发现的客人会去找你更新信息。但你设立了一条规则：每次只能有一个客人来问你特价菜是什么（获取锁）。
锁获取成功：如果某个客人第一个来问你特价菜（成功获取锁），你会告诉他特价菜是什么（查询数据库），并让他把新的信息写到公告板上（更新缓存）。然后你会解除限制（释放锁），让其他客人可以直接看公告板。
锁获取失败：如果另外的客人也发现公告板的信息过期了，但发现已经有一个客人去问你了（获取锁失败），他们不会再来打扰你，而是等一会儿再看公告板，看看新信息是否已经更新（等待并重试）。

import time
import redis

# 初始化 Redis 连接，类似于你有一个能记录锁状态的工具
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)

def get_special_dish_with_lock(key, query_database, lock_timeout=10, cache_timeout=60):
# 先看看公告板上有没有特价菜的信息
data = redis_client.get(key)

if data is not None:
return data

# 如果公告板上没有信息，第一个客人会去找你问特价菜，并设立一个锁
lock_key = f"lock:{key}"
if redis_client.setnx(lock_key, 1):
redis_client.expire(lock_key, lock_timeout) # 设置锁的过期时间，防止有人占着不放

try:
# 再次检查公告板，因为可能有其他人已经更新了
data = redis_client.get(key)
if data is None:
# 如果公告板上还是没有信息，你告诉第一个客人特价菜是什么
data = query_database()

# 第一个客人把新信息写到公告板上
redis_client.set(key, data, ex=cache_timeout)
finally:
# 解除锁，其他客人可以直接看公告板了
redis_client.delete(lock_key)
else:
# 如果有其他客人已经去问你了，其他客人等一会儿再看公告板
while not data:
time.sleep(0.1)
data = redis_client.get(key)

return data

# 模拟数据库查询函数
def query_database():
return "Today's Special Dish"

# 使用互斥锁获取特价菜信息
key = "special_dish"
special_dish = get_special_dish_with_lock(key, query_database)
print(special_dish)

更新缓存的过程

缓存失效检测：每当有请求到来时，首先检查缓存中是否有需要的数据以及数据是否有效（未过期）。
缓存失效：如果缓存中没有数据或者数据已过期，就需要从数据库中获取最新的数据。
查询数据库：从数据库中查询最新的数据。
将数据存入缓存：将从数据库中查询到的最新数据存入缓存，并设置一个新的过期时间。
响应请求：将最新的数据返回给请求方。

缓存过期解决方案

逻辑过期是一种缓存管理策略，通过在缓存数据中附带一个逻辑过期时间，而不是依赖缓存系统的物理过期机制。这样可以避免热点数据在过期瞬间引发的缓存击穿问题，同时确保数据的一致性和及时性更新。

逻辑过期的餐馆例子

背景

假设你是一家餐馆的老板，公告板上每天展示特价菜的信息。为了让信息保持最新，你决定采用逻辑过期的方式来管理特价菜的信息。

具体过程

公告板展示特价菜：公告板上写着当天的特价菜信息，并附带一个逻辑过期时间（比如某个时间之后，信息被认为过期）。
检查公告板：每个客人到来时，首先看看公告板上的特价菜信息。
判断逻辑过期：客人不仅看特价菜信息，还要检查逻辑过期时间。
- 未过期：如果逻辑过期时间还没到，客人就直接获取信息。
- 已过期：如果逻辑过期时间到了，客人仍然先拿到旧的信息，但同时通知你更新信息。
后台更新：你在后台更新特价菜信息并重新设置逻辑过期时间，过程中公告板上的旧信息仍然有效。
更新公告板：新信息准备好后，公告板上的特价菜信息和逻辑过期时间被更新。

优点

防止缓存击穿：即使逻辑过期时间到了，旧的信息仍然可用，避免了大量请求同时打到数据库。
数据更新及时：后台更新新数据，确保新数据在逻辑过期后能尽快生效。

import time
import redis
import json

# 初始化 Redis 连接
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)

def get_data_with_logical_expiration(key, query_database, logic_expiry_time=60):
# 先看看缓存中有没有数据
cached_data = redis_client.get(key)

if cached_data is not None:
cached_data = json.loads(cached_data)
data = cached_data["data"]
expiry_time = cached_data["expiry_time"]

# 检查逻辑过期时间
if time.time() < expiry_time:
return data
else:
# 逻辑过期，启动后台更新
refresh_cache_async(key, query_database, logic_expiry_time)
return data # 返回旧的数据
else:
# 如果缓存中没有数据，查询数据库
data = query_database()

# 将数据和逻辑过期时间存入缓存
expiry_time = time.time() + logic_expiry_time
cached_data = {"data": data, "expiry_time": expiry_time}
redis_client.set(key, json.dumps(cached_data))

return data

def refresh_cache_async(key, query_database, logic_expiry_time):
# 模拟异步更新缓存
data = query_database()
expiry_time = time.time() + logic_expiry_time
cached_data = {"data": data, "expiry_time": expiry_time}
redis_client.set(key, json.dumps(cached_data))

# 模拟数据库查询函数
def query_database():
return "Today's Special Dish"

# 获取特价菜信息
key = "special_dish"
special_dish = get_data_with_logical_expiration(key, query_database)
print(special_dish)

三、缓存雪崩

同一时间段内大量缓存key同时失效或者Redis服务器宕机，导致大量请求到达服务器，带来巨大压力。

解决方案:

给不同key的剩余生存时间(该键距离过期还有多少秒)增加随机值。

集群模式（Cluster Mode）

什么是 Redis 集群模式？

Redis 集群模式是 Redis 提供的分布式架构，允许数据在多个 Redis 节点之间分布。集群模式通过数据分片将数据分布到多个 Redis 实例上，每个节点负责部分数据，并且集群模式提供了自动故障转移和负载均衡的能力。

解决雪崩问题的机制

数据分片：由于数据分布在多个节点上，单个节点的故障不会导致整个集群的服务中断。缓存雪崩只会影响到某个分片的数据。
高可用性：自动故障转移和数据备份使得集群能够继续提供服务，即使某些节点失效，也不会影响整个系统的正常运行。

哨兵模式（Sentinel Mode）

什么是 Redis 哨兵模式？

Redis 哨兵模式是 Redis 提供的一种高可用解决方案。哨兵模式通过监控主节点和从节点，自动处理故障转移（主节点失效时从节点升级为主节点）来提高 Redis 的可用性。

如何工作？

监控：哨兵进程监控主节点和从节点的状态，检测故障。
通知：当检测到主节点发生故障时，哨兵会发出通知。
故障转移：哨兵会自动将某个从节点升级为新的主节点，并更新系统中的配置。
配置提供：客户端可以通过哨兵获取当前的主节点信息，以便进行连接。

解决雪崩问题的机制

自动故障转移：即使主节点失效，哨兵模式可以自动进行故障转移，确保服务持续可用，降低单点故障带来的影响。
高可用性：主从复制和自动故障转移使得 Redis 哨兵模式能够保证数据的高可用性，从而降低因为主节点失效导致的雪崩效应。

双写一致性（Double Write Consistency）是指在系统中同时更新两个或更多存储介质（如数据库和缓存）时，确保这些存储介质中的数据保持一致的机制

四、双写一致性

在使用Redis和主数据库实现双写一致性时，可以结合共享锁和排他锁来确保数据一致性。以下是一个详细的实现方案：

1. 架构概述

主数据库：负责持久化存储数据，支持写操作。
Redis缓存：负责加速读操作，提高性能。

2. 锁机制

共享锁（Shared Lock）：用于读操作。
排他锁（Exclusive Lock）：用于写操作。

3. 实现步骤

读操作

请求获取共享锁。
从Redis缓存中读取数据。如果缓存中没有数据，则从主数据库中读取，并将数据写入Redis缓存。
释放共享锁。

写操作

请求获取排他锁。
写入主数据库。
将数据更新到Redis缓存中。
释放排他锁。

为什么这样可以保证数据一致性

读操作不干扰写操作：
- 读操作使用共享锁，多个读操作可以并发进行，但在读操作进行时，写操作被排除在外，避免了读到不一致的数据。
写操作独占资源：
- 写操作使用排他锁，确保在写操作进行时，没有其他读或写操作进行。这样可以确保写操作完成后，数据在主数据库和Redis缓存中是一致的。
缓存更新机制：
- 读操作会在缓存未命中时，从主数据库读取数据并更新缓存。写操作会在主数据库更新后，立即更新缓存。这确保了缓存中的数据始终与主数据库保持一致。

五、Redis持久化

Redis RDB 快照

Redis 使用 RDB（Redis Database）文件来实现快照功能。RDB 快照是将 Redis 内存中的所有数据在特定时间点保存到一个二进制文件中的过程。RDB 文件包含了 Redis 数据库中的所有键值对的快照，可以用于数据恢复。

RDB 快照的生成方式

自动生成：
- Redis 可以根据配置文件中的 save 选项定期生成 RDB 快照。例如，save 900 1 表示在 900 秒（15 分钟）内至少有一个写操作时触发快照，save 300 10 表示在 300 秒（5 分钟）内至少有 10 次写操作时触发快照。
手动生成：
- 可以通过命令 BGSAVE 或 SAVE 手动触发快照生成。BGSAVE 命令在后台生成快照，SAVE 命令在前台生成快照，阻塞 Redis 服务器的所有客户端请求。

持久化（Persistence）是指将数据存储在非易失性存储介质上，以便在系统重启或崩溃后数据仍然可以被恢复。

bgsave命令

BGSAVE 命令：

创建子进程：当 Redis 执行 BGSAVE 命令时，主进程会创建一个子进程（fork），这个子进程负责生成 RDB 文件。主进程继续响应客户端请求，而子进程负责写入 RDB 文件。
写入文件：子进程会将内存中的所有数据写入 RDB 文件。这个过程中，主进程不会阻塞，可以继续处理其他请求。

在 Redis 中，当需要生成 RDB（Redis Database）快照时，Redis 会使用一个子进程来处理 RDB 文件的生成，这样主进程可以继续响应客户端的请求而不被阻塞。下面是这一过程的详细解释：

子进程和主进程的角色

主进程

主进程是 Redis 的核心进程，它负责处理所有的客户端请求，如读写数据、执行命令、管理连接等。在 Redis 执行 BGSAVE 命令时，主进程的主要任务是：

继续接受和处理来自客户端的请求。
在子进程生成 RDB 文件期间，不会受到阻塞。
确保系统的高可用性和响应能力，即使在生成快照的过程中。

子进程

当 Redis 执行 BGSAVE 命令时，主进程会创建一个子进程来处理 RDB 文件的生成。子进程负责：

复制内存数据：子进程会在创建时复制主进程的内存数据。这意味着子进程会有一个内存中数据的副本，便于将这些数据写入 RDB 文件。
写入 RDB 文件：子进程将内存中的数据以 RDB 格式写入到磁盘上的文件中。这个过程涉及将所有键值对序列化并压缩到一个二进制文件中。
完成后终止：子进程在 RDB 文件写入完成后会退出，生成的 RDB 文件会保存在 Redis 配置文件中指定的位置。

生成 RDB 文件的过程

主进程发起快照：
- 当 Redis 执行 BGSAVE 命令时，主进程创建一个子进程。
子进程复制内存：
- 子进程会复制主进程的内存数据，但在这个阶段，主进程和子进程都使用相同的数据快照。这保证了在快照生成过程中，数据的一致性。
子进程生成 RDB 文件：
- 子进程将内存数据序列化、压缩并写入到 RDB 文件中。这个过程中，主进程可以继续处理客户端的请求。
子进程完成并退出：
- 一旦子进程完成 RDB 文件的生成，它会退出。生成的 RDB 文件会保存到磁盘上，供未来恢复使用。

为什么使用子进程

使用子进程的主要原因是：

避免主进程阻塞：生成 RDB 文件的过程可能需要一定的时间，特别是当数据量很大时。如果主进程直接生成快照，它会阻塞所有客户端请求，影响系统性能和响应能力。通过使用子进程，可以确保主进程继续处理客户端请求，而子进程在后台生成快照。
数据一致性：通过复制内存数据到子进程，子进程可以在一个一致的时间点生成 RDB 文件，避免了在快照生成过程中数据的变化影响快照的一致性。
系统可靠性：将数据写入磁盘的过程是一个相对耗时的操作。将其交给子进程处理，可以提高系统的整体可靠性和响应速度，避免对主进程的性能产生重大影响。

Redis 的 AOF（Append Only File）持久化机制是一种通过将所有写操作追加到日志文件中来实现数据持久化的方式。与 RDB（Redis Database）通过快照生成文件不同，AOF 记录的是所有写操作的日志，以便在 Redis 重启时可以通过重放这些操作来恢复数据。