先上盘小菜：大Key低QPS vs 小Key高QPS哪个影响大

大Key低QPS vs 小Key高QPS的影响: 大Key即使QPS低也会对整体性能产生较大影响,因为每次操作都要处理大量数据。而小Key高QPS虽然频繁,但每次操作量小,影响相对较小。小Key高QPS影响较小的原因:大key问题

在Redis中，"大Key"问题通常指的是在数据库中存储非常大的数据结构（如大型字符串、列表、集合、哈希或有序集合）。这些大Key可能会导致一系列性能和可靠性问题。以下是一些大Key问题的主要缺点：

内存消耗高：

阻塞操作：

网络带宽消耗：

数据迁移和复制：

缓存更新和失效问题：

故障恢复：

识别大Key的方法主要有以下几种：

1. 使用 redis-cli 命令

OBJECT ENCODING 和 OBJECT IDLETIME ：

SCAN 命令：

3. 使用 Lua 脚本热key问题

在Redis中，热Key问题（Hot Key Problem）是指某些键（Key）被频繁访问，导致Redis集群中某个节点承受过大的压力，从而影响整体性能，甚至可能导致该节点的CPU过载或内存不足。热Key问题常出现在热点数据的场景中，比如某个非常流行的商品、新闻文章等被大量请求访问。

为了解决Redis中的热Key问题，可以从多个角度采取优化措施。以下是一些常见的解决方案：

1. 本地缓存（Local Cache）

又可以成为多级缓存

在应用层面引入一个本地缓存（Local Cache），例如使用Java的Guava Cache或Caffeine，可以缓解某些频繁访问的Key对Redis的压力。

// 使用Guava Cache示例
LoadingCache localCache = CacheBuilder.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .build(new CacheLoader() {
        @Override
        public String load(String key) throws Exception {
            return getValueFromRedis(key);  // 从Redis加载数据
        }
    });

2. 数据预热（Cache Warming）

在系统启动或流量高峰期前，主动将热点数据加载到缓存中，避免在流量高峰期时对Redis造成突然的访问压力。

// 数据预热示例
for (String key : hotKeys) {
    String value = getValueFromDB(key);  // 从数据库获取
    redis.set(key, value);               // 提前写入Redis
}

3. 热点Key拆分（Key Sharding）

将一个热点Key拆分成多个Key，通过增加随机性或分片来分散访问压力。

// 访问时根据随机数决定访问哪个分片
int shardId = (int) (Math.random() * 10);  // 生成0-9的随机数
String shardKey = "product_views_" + shardId;
Integer views = redis.get(shardKey);

5. 限流和降级

通过对热点Key进行限流，防止流量过大时对Redis产生过多压力令牌桶，漏桶，滑动窗口，固定窗口。在 Redis 中，热点Key问题是指某些Key被频繁访问，导致Redis承受过大的压力，进而影响性能。为了解决这个问题，可以通过限流和降级机制来控制对热点Key的访问，防止流量过大时对Redis产生过高的压力，甚至导致系统崩溃。

1. 限流（Rate Limiting）

限流即控制对某个资源的并发访问量，避免瞬时流量过大对系统造成冲击，Redis中可以通过多种方式进行限流。

常见的限流方式：a. 令牌桶算法

令牌桶是一种常见的限流算法，它通过控制令牌的产生速率来限制请求的速率。如果有令牌可用，请求就可以通过，否则请求被拒绝。

b. 漏桶算法

漏桶算法是另一种限流算法，它通过将请求放入一个“漏桶”，按固定速率处理请求，超出漏桶容量的请求将被丢弃。

c. 固定窗口计数

Redis的INCR和EXPIRE命令可以用来实现固定窗口计数限流。比如限制某个Key在1分钟内只能被访问100次。

String key = "request_count:" + userIp;
long current = redis.incr(key);
if (current == 1) {
    redis.expire(key, 60);  // 设置过期时间为60秒
}
if (current > 100) {
    // 超过限流
    return "Rate limit exceeded";
} else {
    // 正常处理请求
    return "Request processed";
}

解释：

d. 滑动窗口计数

固定窗口限流有个问题，如果流量集中在某个时间点，超出限流后，在下一个时间窗口立刻又可以处理100个请求，导致短时间内流量依然过大。滑动窗口计数是对固定窗口的改进，它通过在多个小时间片内进行计数，减少流量突发的影响。

滑动窗口计数可以通过 Redis 的 ZSET（有序集合）来实现，使用时间戳作为分数来记录请求时间，并对一定时间窗口内的请求数进行统计。

local key = KEYS[1]
local limit = tonumber(ARGV[1])
local now = tonumber(ARGV[2])
local window_time = tonumber(ARGV[3])
-- 删除窗口外的数据
redis.call('ZREMRANGEBYSCORE', key, 0, now - window_time)
local current_count = redis.call('ZCARD', key)
if current_count < limit then
    redis.call('ZADD', key, now, now)
    redis.call('EXPIRE', key, window_time)
    return 1
else
    return 0
end

解释：

2. 降级（Degradation）

当 Redis 负载过高、限流策略未能缓解足够的压力时，可以使用降级策略来保证系统的可用性。降级策略的核心思想是，当系统负载过大或出现异常时，降低系统的服务质量，保证核心功能可用。

常见的降级方式：a. 返回默认值或缓存兜底

在无法从Redis中获取热点Key的值时，可以选择返回一个默认值或从其他地方（如本地缓存）获取数据，保证系统能继续服务。

b. 降级到异步处理

对于一些非核心的操作，可以将其降级为异步处理。例如，某些数据更新操作如果不能及时完成，可以先将请求记录下来，通过后台任务异步处理，减少对Redis的依赖。

c. 部分功能关闭

在系统负载过高时，可以临时关闭一些非核心功能。例如，某些统计数据、推荐系统等服务可以暂时关闭，保证核心业务功能正常运行。