我们在开发 HTTP Server 的时候，经常有对接口内容做缓存的需求。例如，对于某些热点内容，我们希望做 1 分钟内的缓存。短期内缓存相同内容不会对业务造成实质影响，同时也会降低系统的整体负载。

有时我们需要把缓存逻辑放在 Server 内部，而非网关侧如 Nginx 等，是因为这样我们可以根据需要便捷地清除缓存，或者可以使用 Redis 等其他存储介质作为缓存后端。

这样的缓存场景无非是有缓存时从缓存取，无缓存时从下游服务取，并将数据放入缓存中。这其实是个非常通用的逻辑，应该可以将其抽象出来。从而缓存逻辑无需侵入进业务代码。

我常用的 HTTP 框架是 golang 的 gin。gin 官方就有一个 cache 组件：github.com/gin-contrib/cache，但这个 cache 组件无论在性能还是接口设计上，都有一些不足之处。

因此，我重新设计了一套 cache 中间件： gin-cache。 从压测结果来看，其性能相比于 gin-contrib/cache 明显提升。

gin-contrib/cache 的问题分析

gin-contrib/cache 是 gin 官方提供的一个 cache 组件，但这个组件在性能还是接口设计上，都并不令人满意。如下：

接口设计

1. gin-contrib/cache 对外提供的使用方式是 wrap handler 的方式，而非更加优雅和通用的 middleware。
   如:

1
2
3

cache.CachePage(store, time.Minute, func(c *gin.Context) {
c.String(200, "pong"+fmt.Sprint(time.Now().Unix()))
})

2. 用户无法根据请求自定义地生成 cache key。gin-contrib/cache 只提供了 CachePage、CachePageWithoutQuery 等函数，用户可以根据 url 作为缓存的 key。但该组件并不支持自定义 cache key。对于一些特殊场景，将无法满足需求。

性能方面

1. 该组件写入 cache 的方式是，重载了 ResponseWriter 的 Write 函数。每次在 gin 中调用 Write 函数时，都会触发一次缓存的 get 和 append 操作。这种边写边 cache 的过程，其性能显然是比较糟糕的。
2. 最糟糕的是关于并发安全的实现。由于该组件写缓存之前需要先 get 原始内容进行拼接，这个过程并非是原子的。为了保证在最 HTTP Server 基本的并发安全性，该组件在对外提供的 CachePageAtomic 接口，加了一把互斥锁来保证缓存不会写冲突, 代码如下。这把互斥锁会使得在并发越大的情况下，反而接口性能会越差。

1
2
3
4
5
6
7
8
9

func CachePageAtomic(store persistence.CacheStore, expire time.Duration, handle gin.HandlerFunc) gin.HandlerFunc {
var m sync.Mutex
p := CachePage(store, expire, handle)
return func(c *gin.Context) {
m.Lock()
defer m.Unlock()
p(c)
}
}

关于性能的这两个方面，让我着实踩了一些坑。针对于性能方面的第一项，我也对 gin-contrib/cache 提了一个 pull request。但是其他方面, 尤其是接口设计方面，让我觉得这个库或许不是最终的答案。

在踩了这个库的坑后，我决定不如实现一个新的库，可以满足我这些需求。

新的方案

在踩了 gin-contrib/cache 的坑后，gin-cache 就随之诞生。其具体实现可以看 github.com/chenyahui/gin-cache。

1
2
3
4
5
6
7
8
9

app.GET("/hello",
    cache.CacheByPath(cache.Options{
        CacheDuration: 5 * time.Second,
        CacheStore:    persist.NewMemoryStore(1 * time.Minute),
    }),
    func(c *gin.Context) {
        c.String(200, "hello world")
    },
)

1. 对外提供的形式是 Middleware 的方式
2. 用户可以根据自己需要自定义 cachekey...