Redis - 高并发场景下的Redis最佳实践

文章目录

概述
6座大山之_缓存雪崩（缓存全部失效）
- 缓存雪崩的两种常见场景
- 如何应对缓存雪崩？
6座大山之_缓存穿透（查询不存在的 key）
- 缓存穿透的原因
- 解决方案
- - 1. 数据校验
  - 2. 缓存空值
  - 3. 频控
  - 4. 使用布隆过滤器
6座大山之_缓存击穿（热 key 突然失效）
- 解决思路1：永不过期
- 解决思路2：逻辑过期
- 解决思路3：互斥锁
6座大山之_缓存打满（内存空间不够）
- Redis的淘汰策略
- 发生场景
- 解决方案
6座大山之_Hot Key
- 发现热 Key
- 处理热 Key
6座大山之_Big Key
- 问题：
- 可能发生的场景：
- 发现大 Key的方法：
- 删除大 Key的方法：
- 避免产生大 Key的方法：

在这里插入图片描述

概述

在这里插入图片描述

在高并发系统中，Redis缓存通常被视为数据在存入数据库之前的重要中间层，其设计专注于缓存功能，性能往往比传统数据库高出一个数量级以上。以Redis单实例而言，其读取并发能力可达到10万QPS（官方理论值）。

然而，正因为Redis的高并发处理能力，它在系统链路中扮演着至关重要的角色。一旦系统遭遇高峰期，若我们在Redis处理方面稍有疏忽，可能会导致整个系统瘫痪。

因此，我们接下来将探讨在复杂、高并发的互联网系统中，缓存可能面临的一系列挑战，以及我们可以采取的措施来应对这些挑战。

6座大山之_缓存雪崩（缓存全部失效）

在这里插入图片描述

在高并发系统中，缓存（通常是Redis）扮演着重要的角色，它被视为数据库的保护伞，能够有效减轻数据库负载。然而，有时候我们可能会面临一个令人头疼的问题：缓存竟然完全失效了，而流量却突然间涌向了数据库，最终可能导致整个系统的不可用。这种情况被称为缓存雪崩。

缓存雪崩的两种常见场景

Redis集群不可用： 即使Redis是以集群模式部署，但当集群中的某个节点不可用时（如重启），如果没有合理的容错机制，可能会导致大量缓存同时失效，从而压垮数据库。
大量缓存集中失效： 在缓存预热过程中，如果将大量缓存集中预热或更新，那么这些缓存可能在同一时间突然失效，导致系统出现雪崩效应。

如何应对缓存雪崩？

合理部署Redis集群： 将Redis部署为集群模式，确保数据在多个节点上存在，即使某个节点不可用，也不至于导致所有缓存失效。跨机房部署可以进一步提高容灾能力。
持久化数据并预热缓存： 在重启Redis等操作前，通过SAVE指令将数据持久化，或者在重启后人工触发缓存预热，确保缓存不会因为重启而全部失效。
随机设置过期时间： 对于集中预热的缓存数据，设置过期时间时增加一定的随机性，使得缓存失效时间分散，避免集中失效导致的雪崩效应。

在这里插入图片描述

6座大山之_缓存穿透（查询不存在的 key）

在这里插入图片描述

在缓存系统中，缓存穿透是一种常见而又令人头疼的问题。当用户请求查询缓存中不存在的数据时，这些请求会直接穿透缓存打到数据库，可能导致数据库负载过大，甚至引发系统崩溃。特别是在攻击者持续发起此类请求的情况下，这种攻击行为会对系统造成严重影响。

缓存穿透的原因

缓存穿透通常发生在以下情况下：

查询不存在的数据： 当用户请求查询缓存中不存在的数据时，如果缓存未命中，请求就会直接打到数据库，导致缓存穿透现象的发生。
恶意攻击： 攻击者可能会利用此漏洞，不断发起查询不存在数据的请求，造成数据库压力过大，甚至拖垮整个系统。

解决方案

1. 数据校验

在接入层对请求数据进行严格的校验，例如检查ID是否为正整数、参数范围是否合法等，以过滤掉非法请求，避免其穿透缓存直接访问数据库。

2. 缓存空值

对于查询不到的数据，可以在缓存中存储一个特殊的“null”值，下次请求命中缓存时直接返回。但需注意设置空值缓存的过期时间，避免缓存空间被占满。

3. 频控

针对恶意攻击者，可实施频率限制策略，例如基于IP地址进行频控，及时拒绝异常请求，以保护数据库不受攻击。

4. 使用布隆过滤器

布隆过滤器是一种高效的数据结构，可用于判断元素是否存在，但有一定的误判率。可以将所有数据存储在布隆过滤器中，查询缓存前先检查布隆过滤器，如果不存在则直接返回，从而避免不必要的缓存/数据库查询。

在这里插入图片描述

– 在这里插入图片描述

缓存穿透是高并发系统中常见的问题，但通过合理的预防措施和技术手段，我们可以有效地减轻其影响。在设计和开发过程中，应注重数据校验、缓存空值设置、频率限制以及布隆过滤器等措施的应用，以确保系统的稳定和安全运行。

6座大山之_缓存击穿（热 key 突然失效）

在这里插入图片描述

在缓存系统中，缓存击穿是一种常见但十分危险的现象。当一个热门的缓存 key 在失效瞬间，大量请求同时打到数据库，可能会导致数据库压力过大，甚至引发系统崩溃。

为应对这一挑战，我们可以采取以下解决方案：

解决思路1：永不过期

针对某些热门的 key，可以选择不设置过期时间，而是采用定时任务或定时更新的方式，以避免 key 失效的情况。

解决思路2：逻辑过期

对于不适合永不过期的全量 key，可以设置一个逻辑过期时间。即在缓存中存储数据的同时，记录数据的逻辑过期时间，定时任务异步地重新刷新缓存，并重新设置其物理过期时间和逻辑过期时间。

例如 Key1=Value1 这样的缓存，过期时间是 2024.10.01.00:00，那么物理过期时间可能设置在 2024.10.01.01:00，但是我们将 value 这样存储

{

	v:"Value1",

	t:1727715600

}

当读取到这个数据过期的时候，我们让任务异步地去重新刷新这个缓存，并重新设置其物理过期时间和逻辑过期时间，这样击穿到数据库的线程就可控为一条异步线程了。

这里的原则是物理过期时间一定要比逻辑过期时间久

解决思路3：互斥锁

使用互斥锁，在发现缓存不存在时加锁，只允许一条线程去数据库查询真实数据，其他线程等待。通过双重检查机制，确保数据在锁被释放前已被写入缓存，从而避免多次数据库访问。

在这里插入图片描述

public String query(String key) {
    String data = stringRedisTemplate.opsForValue().get(key);
    if (StringUtils.isEmpty(data)) {
        RLock locker = redissonClient.getLock("locker_" + key);
        if (locker.tryLock()) {
            try {
                data = stringRedisTemplate.opsForValue().get(key);
                if (StringUtils.isEmpty(data)) {
                    data = getDataFromDB(key);
                    stringRedisTemplate.opsForValue().set(key, data, 5, TimeUnit.SECONDS);
                }
            } finally {
                locker.unlock();
            }
        } else {
            Thread.sleep(100);
            return query(key);
        }
    }
    return data;
}

以上是利用 Redisson 实现的分布式锁示例，确保只有一条线程去数据库查询数据，其他线程等待或递归查询缓存，以防止缓存击穿。

之所以使用 1 个分布式锁，这样才能放 1 条线程去数据库访问，但是真实使用的时候并不需要做得这么重，只需要进程级别的加锁即可，因为我们服务的数量通常是有限且不大的，那么有限的并发打到数据库，做一些重复的工作也并不会太影响。

在这里插入图片描述

缓存击穿是高并发系统中常见的问题，但通过合理的策略和技术手段，我们可以有效地预防和应对这一挑战。重视缓存设计和管理，结合适当的方案，可以有效地保护数据库并确保系统的稳定运行。

6座大山之_缓存打满（内存空间不够）

在这里插入图片描述

在Redis中，内存是有限的，当内存使用达到上限时，需要采取一些策略来淘汰一定不使用的key，以释放空间存储新的key。这个上限由配置的maxmemory参数决定，无论是否开启持久化，都会触发淘汰策略。

maxmemory 100mb

Redis的淘汰策略

noeviction（默认）： 不删除任意数据，但根据引用计数器进行释放，当内存不足时直接返回错误。
volatile-lru： 选择最近最少使用的带过期时间的数据进行淘汰。
allkeys-lru： 选择最近最少使用的数据进行淘汰，包括带过期时间和不带过期时间的数据。
volatile-lfu： 选择使用频率最低的带过期时间的数据进行淘汰。
allkeys-lfu： 选择使用频率最低的数据进行淘汰，包括带过期时间和不带过期时间的数据。
volatile-random： 随机选择一个带过期时间的数据进行淘汰。
allkeys-random： 随机选择一个数据进行淘汰，包括带过期时间和不带过期时间的数据。
volatile-ttl： 选择最接近过期的数据进行释放操作，只从带过期时间的数据集中选择。

发生场景

把Redis当存储使用： 部分场景下，将Redis用作数据存储，不设置过期时间，可能导致内存持续增长，触发淘汰策略，不正确的淘汰策略可能导致数据丢失。
Bug数据逐步污染缓存： 开发人员忘记设置过期时间，或设置过期时间过长，导致缓存内存被占满。

解决方案

存储隔离： 对于永不过期的数据，要与正常的缓存数据做集群的分离，以便设置不同的淘汰策略。
容量监控：
- 预估使用容量，给予足够的冗余应对业务发展。
- 实时监控使用量变化，一旦超过阈值，立即扩容并排查原因。
- 监控key的过期时间，定期扫描，发现未设置过期时间或设置不合理的key，并及时修复。

在实际应用中，结合合适的淘汰策略和监控手段，能够更好地管理Redis缓存，保障系统的稳定性和可靠性。

6座大山之_Hot Key

热 Key 是指在Redis中频繁访问的某些特定key，可能导致单个实例的性能问题。即使对Redis进行扩容，也无法完全解决热 Key 问题，因为对于同一个key的访问通常会集中在同一个实例上。

热 Key 问题可能导致接口超时、网络负载过大、连接数达到上限等一系列问题，严重影响系统稳定性和性能。

发现热 Key

按业务场景预估热点 key： 根据业务特点预估一些热门key，如促销商品、秒杀商品等。这种方法简单但依赖于人工经验，无法发现意外的热点。
客户端收集： 封装代码统计Redis的所有访问命令，对命令进行统计分析。简单方便但需要代码修改。
代理层收集： 在访问Redis之前添加访问代理层，代理层收敛请求并进行统计。无代码侵入但架构复杂。
Redis监控命令： 使用Redis提供的监控命令，如hotkeys命令，实时监控热 Key。无代码侵入但对大集群扫描较慢。

# 统计间隔0.1秒输出一次hotkeys

redis-cli --hotkeys -i 0.1

root@root:~# redis-cli --hotkeys -i 0.1

# Scanning the entire keyspace to find hot keys as well as

# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec

# per 100 SCAN commands (not usually needed).

[00.00%] Hot key 'aaa' found so far with counter 1

-------- summary -------

Sampled 4 keys in the keyspace!

hot key found with counter: 1    keyname: aaa

网络抓包分析： 抓取Redis服务器侧的包进行分析，发现流量倾斜和热 Key。无代码侵入但可能恶化现有问题。

处理热 Key

本地缓存： 在访问Redis之前加一层本地缓存，将部分热 Key 存储在本地。需要合理设计淘汰策略和热 Key 发现机制。
本机Redis备机： 将Redis备机部署在本地，充当本地缓存的角色。需要考虑一致性和维护成本。
备份存储： 将热 Key 备份成多份，分布在不同实例上，分散流量。需要设计合适的备份策略。

Cluster 模式下某个 key 是存储在固定的某个实例上的，所以热 key 才如此棘手，因为所有流量都打到同一个实例上。那么有没有可能打散这些流量呢？

答案是有可能的。如果我们把热 key 备份成 N 份，例如，原 key 是 goods📱detail，那么这 N 份的 key 就分为 goods:iphone:detail:0，goods:iphone:detail:1，goods:iphone:detail:2，……，goods:iphone:detail:N-1，分散在集群的多个节点，查询的时候可以按照一定的散列规则分散去访问不同的 key 副本，规则可以选择随机散列、按用户散列等。

随机散列的示意 Java 代码如下：

int N = M * 2//M是集群里的节点数，得到备份数量

//生成随机数

int random = new Random().nextInt(N);



//构造备份新key

String bakHotKey = hotKey + “_” + random；

String data = getFromRedis(bakHotKey);

if (data == null) {//查询不到缓存，从数据库查询出来放到对应的备份Key

    data = getFromDB();

    saveToRedis(bakHotKey, expireTime);

}