groupcache 不是开箱即用的分布式 Redis 替代品，需显式配置节点通信、理解 singleflight 边界，且无法自动处理网络分区或节点下线；NewGroup 第三个参数 GetterFunc 有严格契约，cacheBytes 是硬上限而非建议值。
groupcache 不是开箱即用的“分布式 Redis 替代品”，它需要你显式配置节点通信、理解 singleflight 的阻塞边界，并且无法自动处理网络分区或节点永久下线——直接照抄 NewGroup 示例代码，服务一上生产就可能卡死或缓存不一致。
初始化 groupcache.Group 时必须传对三个参数
很多人只关注 NewGroup 的第一个参数（名字）和第二个（内存大小），却忽略第三个 groupcache.GetterFunc 的行为契约：
-
cacheBytes是硬上限，不是建议值：设成64 就真只用 64MB，超出部分由 LRU 自动淘汰，但不会报错或告警；设太小会导致高频 key 反复进出，降低命中率 -
GetterFunc必须是纯函数式加载逻辑：不能在里面启动 goroutine、不能阻塞等待外部信号、不能修改传入的dest以外的状态；否则singleflight合并请求时会出竞态 - 函数签名里
ctx context.Context必须被实际使用：比如传给数据库查询或 HTTP client，否则超时和取消无法传递，一个慢查询会让所有同 key 请求一起 hang 住
HTTPPool 配置错误会导致 peer-to-peer 请求永远 404
groupcache 节点间靠 HTTPPool 通信，不是自动发现。常见错误是：
- 没调用
http.ListenAndServe或监听地址与HTTPPool初始化时的 URL 不一致，比如代码里写"http://127.0.0.1:8000"，但实际服务监听在:9000，结果本地 miss 后发请求到自己却返回 404 -
HTTPPool.Set()传入的 peers 列表包含无效或已下线地址，而 groupcache 默认不健康检查，会持续重试失败节点，拖慢整体响应 - 没设置
HTTPPool.Transport的超时：默认 http.Transport 没设 timeout，peer 请求可能卡住几十秒，连带阻塞整个Get调用
正确做法是显式配置 transport：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
pool := &groupcache.HTTPPool{
BaseURL: "http://10.0.1.100:8000",
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 500 * time.Millisecond,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 500 * time.Millisecond,
ResponseHeaderTimeout: 1 * time.Second,
},
}
pool.Set([]string{"http://10.0.1.101:8000", "http://10.0.1.102:8000"})Get 调用后数据没进缓存？检查 Sink 类型和生命周期
Get 方法本身不决定数据是否落本地缓存，而是由你传入的 Sink 实现决定：
-
groupcache.AllocatingByteSliceSink(&data)：只把数据拷贝进&data指向的切片，不触发本地缓存写入 —— 它是为“只读一次、不用再查”场景设计的 - 真正写本地缓存要用
groupcache.ByteViewSink或自定义Sink实现Set方法时调用dest.SetBytes并确保该dest是当前 group 的内部缓存实例 - 如果用了
AllocatingByteSliceSink却期望下次Get命中，就会发现永远 miss：因为数据根本没进MainCache
典型误用：
var data []byte err := cacheGroup.Get(ctx, "user:123", groupcache.AllocatingByteSliceSink(&data)) // 此时 data 已有值，但 cacheGroup 本地没存这份数据
一致性哈希节点变更时，冷启动期间缓存命中率归零
groupcache 的一致性哈希基于 HTTPPool 当前 peers 列表实时计算，没有预热机制：
- 集群从 3 节点扩到 4 节点瞬间，约 25% 的 key 会被重新分配，这些 key 在新节点上全是 cold miss
- 旧节点不会主动推送已有缓存给新节点，新节点只能等第一次请求触发远程 fetch，延迟翻倍
- 如果业务对冷启动敏感（如登录接口），必须配合外部机制：比如启动时从共享存储（Redis / S3）批量 restore 热 key 的
ByteView
最容易被忽略的一点：groupcache 的 PeerPicker 接口允许你实现自定义路由逻辑，但它不解决数据迁移问题 —— 迁移得你自己做。
