Rueidis 客户端缓存一致性问题解析

背景介绍

Rueidis 是一个高性能的 Redis 客户端库，它提供了本地缓存功能以提升性能。但在实际使用中，开发者可能会遇到一些缓存一致性的问题，特别是在 SET 和 GET 操作连续执行时。

核心问题分析

本地缓存与Redis的同步延迟

由于 Redis 内部机制的变化（Redis PR#9422），现在所有的失效消息都是在命令响应之后才发送给客户端的。这意味着当执行 client.Do(ctx, client.B().Set()...) 调用时，命令会先返回，而本地缓存可能仍然保持旧状态，导致短暂的不一致。

缓存命中与Nil返回值

一个常见的误区是认为 IsCacheHit() 和 rueidis.Nil 不应该同时出现。实际上，这是完全合理的场景：

1. 当首次查询一个不存在的键时，会从Redis获取并返回Nil，同时缓存这个结果
2. 后续查询会命中本地缓存，仍然返回Nil

result1 := client.DoCache(ctx, client.B().Get().Key("nonexistent").Cache(), ttl)
result2 := client.DoCache(ctx, client.B().Get().Key("nonexistent").Cache(), ttl)
// result1.IsCacheHit() == false
// result1.Error() == rueidis.Nil
// result2.IsCacheHit() == true 
// result2.Error() == rueidis.Nil

最佳实践建议

写操作后的缓存处理

任何写操作（SET/DEL等）都会触发缓存失效，但需要等待一小段时间让失效消息传播：

// 写入操作
client.Do(ctx, client.B().Set().Key(key).Value(value).Build())

// 需要短暂等待失效完成
time.Sleep(time.Millisecond)

// 现在读取将获取最新值
result := client.DoCache(ctx, client.B().Get().Key(key).Cache(), ttl)

缓存策略选择

对于缓存封装，推荐两种模式：

1. 简单模式（容忍短暂不一致）：

val, err := client.DoCache(ctx, client.B().Get().Key(key).Cache(), ttl).ToString()
if err == rueidis.Nil {
    dbVal := fetchFromDB(key)
    client.Do(ctx, client.B().Set().Key(key).Value(dbVal).Build())
    return dbVal
}
return val, err

2. 严格模式（确保强一致）：

result := client.DoCache(ctx, client.B().Get().Key(key).Cache(), ttl)
if result.IsCacheHit() && result.Error() == rueidis.Nil {
    // 二次检查Redis
    result = client.Do(ctx, client.B().Get().Key(key).Build())
}
if result.Error() == rueidis.Nil {
    dbVal := fetchFromDB(key)
    client.Do(ctx, client.B().Set().Key(key).Value(dbVal).Build())
    return dbVal
}
return result.ToString()

性能考量

1. 对于全新键的连续SET+GET操作，不需要等待，因为本地缓存中不会有旧值
2. 在测试环境中，适当增加操作间隔可以避免竞态条件
3. 直接使用client.Do()虽然会绕过本地缓存，但性能影响通常可以接受

总结

Rueidis的本地缓存机制在提升性能的同时，也带来了缓存一致性的挑战。开发者需要根据业务场景选择合适的缓存策略，理解缓存命中与Nil返回值的关系，并在必要时添加适当的等待时间或二次检查机制来确保数据一致性。