Redis性能瓶颈深度分析

一、Redis性能模型与瓶颈定位

Redis是单线程（6.0前）的事件循环模型，基于I/O多路复用（epoll/select/kqueue）。理解这个模型是分析瓶颈的前提：

// Redis 6.0 单线程事件处理模型
// 每次主循环（aeMain）：
// 1. aeApiPoll(timeout) — I/O多路复用，等待就绪事件（epoll_wait）
// 2. beforeSleep() — 处理AOF刷盘、客户端超时、统计等
// 3. processEvents() — 处理已就绪的事件（socket可读/可写）
// 4. afterSleep() — 后处理

// 单线程瓶颈的三大来源：
// 1. CPU密集型命令：KEYS, SMEMBERS, SORT, UNION, LREM 等 — O(N)复杂度
// 2. 大Key操作：HGETALL/SMEMBERS/MGET 传输大量数据
// 3. 持久化阻塞：AOF fsync/BGSAVE fork() 时的COW（Copy-On-Write）

// redis-cli --latency 基准测试（延迟基准）
// $ redis-cli --latency-history -i 1
// avg: 0.057ms (min: 0.02, max: 0.15) — 正常延迟

// 基准测试工具
// redis-benchmark -n 100000 -c 100 -t SET,GET
// 关键指标：QPS、延迟分布（P50/P99/P999）

// slowlog：慢查询日志（超过slowlog-log-slower-than微秒的命令）
CONFIG SET slowlog-log-slower-than 1000   // 超过1ms记录
CONFIG SET slowlog-max-len 128
SLOWLOG GET 10  // 查看最近10条慢查询

1.1 六大经典瓶颈场景

• BigKey：单个Key数据量过大，阻塞主线程
• HotKey：某个Key被高频访问，单线程成为瓶颈
• 内存碎片：jemalloc分配器碎片化导致可用内存不足
• 持久化阻塞：BGSAVE/AOF重写 fork() 期间内存膨胀
• 网络带宽：大Value导致网络IO成为瓶颈
• CPU绑定：持久化子进程与主进程竞争CPU

二、BigKey问题诊断与解决

// BigKey诊断：使用SCAN替代KEYS（全量扫描不阻塞）
redis-cli --bigkeys                    // 扫描各类最大Key
redis-cli --scan | head -10000 | redis-cli --pipe-timeout 3 --pipe \
  "$(redis-cli SCAN 0 COUNT 10000 | awk '{print "MEMORY USAGE "$1}')"

# Python脚本：找出所有BigKey
import redis
r = redis.Redis(host='localhost', port=6379)
for key in r.scan_iter(match='*', count=1000):
    t = r.type(key).decode()
    if t == 'string':
        size = r.memory_usage(key)
        if size and size > 1024*1024: # >1MB
            print(f"BIG STRING: {key} = {size//1024//1024}MB")
    elif t in ('list','set','zset','hash'):
        count = r_llen(key) if t=='list' else r_scard(key)
        if count > 10000:
            print(f"BIG {t}: {key} = {count} items")

// BigKey删除：分批渐进式删除（避免阻塞）
# 删除大Hash：先获取field数量，再分批HDEL
let size = redis.call('HLEN', KEYS[1])
let batch = 1000
for i = 1, size, batch do
    local fields = redis.call('HKEYS', KEYS[1], i, math.min(i+batch-1, size))
    for _, field in ipairs(fields) do
        redis.call('HDEL', KEYS[1], field)
    end
    redis.call('LCSLEEP', 50) -- 每次删除后休息50ms
end

# Lua脚本：渐进式删除Hash
EVAL "
local keys = redis.call('HKEYS', KEYS[1])
local batch = 1000
for i = 1, #keys, batch do
    local fields = {}
    for j = i, math.min(i+batch-1, #keys) do
        table.insert(fields, keys[j])
    end
    redis.call('HDEL', KEYS[1], unpack(fields))
    redis.call('LCSLEEP', 50)
end
redis.call('DEL', KEYS[1])
" 1 my_big_hash

// BigKey预防策略
# 1. 将大Hash按field数量拆分
user:1000:profile → user:1000:profile:base, user:1000:profile:extend
# 2. 用SortedSet替代List存储需要按序访问的数据
# 3. 设置TTL防止无限增长

2.1 HotKey问题：单机热点探测与分布式解决

// HotKey探测（客户端代理层）
# 阿里云Redis/腾讯云Redis提供热点Key分析接口
redis-cli HOTKEYS 100          // redis-cli 4.0+，采样100个Key

# 客户端本地计数
private ConcurrentHashMap hotKeyCounter = new ConcurrentHashMap<>();

public String get(String key) {
    hotKeyCounter.computeIfAbsent(key, k -> new AtomicLong()).incrementAndGet();
    return redisTemplate.opsForValue().get(key);
}

// 定时上报并清理
@Scheduled(fixedRate = 60000)
public void reportHotKeys() {
    hotKeyCounter.entrySet().stream()
        .filter(e -> e.getValue().get() > 10000)
        .forEach(e -> {
            log.warn("HOT KEY DETECTED: {} count={}", e.getKey(), e.getValue().get());
            e.getValue().set(0);
        });
}

// HotKey解决方案：本地缓存 + Redis + 多副本分流
# Redis Cluster：给热点Key创建多个副本
redis-cli CLUSTER SETSLOT 0 NODE   // 迁移Slot

# 客户端：本地LRU缓存 + Redis + 一致性hash
LoadingCache localCache = Caffeine.newBuilder()
    .maximumSize(10000)
    .expireAfterWrite(1, TimeUnit.MINUTES)
    .build(key -> redis.get(key)); // Cache Aside

三、Pipeline与Lua脚本优化

// 普通模式：N次命令 = N次RTT（Round Trip Time）
for (String key : keys) {
    redisTemplate.opsForValue().get(key); // 每次命令一次网络往返
}
// 10个key × 1ms RTT = 10ms

// ✅ Pipeline模式：N次命令 = 1次RTT
RedisCallback> pipelineCallback = connection -> {
    connection.openPipeline();
    for (String key : keys) {
        connection.get(key.getBytes());
    }
    return connection.closePipeline();
};
List