BigCache

快速、并发、支持淘汰的内存缓存，专为保存大量条目而设计，不影响性能。BigCache 将条目保存在堆上，但避免了垃圾回收。为实现这一点，操作都在字节切片上进行，因此在大多数使用场景中，需要在缓存前进行条目的序列化和反序列化。

需要 Go 1.12 或更新版本。

使用方法

简单初始化

import (
	"fmt"
	"context"
	"github.com/allegro/bigcache/v3"
)

cache, _ := bigcache.New(context.Background(), bigcache.DefaultConfig(10 * time.Minute))

cache.Set("my-unique-key", []byte("value"))

entry, _ := cache.Get("my-unique-key")
fmt.Println(string(entry))

自定义初始化

当可以预先预测缓存负载时，最好使用自定义初始化，因为这样可以避免额外的内存分配。

import (
	"log"

	"github.com/allegro/bigcache/v3"
)

config := bigcache.Config {
		// 分片数量（必须是 2 的幂）
		Shards: 1024,

		// 条目可以被淘汰的时间
		LifeWindow: 10 * time.Minute,

		// 删除过期条目的时间间隔（清理）。
		// 如果设置为 <= 0，则不执行任何操作。
		// 设置为 < 1 秒会适得其反 — bigcache 的分辨率为一秒。
		CleanWindow: 5 * time.Minute,

		// rps * lifeWindow，仅用于初始内存分配
		MaxEntriesInWindow: 1000 * 10 * 60,

		// 最大条目大小（字节），仅用于初始内存分配
		MaxEntrySize: 500,

		// 打印有关额外内存分配的信息
		Verbose: true,

		// 缓存不会分配超过此限制的内存，单位为 MB
		// 如果达到此值，则最旧的条目可能会被新条目覆盖
		// 0 值表示没有大小限制
		HardMaxCacheSize: 8192,

		// 当最旧的条目因过期时间或没有空间容纳新条目而被删除时，或因调用了删除操作时触发的回调
		// 将返回一个表示原因的位掩码。
		// 默认值为 nil，表示没有回调，并且阻止解包最旧的条目。
		OnRemove: nil,

		// OnRemoveWithReason 是当最旧的条目因过期时间或没有空间容纳新条目而被删除时，或因调用了删除操作时触发的回调
		// 将传递一个表示原因的常量。
		// 默认值为 nil，表示没有回调，并且阻止解包最旧的条目。
		// 如果指定了 OnRemove，则忽略此项。
		OnRemoveWithReason: nil,
	}

cache, initErr := bigcache.New(context.Background(), config)
if initErr != nil {
	log.Fatal(initErr)
}

cache.Set("my-unique-key", []byte("value"))

if entry, err := cache.Get("my-unique-key"); err == nil {
	fmt.Println(string(entry))
}

`LifeWindow` 和 `CleanWindow`

LifeWindow 是一个时间。在此时间之后，一个条目可以被称为死亡但不会被删除。
CleanWindow 是一个时间。在此时间之后，所有死亡的条目将被删除，但仍有生命的条目不会被删除。

基准测试

比较了三种缓存：bigcache、freecache 和 map。基准测试在配备 32GB RAM 的 Ubuntu 18.04 LTS (5.2.12-050212-generic) 系统上使用 i7-6700K CPU @ 4.00GHz 进行。

基准测试源代码可以在这里找到

写入和读取

go version
go version go1.13 linux/amd64

go test -bench=. -benchmem -benchtime=4s ./... -timeout 30m goos: linux goarch: amd64 pkg: github.com/allegro/bigcache/v3/caches_bench BenchmarkMapSet-8 12999889 376 ns/op 199 B/op 3 allocs/op BenchmarkConcurrentMapSet-8 4355726 1275 ns/op 337 B/op 8 allocs/op BenchmarkFreeCacheSet-8 11068976 703 ns/op 328 B/op 2 allocs/op BenchmarkBigCacheSet-8 10183717 478 ns/op 304 B/op 2 allocs/op BenchmarkMapGet-8 16536015 324 ns/op 23 B/op 1 allocs/op BenchmarkConcurrentMapGet-8 13165708 401 ns/op 24 B/op 2 allocs/op BenchmarkFreeCacheGet-8 10137682 690 ns/op 136 B/op 2 allocs/op BenchmarkBigCacheGet-8 11423854 450 ns/op 152 B/op 4 allocs/op BenchmarkBigCacheSetParallel-8 34233472 148 ns/op 317 B/op 3 allocs/op BenchmarkFreeCacheSetParallel-8 34222654 268 ns/op 350 B/op 3 allocs/op BenchmarkConcurrentMapSetParallel-8 19635688 240 ns/op 200 B/op 6 allocs/op BenchmarkBigCacheGetParallel-8 60547064 86.1 ns/op 152 B/op 4 allocs/op BenchmarkFreeCacheGetParallel-8 50701280 147 ns/op 136 B/op 3 allocs/op BenchmarkConcurrentMapGetParallel-8 27353288 175 ns/op 24 B/op 2 allocs/op PASS ok github.com/allegro/bigcache/v3/caches_bench 256.257s

在bigcache中的写入和读取比freecache更快。对map的写入是最慢的。

GC暂停时间

go version
go version go1.13 linux/amd64

go run caches_gc_overhead_comparison.go

条目数量:  20000000
bigcache的GC暂停时间:  1.506077ms
freecache的GC暂停时间:  5.594416ms
map的GC暂停时间:  9.347015ms

go version
go version go1.13 linux/arm64

go run caches_gc_overhead_comparison.go
条目数量:  20000000
bigcache的GC暂停时间:  22.382827ms
freecache的GC暂停时间:  41.264651ms
map的GC暂停时间:  72.236853ms

测试显示了填充了2000万条目的缓存的GC暂停时间。 Bigcache和freecache的GC暂停时间非常相似。

内存使用

你可能会发现系统内存报告似乎呈指数增长，但这是预期的行为。Go运行时以块或"spans"的形式分配内存，并在不再需要时通过将其状态更改为"空闲"来通知操作系统。在操作系统需要重新利用地址之前，这些"spans"将保留为进程资源使用的一部分。更多相关阅读可以在这里找到。

工作原理

BigCache依赖于Go 1.5版本中引入的优化(issue-9477)。这个优化表明，如果使用的map的键和值中没有指针，那么GC将忽略其内容。因此，BigCache使用map[uint64]uint32，其中键是哈希值，值是条目的偏移量。

条目保存在字节切片中，再次避免GC。字节切片的大小可以增长到数十亿字节而不影响性能，因为GC只会看到指向它的单个指针。

冲突

BigCache不处理冲突。当插入新项目且其哈希值与先前存储的项目冲突时，新项目会覆盖先前存储的值。

Bigcache vs Freecache

两种缓存提供相同的核心功能，但它们以不同的方式减少GC开销。 Bigcache依赖于map[uint64]uint32，freecache实现了自己的基于切片的映射以减少指针数量。

上面展示了基准测试的结果。 bigcache相对于freecache的一个优势是，你不需要提前知道缓存的大小，因为当bigcache满了时，它可以为新条目分配额外的内存，而不是像freecache当前那样覆盖现有条目。然而，bigcache中也可以设置硬性最大大小，请查看HardMaxCacheSize。