groupcache 架构设计

groupcache 是一个分布式缓存 go 语言库,支持多节点互备热数据,有良好的稳定性和较高的并发性。

这里有个简单的应用场景:

groupcache.png

当 GET foo 打到 groupcache-1 后:

groupcache-1 先看看自己的 cache 里有没有 foo,有的话直接返回

要是没有,看看这个请求归不归自己管,若是,去 DataSever 获取,否则问 group-2(假设 foo 归 -2管) 要数据,成功返回后 groupcache-1 本地也缓存一份

在 2 过程中,所有后来打到 groupcache-1 的 GET foo 都会阻塞,直到第一个请求返回

问题来了,如何判断 foo 由谁来处理?

consistenthash.png

如上图,利用hash将所有节点平均打散到全集,然后当 foo 进来后用相同hash算法就会得到一个唯值,落在那个区间就属于那个节点,要保证一致性。

因为 foo 和某资源一一对应,这就要求 groupcache 只有 get 没有 update。

一个简单的HTTP groupcache Server:

packagemainimport"github.com/golang/groupcache"import"github.com/gin-gonic/gin"import"net/http"import"time"import"bytes"// 虚拟文件生成方法funcgenerateThumbnail(fileNamestring)[]byte{return[]byte("fake file")}funcmain(){// 本机 ipme :="http://10.0.0.1"peers := groupcache.NewHTTPPool(me)// 设置互备的 nodepeers.Set("http://10.0.0.1","http://10.0.0.2","http://10.0.0.3")// 创建一个 cache group,最大缓存为64MvarthumbNails = groupcache.NewGroup("thumbnail",64<<20, groupcache.GetterFunc(func(ctx groupcache.Context, keystring, dest groupcache.Sink)error{            fileName := key            dest.SetBytes(generateThumbnail(fileName))returnnil}))// 设置 thumbnail 的 peersgroupcache.RegisterPeerPicker(func()groupcache.PeerPicker{returnpeers    })// 起一个 HTTP serverserver := gin.Default()    server.GET("/files/:name", gin.HandlerFunc(func(ctx *gin.Context){vardata []bytename := ctx.Param("name")// 获取缓存err := thumbNails.Get(ctx, name, groupcache.AllocatingByteSliceSink(&data))iferr !=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资源库

typeGroupstruct{    namestringgetter    Getter// cache 没有命中,从数据库获取peersOnce  sync.Once    peers      PeerPicker// peer 节点调度器cacheBytesint64// 最大cache字节数mainCache cache// 此节点缓存hotCache cache// 其他节点缓存loadGroup flightGroup// 请求并发控制器Stats Stats// 统计数据}

对于一个 Group 来说,会缓存自己节点的数据和访问比较频繁的 peer节点 的数据,用LRU算法控制缓存。

当 cache 没有命中的时候,首先看看这个请求归不归该节点管,若是就是调用 getter:

Getter

typeGetterinterface{    Get(ctx Context, keystring, dest Sink) error}

对于一个 cache 来说,他不知道如何拉取需要缓存的数据,所以他说啊,你要是想缓存新的东西,就得有个 type 实现 Getter 接口,然后给我一个 Getter 对象,这样cache没有命中的时候我能靠这个对象拉取数据。

这个 Getter 类似于 http.Handler,抽象拉取要缓存的数据这个行为,Context(interface{}) 是操作的附带信息,key 请求的 id,Sink 类似于 http.ResponseWriter,抽象了数据载体的行为:

Sink

typeSinkinterface{// SetString 写入 stringSetString(sstring) 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

typeProtoGetterinterface{    Get(context Context, in *pb.GetRequest, out *pb.GetResponse) error}

pb.GetRequest和pb.GetResponse定义了请求和响应 struct,这个抽象可以分离底层传输方式。

当然还需要对节点调度器抽象,PeerPicker:

PeerPicker

typePeerPickerinterface{// PickPeer 根据 key 返回应该处理这个 key 的节点// ok 为 true 代表找到了节点// nil, false 代表当前节点就是 key 的处理器PickPeer(keystring) (peer ProtoGetter, okbool)}

调度器主要负责根据管理 key 和节点的一致性映射。

groupcache 实现了一个 HTTP 的 PeerPicker,HTTPPool。

至此,groupcache 通过 Getter,PeerPicker,ProtoGetter 三个 interface 定义了cache,节点和调度器之间的连接方式,可以有效地控制耦合度,也提供了比较大的灵活性。

作者:王谙然

链接:https://www.jianshu.com/p/f69f3a3a9a78

來源:

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

你可能感兴趣的:(groupcache 架构设计)