编程沉思录

剖析Golang Bigcache的极致性能优化

发表于 2023-11-25 更新于 2025-08-20 阅读次数： Disqus：

Bigcache是用Golang实现的本地内存缓存的开源库，主打的就是可缓存数据量大，查询速度快。 在其官方的介绍文章《Writing a very fast cache service with millions of entries in Go》一文中，明确提出了bigcache的设计目标：

目前有许多开源的cache库，大部分都是基于map实现的，例如go-cache,ttl-cache等。bigcache明确指出，当数据量巨大时，直接基于map实现的cache库将出现严重的性能问题，这也是他们设计了一个全新的cache库的原因。

本文将通过分析bigcache v3.1.0的源码，揭秘bigcache如何解决现有map库的性能缺陷，以极致的性能优化，实现超高性能的缓存库。

发表于 2023-11-23 更新于 2025-08-20 阅读次数： Disqus：

最近发现 Golang 标准库竟然自带了 varint 的实现，代码位置在 encoding/binary/varint.go，这个跟protobuf里面的varint实现基本是一致的。刚好借助 golang 标准库的 varint 源码，我们来系统地学习和梳理下 varint。

熟悉 protobuf 的人肯定对 varint 不陌生，protobuf 里面除了带 fix (如 fixed32、fixed64) 之外的整数类型, 都是 varint 编码。

varint 的出现主要是为了解决两个问题：

空间效率：以 uint64 类型为例，可以表示的最大值为 18446744073709551615。然而在实际业务场景中，我们通常处理的整数值远小于 uint64 的最大值。假设在我们的业务中，需要处理的整数值仅为 1，但在网络传输过程中，我们却需要使用 8 个字节来表示这个值。这就导致了大量的空间浪费，因为大部分字节并没有实际存储有效的信息。varint 编码通过使用可变长度的字节序列来表示整数，使得小的整数可以用更少的字节表示，提高空间效率。
兼容性：varint 使得我们可以在不改变编码 / 解码逻辑的情况下，处理不同大小的整数。这意味着我们可以在不破坏向后兼容性的情况下，将一个字段从较小的整数类型（如 uint32）升级到较大的整数类型（如 uint64）

本文将通过分析 Golang 标准库自带的 varint 源码实现，介绍 varint 的设计原理以及Golang标准库是如何解决 varint 在编码负数时遇到的问题。

发表于 2021-07-18 更新于 2025-08-20 阅读次数： Disqus：

sync.Pool 是 Golang 内置的对象池技术，可用于缓存临时对象，以缓解因频繁建立临时对象带来的性能损耗以及对 GC 带来的压力。

在许多知名的开源库中都可以看到 sync.Pool 的大量使用。例如，HTTP 框架 Gin 用 sync.Pool 来复用每个请求都会创建的 gin.Context 对象。在 grpc-Go、kubernetes 等也都可以看到对 sync.Pool 的身影。

但需要注意的是，sync.Pool 缓存的对象随时可能被无通知的清除，因此不能将 sync.Pool 用于存储持久对象的场景。

sync.Pool 作为 goroutine 内置的官方库，其设计非常精妙。sync.Pool 不仅是并发安全的，而且实现了 lock free，里面有许多值得学习的知识点。

本文将基于 go-1.16 的源码对 sync.Pool 的底层实现一探究竟。

发表于 2021-06-20 更新于 2025-08-20 阅读次数： Disqus：

问题是这样的：我在代码里面调用了 os.Chmod("test.txt", 777)，希望把该文件的读写及执行权限对所有用户开放。
执行完代码，顺手 ls 看了下。如下：

1 2	$ ls -l test.txt -r----x--x 1 cyhone 1085706827 0 Jun 20 13:27 test.txt

结果出乎意料，不仅文件权限没有按预期的变成 rwxrwxrwx。反而执行完后，当前用户就只剩可读权限了，其他用户就只有可执行权限同时无读写权限。

因为这实在是一个简单又愚蠢的错误，所以先直接给出结论:

这个问题虽然非常简单，但尴尬的是我还踩了坑，所以把这个问题及原因分享出来。

发表于 2021-06-14 更新于 2025-08-20 阅读次数： Disqus：

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

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

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

cache

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

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

发表于 2021-03-18 更新于 2025-08-20 阅读次数： Disqus：

「优雅终止」指的是当服务需要下线或者重启时，通过一些措施和手段，一方面能够让其他服务尽快的感知到当前服务的下线，另一方面也尽量减小对当前正在处理请求的影响。优雅终止可提升服务的高可用，减少下线造成的服务抖动，提升服务稳定性和用户体验。

下线服务不仅仅是运维层面的工作，需要整个 RPC 实现、服务架构以及运维体系的配合，才能完美的实现服务的优雅下线。本文将基于服务下线的整个流程，分析如何实现微服务的优雅终止。主要包含以下方面：