groupcache 是一个分布式缓存 go 语言库，支持多节点互备热数据，有良好的稳定性和较高的并发性。
这里有个简单的应用场景：
当 GET foo 打到 groupcache-1 后：
- groupcache-1 先看看自己的 cache 里有没有 foo，有的话直接返回
- 要是没有，看看这个请求归不归自己管，若是，去 DataSever 获取，否则问 group-2(假设 foo 归 -2管) 要数据，成功返回后 groupcache-1 本地也缓存一份
- 在 2 过程中，所有后来打到 groupcache-1 的 GET foo 都会阻塞，直到第一个请求返回
问题来了，如何判断 foo 由谁来处理？
如上图，利用hash将所有节点平均打散到全集，然后当 foo 进来后用相同hash算法就会得到一个唯值，落在那个区间就属于那个节点，要保证一致性。
因为 foo 和某资源一一对应，这就要求 groupcache 只有 get 没有 update。
一个简单的HTTP groupcache Server：
package main
import "github.com/golang/groupcache"
import "github.com/gin-gonic/gin"
import "net/http"
import "time"
import "bytes"
// 虚拟文件生成方法
func generateThumbnail(fileName string) []byte {
return []byte("fake file")
}
func main() {
// 本机 ip
me := "http://10.0.0.1"
peers := groupcache.NewHTTPPool(me)
// 设置互备的 node
peers.Set("http://10.0.0.1", "http://10.0.0.2", "http://10.0.0.3")
// 创建一个 cache group，最大缓存为64M
var thumbNails = groupcache.NewGroup("thumbnail", 64<<20, groupcache.GetterFunc(
func(ctx groupcache.Context, key string, dest groupcache.Sink) error {
fileName := key
dest.SetBytes(generateThumbnail(fileName))
return nil
}))
// 设置 thumbnail 的 peers
groupcache.RegisterPeerPicker(func() groupcache.PeerPicker {
return peers
})
// 起一个 HTTP server
server := gin.Default()
server.GET("/files/:name", gin.HandlerFunc(
func(ctx *gin.Context) {
var data []byte
name := ctx.Param("name")
// 获取缓存
err := thumbNails.Get(ctx, name, groupcache.AllocatingByteSliceSink(&data))
if err != nil {
ctx.JSON(http.StatusBadRequest, gin.H{"mesage": "file not found"})
return
}
// 返回给客户端
http.ServeContent(ctx.Writer, ctx.Request, name, time.Now(), bytes.NewReader(data))
}))
server.Run("10.0.0.1:80")
}
Group
groupcache.NewGroup(addr string)
Group 代表一个 cache资源库
type Group struct {
name string
getter Getter // cache 没有命中，从数据库获取
peersOnce sync.Once
peers PeerPicker // peer 节点调度器
cacheBytes int64 // 最大cache字节数
mainCache cache // 此节点缓存
hotCache cache // 其他节点缓存
loadGroup flightGroup // 请求并发控制器
Stats Stats // 统计数据
}
对于一个 Group 来说，会缓存自己节点的数据和访问比较频繁的 peer节点 的数据，用LRU算法控制缓存。
当 cache 没有命中的时候，首先看看这个请求归不归该节点管，若是就是调用 getter：
Getter
type Getter interface {
Get(ctx Context, key string, dest Sink) error
}
对于一个 cache 来说，他不知道如何拉取需要缓存的数据，所以他说啊，你要是想缓存新的东西，就得有个 type 实现 Getter 接口，然后给我一个 Getter 对象，这样cache没有命中的时候我能靠这个对象拉取数据。
这个 Getter 类似于 http.Handler，抽象拉取要缓存的数据这个行为，Context(interface{}) 是操作的附带信息，key 请求的 id，Sink 类似于 http.ResponseWriter，抽象了数据载体的行为：
Sink
type Sink interface {
// SetString 写入 string
SetString(s string) error
// SetBytes 写入字节数组，调用者会保留 v 引用
SetBytes(v []byte) error
// SetProto 写入proto.Message，调用者会保留 m 应用
SetProto(m proto.Message) error
// ...
}
groupcache 提供了一些常用的 Sink 如 StringSink，BytesSliceSink 和 ProtoSink，这个 proto 是github.com/golang/protobuf/proto，groupcache 规定内部 peer 节点之间数据通信格式使用 google/protobuf，为了抽象 peer 节点，定义了 ProtoGetter：
ProtoGetter
type ProtoGetter interface {
Get(context Context, in *pb.GetRequest, out *pb.GetResponse) error
}
pb.GetRequest 和 pb.GetResponse 定义了请求和响应 struct，这个抽象可以分离底层传输方式。
当然还需要对节点调度器抽象，PeerPicker：
PeerPicker
type PeerPicker interface {
// PickPeer 根据 key 返回应该处理这个 key 的节点
// ok 为 true 代表找到了节点
// nil, false 代表当前节点就是 key 的处理器
PickPeer(key string) (peer ProtoGetter, ok bool)
}
调度器主要负责根据管理 key 和节点的一致性映射。
groupcache 实现了一个 HTTP 的 PeerPicker，HTTPPool。
至此，groupcache 通过 Getter，PeerPicker，ProtoGetter 三个 interface 定义了cache，节点和调度器之间的连接方式，可以有效地控制耦合度，也提供了比较大的灵活性。
