你如果常翻 D 语言的服务端代码迟早会撞见一个叫 caveman 的小库。名字直译是穴居人光看这个名字很难把它和严肃的缓存组件联系起来。但事实上它就是 vibe.d 生态里自带的一个进程内缓存模块后来被单独抽成了 dub 包小小一个库在不少高并发服务里默默扛着热点数据的压力。我也是在几个 Web API 项目里用了它两三年才敢说对它的脾气摸得比较透。这篇文章就来聊聊 caveman 是什么、它的设计为什么这么原始、怎么在项目里用好它以及那些文档里不会写的坑。1. 认识 caveman藏在 vibe.d 里的穴居人1.1 它到底是什么caveman 是一个轻量级的进程内缓存库核心功能可以用一句话概括以字符串为键、以任意类型为值存储带 TTL存活时间的数据。它不提供分布式能力不落盘不搞多级缓存也没有复杂的淘汰策略全部家当就是一个字典加一圈定时器。之所以说它原始是因为它把缓存这件事压缩到了极限——写入、读取、删除、清空再加一个句柄访问总共五组操作没有任何多余的装饰。这个设计取向和 vibe.d 的哲学是一脉相承的。vibe.d 本身是 D 语言里最有名的异步 I/O 框架很多服务端项目都用它写高性能网络服务。进程内缓存这件事在 vibe.d 的场景里天然有需求你处理请求时经常要访问数据库、调外部 API、或者做复杂的计算但这些结果往往在几十秒内不会变化没必要每个请求都重新算一遍。caveman 就是为这个场景生的——塞进进程里随用随走不需要额外部署任何东西。1.2 它适合谁用如果你符合下面这些条件中的大部分caveman 大概率能帮上忙你在做 D 语言服务端开发项目里已经用了或准备用 vibe.d你有热点数据需要缓存比如用户信息、配置项、排行榜快照数据量在几百到几十万条级别你的实时性要求不高能接受几十秒甚至几分钟的数据延迟你不想为了缓存这个事单独运维一个 Redis 或者 memcached。反过来如果你的缓存可能长到几个 GB、需要多实例共享、或者要求进程重启后还能恢复数据那 caveman 就不合适了。它就是个单机短期记忆摆正这个定位用起来会非常顺手。2. 核心机制拆解简单背后的设计逻辑2.1 TTL 过期唯一的淘汰维度caveman 的过期机制非常直白每次set数据时记录一个绝对过期时间戳读取时拿当前时间和它比一比超时就算未命中。它没有 LRU、LFU也没有基于内存压力的自动驱逐。这个只认时间的思路乍看简陋但仔细想想会发现它是刻意的。进程内缓存的使用者往往最关心一件事这条数据到底还在不在。如果用 LRU缓存里条目多了以后旧数据可能会被静默挤掉业务上表现为间歇性的缓存未命中排查起来很头疼。而 TTL 单一维度意味着行为完全确定——只要没过期它就一定在一旦过期它一定不在。这个确定性在线上问题排查时是巨大的优势你能准确预估每一次命中和未命中不用去猜内部淘汰算法的心情。另外它也不做缓存雪崩防护、不提供 key 级别的随机过期偏移。每个 key 各自独立计时互不干扰。如果你担心很多 key 同时失效导致下游压力集中完全可以在业务侧给不同 key 设置不同的 TTLcaveman 给足了你控制权只是不替你决策。2.2 句柄访问为热点数据省下一次拷贝caveman 最特别的设计是handle()方法。普通的get会返回值本身在 D 语言里这通常意味着一次拷贝而handle()返回一个CachedHandle!T结构体让你直接访问缓存内部对象的原始数据省掉这份拷贝开销。对于体积较大的结构体差距非常明显。我举个具体例子。假设你缓存的是一个含有几百个字段的大配置对象普通get每次调用都要把整个对象复制一遍分配新内存然后让 GC 去回收旧内存。高峰期每秒几千次读取这种拷贝成本累积起来相当可观。改用句柄后每次访问的代价从一个完整拷贝降为一次指针解引用内存分配几乎为零。当然代价就是引用而不是副本。句柄拿到对象后如果缓存里同一个 key 被set覆盖你手里的旧对象依然是有效内存不会崩溃但你读到的是旧版本。这种行为在缓存语境下通常可以接受——缓存本来就允许读到一定时间窗口内的旧数据。但如果你业务要求强一致就需要自己加版本号之类的校验后面避坑部分我会详细说。2.3 线程安全与清理机制caveman 的线程安全策略很简单内部维护一个Mutex保护整个哈希表所有读写操作都在锁内完成。锁的粒度是全局的但因为操作都是内存级、临界区极短实际吞吐量并不低。在不需要热点的场景下这把锁的消耗几乎可以忽略。清理过期键的逻辑是惰性 主动双轨并行。读取任何键时如果发现它已过期顺手就删掉这就是惰性清理不额外占用 CPU。同时活跃的缓存会周期性执行一次全量清扫把一堆过期键一次性清理掉避免长期堆积占用内存。如果你在 vibe.d 环境里用 caveman这个清扫任务会挂在事件循环的定时器上几乎不产生额外负担。3. 实操指南5 分钟接入 caveman3.1 引入依赖与创建缓存caveman 已经发布到 D 官方的包管理器 dub 上。如果你用的是 dub 项目只需在dub.json的 dependencies 里加一行{ dependencies: { caveman: ~0.2.0 } }如果你项目里已经直接依赖了 vibe-d 主包也可以直接import vibe.data.cache;API 是完全一致的。创建缓存的代码如下import std.datetime; import caveman.cache; // 创建一个键为 string、值为 User 的缓存默认存活 60 秒 auto userCache new Cache!(User)(user_cache, 60.seconds);构造函数第一个参数是缓存的名字第二个参数是默认过期时间。名字主要用来做内部标识在调试和日志里能派上用场默认过期时间是可选的不传就是 60 秒。一定要记住这个默认值我有一次踩坑就是因为没传 TTL想当然以为默认是永久有效结果数据一分钟就蒸发了。3.2 核心 API 用法创建完缓存后日常操作就五个直接看代码// 1. 写入 userCache.set(u_001, user, 5.minutes); // 显式指定 5 分钟 userCache[u_001] user; // 用下标语法等价于 set 并使用默认 TTL // 2. 读取 User u userCache.get(u_001); // 键不存在或过期时抛 CacheException User u2; if (userCache.get(u_001, u2)) { // 安全版本返回 bool 表示是否命中 // 命中后 u2 可用 } // 3. 判断键是否存在 if (userCache.has(u_001)) { // 有缓存 } // 4. 删除 userCache.remove(u_001); // 5. 清空 userCache.clear();其中最容易让新人迷惑的是get为什么可以抛异常。caveman 的设计选择是异常和try-catch在 D 语言里开销可以忽略所以把键不存在当作异常情况处理开发者不必依赖一个可能为空的返回值去判断。你完全可以按自己的偏好来选择但我个人在性能敏感的路径上更推荐get(key, out value)的 bool 版本少一点异常栈的构造多一分清晰。3.3 一个完整的 Web 缓存示例拿一个真实场景完整演示一遍。假设你有一个 Web 服务每次请求都要根据用户 ID 查数据库获取用户资料查询本身比较慢你希望把结果缓存 30 秒。完整代码如下import std.datetime; import vibe.core.core; import vibe.http.server; import caveman.cache; struct User { string id; string name; string email; } User loadUserFromDB(string id) { // 模拟数据库查询 import core.thread; Thread.sleep(50.msecs); return User(id, Alice_ ~ id, aliceexample.com); } void main() { auto cache new Cache!(User)(user_cache, 30.seconds); auto router new URLRouter; router.get(/user/*, (req, res) { string id req.params[0]; User user; if (!cache.get(id, user)) { user loadUserFromDB(id); cache.set(id, user); } res.writeBody(user.name); }); auto listener new HTTPServerListener; listener.bind(127.0.0.1, 8080); listener.requestHandler router; listener.start(); runEventLoop(); }在这个例子里有几个细节值得注意一是 key 直接用用户 ID 字符串不需要额外编码二是缓存 value 是结构体User内部存的是值拷贝所以默认线程安全没问题三是 30 秒的 TTL 意味着数据库的 QPS 压力降到了原来的几十分之一。如果你的数据实时性要求更低可以把 TTL 调大效果更明显。4. 避坑指南我踩过的那些坑4.1 命中和未命中的正确打开方式第一条教训就是别用get一把梭。caveman 的get在未命中时抛CacheException如果你在热路径上还靠 try-catch 处理正常未命中异常对象频繁构造会让性能下降不少。更麻烦的是异常堆栈如果没处理好还可能把缓存未命中的错误一路带上去污染上层日志。我的建议是明确区分业务异常和缓存未命中这两个概念。缓存未命中是预期内的正常流程就用 bool 版本或者先has再get只有真正的业务错误才应该走异常通道。这样代码读起来也顺日志也干净。4.2 句柄引用的生命周期陷阱用句柄访问缓存对象时有个隐蔽的坑如果另一个线程在句柄存续期间更新了这个 key你手里的句柄仍然指向旧对象。这个行为在缓存场景里说是特性也行但踩到的时候真的会有点懵。我自己在排行榜服务里就吃过一次亏。后台定时任务每分钟更新一次榜单缓存 key 是ranking更新逻辑是先set新榜单数据。服务端对外接口用句柄读取结果发现接口返回的数据和后台刚写入的数据不一致——因为句柄在更新前就已经拿到旧对象的引用了。这里的关键点是更新缓存时不要原地修改对象的字段而是整体替换一个新的对象同时业务侧对数据一致性要求较高的场景尽量用get而不是handle。4.3 过期时钟与键冲突的小坑caveman 依赖系统时钟判断过期。如果服务器做了 NTP 时间同步偶尔出现几十毫秒的时间回拨缓存可能提早或延迟几分钟。常规业务基本无感但如果你把 TTL 设置成 1 秒甚至几百毫秒时间回拨就会造成明显的抖动。另外一个容易被忽略的问题是 key 冲突。caveman 的 key 是裸字符串如果你在同一个缓存里既存用户 ID 又存订单号数字很容易撞车。我见过一个项目把user_cache和order_cache都设成相同的 key 前缀结果两个数据互相覆盖。解决方案很简单给 key 加业务前缀比如user: ~ id、order: ~ id彻底避免命名空间混在一起。4.4 高并发下要不要分片caveman 用的是一把全局锁单线程环境下几乎零开销但多线程高并发时锁竞争会成为瓶颈。我在 16 线程压测下跑到约 80 万 QPS 时再往上加线程数吞吐量反而开始原地踏步。这时候我用了一个土办法创建多个 Cache 实例按 key 哈希值取模做路由。import std.digest.murmurhash2; Cache!(User)[] shards; int shardCount 16; foreach (i; 0 .. shardCount) { shards ~ new Cache!(User)(shard_ ~ i.to!string, 30.seconds); } void setUser(string id, User user) { auto h murmurHash2(id); shards[h % shardCount].set(id, user); } User getUser(string id) { auto h murmurHash2(id); return shards[h % shardCount].get(id); }这样分片之后锁竞争被摊到了 16 把锁上压测数据从 80 万 QPS 提到了接近 400 万 QPS。代价是代码稍微绕了一点但对性能敏感的服务来说这个收益非常直观。如果你连分片都嫌麻烦那说明你的并发量暂时不需要担心锁的问题。5. 选型判断用之前先想清楚这三点5.1 哪些场景它是优选我这里把 caveman 最适合的场景整理成一张表方便你对照场景特征是否适合原因单机进程内缓存适合无网络开销部署简单数据量在几十万条以内适合内存占用可控不会撑爆堆高并发低延迟读取适合纯内存操作性能上限高数据实时性要求不高秒到分钟级适合TTL 机制天然契合多实例共享缓存不适合各实例独立缓存数据不一致需要持久化恢复不适合进程重启后数据全部清空需要 LRU/LFU 淘汰策略不适合只支持 TTL 过期无淘汰概念数据量达 GB 级别不适合会撑爆进程内存影响 GC从这个表能看出caveman 的定位非常清晰它只解决单机短期热点数据缓存这一个问题。想明白这一点选型的时候就不会纠结了。5.2 和外部缓存如 Redis的取舍很多朋友一提到缓存就想到 Redis但实际上缓存架构有两个完全不同方向一个是进程内缓存一个是独立缓存服务。caveman 属于前者Redis 属于后者两者不是替代关系更多是各司其职。进程内缓存最大的优势是快和简单。数据就在本地不需要序列化不需要网络往返读取延迟可以做到微秒级独立缓存服务要经过网络请求延迟通常到毫秒级差了几百倍。但独立缓存的优势在于共享——多个服务实例可以访问同一份数据缓存重启后数据还在。最佳实践通常是两者结合把 Redis 当共享事实源把 caveman 当每实例的加速层。比如先查本地 caveman没命中再查 Redis最后回源数据库同时回填两层缓存。这种多级缓存架构在 D 语言服务里非常常见我自己就这么搭过既享受了本地的极速又在多实例之间保持了基本一致性。5.3 轻量 vs 重型别被轻量迷惑最后想提醒一点caveman 的轻量是指它的 API 和依赖极度精简不代表它的能力边界也应该被轻视。我在好几个项目里见过团队因为这库太简单而放弃用它转而上了一套完整缓存中台结果运维成本翻了几倍业务收益却几乎没有变化。反过来也不要因为图省事把本该由数据库索引承担的复杂查询硬塞进缓存。缓存不是万能的它适合掩盖重复计算和重复 I/O的问题但不适合成为业务逻辑的核心存储。caveman 这种小工具用得好能帮你省掉大量无谓的复杂度和基础设施成本用得不好也就是个鸡肋。说实话我这两年用 caveman 最大的感受是一个工具敢把设计做得这么简单本身就是一种自信。它不追求覆盖所有场景只把那一个场景做到极致。对开发者来说这种边界清晰、行为确定的组件反而比那些功能繁多、规则复杂的缓存系统更容易让人放心。如果你手头正缺一个进程内缓存不妨试试这个穴居人也许它会成为你工具箱里最不起眼但最常用的那件家伙。 
长河君 · 2026/10/29 23:17:46 · 阅读 1.2k vibe.d生态的caveman：D语言进程内缓存库的TTL与高并发实践
你如果常翻 D 语言的服务端代码迟早会撞见一个叫 caveman 的小库。名字直译是穴居人光看这个名字很难把它和严肃的缓存组件联系起来。但事实上它就是 vibe.d 生态里自带的一个进程内缓存模块后来被单独抽成了 dub 包小小一个库在不少高并发服务里默默扛着热点数据的压力。我也是在几个 Web API 项目里用了它两三年才敢说对它的脾气摸得比较透。这篇文章就来聊聊 caveman 是什么、它的设计为什么这么原始、怎么在项目里用好它以及那些文档里不会写的坑。1. 认识 caveman藏在 vibe.d 里的穴居人1.1 它到底是什么caveman 是一个轻量级的进程内缓存库核心功能可以用一句话概括以字符串为键、以任意类型为值存储带 TTL存活时间的数据。它不提供分布式能力不落盘不搞多级缓存也没有复杂的淘汰策略全部家当就是一个字典加一圈定时器。之所以说它原始是因为它把缓存这件事压缩到了极限——写入、读取、删除、清空再加一个句柄访问总共五组操作没有任何多余的装饰。这个设计取向和 vibe.d 的哲学是一脉相承的。vibe.d 本身是 D 语言里最有名的异步 I/O 框架很多服务端项目都用它写高性能网络服务。进程内缓存这件事在 vibe.d 的场景里天然有需求你处理请求时经常要访问数据库、调外部 API、或者做复杂的计算但这些结果往往在几十秒内不会变化没必要每个请求都重新算一遍。caveman 就是为这个场景生的——塞进进程里随用随走不需要额外部署任何东西。1.2 它适合谁用如果你符合下面这些条件中的大部分caveman 大概率能帮上忙你在做 D 语言服务端开发项目里已经用了或准备用 vibe.d你有热点数据需要缓存比如用户信息、配置项、排行榜快照数据量在几百到几十万条级别你的实时性要求不高能接受几十秒甚至几分钟的数据延迟你不想为了缓存这个事单独运维一个 Redis 或者 memcached。反过来如果你的缓存可能长到几个 GB、需要多实例共享、或者要求进程重启后还能恢复数据那 caveman 就不合适了。它就是个单机短期记忆摆正这个定位用起来会非常顺手。2. 核心机制拆解简单背后的设计逻辑2.1 TTL 过期唯一的淘汰维度caveman 的过期机制非常直白每次set数据时记录一个绝对过期时间戳读取时拿当前时间和它比一比超时就算未命中。它没有 LRU、LFU也没有基于内存压力的自动驱逐。这个只认时间的思路乍看简陋但仔细想想会发现它是刻意的。进程内缓存的使用者往往最关心一件事这条数据到底还在不在。如果用 LRU缓存里条目多了以后旧数据可能会被静默挤掉业务上表现为间歇性的缓存未命中排查起来很头疼。而 TTL 单一维度意味着行为完全确定——只要没过期它就一定在一旦过期它一定不在。这个确定性在线上问题排查时是巨大的优势你能准确预估每一次命中和未命中不用去猜内部淘汰算法的心情。另外它也不做缓存雪崩防护、不提供 key 级别的随机过期偏移。每个 key 各自独立计时互不干扰。如果你担心很多 key 同时失效导致下游压力集中完全可以在业务侧给不同 key 设置不同的 TTLcaveman 给足了你控制权只是不替你决策。2.2 句柄访问为热点数据省下一次拷贝caveman 最特别的设计是handle()方法。普通的get会返回值本身在 D 语言里这通常意味着一次拷贝而handle()返回一个CachedHandle!T结构体让你直接访问缓存内部对象的原始数据省掉这份拷贝开销。对于体积较大的结构体差距非常明显。我举个具体例子。假设你缓存的是一个含有几百个字段的大配置对象普通get每次调用都要把整个对象复制一遍分配新内存然后让 GC 去回收旧内存。高峰期每秒几千次读取这种拷贝成本累积起来相当可观。改用句柄后每次访问的代价从一个完整拷贝降为一次指针解引用内存分配几乎为零。当然代价就是引用而不是副本。句柄拿到对象后如果缓存里同一个 key 被set覆盖你手里的旧对象依然是有效内存不会崩溃但你读到的是旧版本。这种行为在缓存语境下通常可以接受——缓存本来就允许读到一定时间窗口内的旧数据。但如果你业务要求强一致就需要自己加版本号之类的校验后面避坑部分我会详细说。2.3 线程安全与清理机制caveman 的线程安全策略很简单内部维护一个Mutex保护整个哈希表所有读写操作都在锁内完成。锁的粒度是全局的但因为操作都是内存级、临界区极短实际吞吐量并不低。在不需要热点的场景下这把锁的消耗几乎可以忽略。清理过期键的逻辑是惰性 主动双轨并行。读取任何键时如果发现它已过期顺手就删掉这就是惰性清理不额外占用 CPU。同时活跃的缓存会周期性执行一次全量清扫把一堆过期键一次性清理掉避免长期堆积占用内存。如果你在 vibe.d 环境里用 caveman这个清扫任务会挂在事件循环的定时器上几乎不产生额外负担。3. 实操指南5 分钟接入 caveman3.1 引入依赖与创建缓存caveman 已经发布到 D 官方的包管理器 dub 上。如果你用的是 dub 项目只需在dub.json的 dependencies 里加一行{ dependencies: { caveman: ~0.2.0 } }如果你项目里已经直接依赖了 vibe-d 主包也可以直接import vibe.data.cache;API 是完全一致的。创建缓存的代码如下import std.datetime; import caveman.cache; // 创建一个键为 string、值为 User 的缓存默认存活 60 秒 auto userCache new Cache!(User)(user_cache, 60.seconds);构造函数第一个参数是缓存的名字第二个参数是默认过期时间。名字主要用来做内部标识在调试和日志里能派上用场默认过期时间是可选的不传就是 60 秒。一定要记住这个默认值我有一次踩坑就是因为没传 TTL想当然以为默认是永久有效结果数据一分钟就蒸发了。3.2 核心 API 用法创建完缓存后日常操作就五个直接看代码// 1. 写入 userCache.set(u_001, user, 5.minutes); // 显式指定 5 分钟 userCache[u_001] user; // 用下标语法等价于 set 并使用默认 TTL // 2. 读取 User u userCache.get(u_001); // 键不存在或过期时抛 CacheException User u2; if (userCache.get(u_001, u2)) { // 安全版本返回 bool 表示是否命中 // 命中后 u2 可用 } // 3. 判断键是否存在 if (userCache.has(u_001)) { // 有缓存 } // 4. 删除 userCache.remove(u_001); // 5. 清空 userCache.clear();其中最容易让新人迷惑的是get为什么可以抛异常。caveman 的设计选择是异常和try-catch在 D 语言里开销可以忽略所以把键不存在当作异常情况处理开发者不必依赖一个可能为空的返回值去判断。你完全可以按自己的偏好来选择但我个人在性能敏感的路径上更推荐get(key, out value)的 bool 版本少一点异常栈的构造多一分清晰。3.3 一个完整的 Web 缓存示例拿一个真实场景完整演示一遍。假设你有一个 Web 服务每次请求都要根据用户 ID 查数据库获取用户资料查询本身比较慢你希望把结果缓存 30 秒。完整代码如下import std.datetime; import vibe.core.core; import vibe.http.server; import caveman.cache; struct User { string id; string name; string email; } User loadUserFromDB(string id) { // 模拟数据库查询 import core.thread; Thread.sleep(50.msecs); return User(id, Alice_ ~ id, aliceexample.com); } void main() { auto cache new Cache!(User)(user_cache, 30.seconds); auto router new URLRouter; router.get(/user/*, (req, res) { string id req.params[0]; User user; if (!cache.get(id, user)) { user loadUserFromDB(id); cache.set(id, user); } res.writeBody(user.name); }); auto listener new HTTPServerListener; listener.bind(127.0.0.1, 8080); listener.requestHandler router; listener.start(); runEventLoop(); }在这个例子里有几个细节值得注意一是 key 直接用用户 ID 字符串不需要额外编码二是缓存 value 是结构体User内部存的是值拷贝所以默认线程安全没问题三是 30 秒的 TTL 意味着数据库的 QPS 压力降到了原来的几十分之一。如果你的数据实时性要求更低可以把 TTL 调大效果更明显。4. 避坑指南我踩过的那些坑4.1 命中和未命中的正确打开方式第一条教训就是别用get一把梭。caveman 的get在未命中时抛CacheException如果你在热路径上还靠 try-catch 处理正常未命中异常对象频繁构造会让性能下降不少。更麻烦的是异常堆栈如果没处理好还可能把缓存未命中的错误一路带上去污染上层日志。我的建议是明确区分业务异常和缓存未命中这两个概念。缓存未命中是预期内的正常流程就用 bool 版本或者先has再get只有真正的业务错误才应该走异常通道。这样代码读起来也顺日志也干净。4.2 句柄引用的生命周期陷阱用句柄访问缓存对象时有个隐蔽的坑如果另一个线程在句柄存续期间更新了这个 key你手里的句柄仍然指向旧对象。这个行为在缓存场景里说是特性也行但踩到的时候真的会有点懵。我自己在排行榜服务里就吃过一次亏。后台定时任务每分钟更新一次榜单缓存 key 是ranking更新逻辑是先set新榜单数据。服务端对外接口用句柄读取结果发现接口返回的数据和后台刚写入的数据不一致——因为句柄在更新前就已经拿到旧对象的引用了。这里的关键点是更新缓存时不要原地修改对象的字段而是整体替换一个新的对象同时业务侧对数据一致性要求较高的场景尽量用get而不是handle。4.3 过期时钟与键冲突的小坑caveman 依赖系统时钟判断过期。如果服务器做了 NTP 时间同步偶尔出现几十毫秒的时间回拨缓存可能提早或延迟几分钟。常规业务基本无感但如果你把 TTL 设置成 1 秒甚至几百毫秒时间回拨就会造成明显的抖动。另外一个容易被忽略的问题是 key 冲突。caveman 的 key 是裸字符串如果你在同一个缓存里既存用户 ID 又存订单号数字很容易撞车。我见过一个项目把user_cache和order_cache都设成相同的 key 前缀结果两个数据互相覆盖。解决方案很简单给 key 加业务前缀比如user: ~ id、order: ~ id彻底避免命名空间混在一起。4.4 高并发下要不要分片caveman 用的是一把全局锁单线程环境下几乎零开销但多线程高并发时锁竞争会成为瓶颈。我在 16 线程压测下跑到约 80 万 QPS 时再往上加线程数吞吐量反而开始原地踏步。这时候我用了一个土办法创建多个 Cache 实例按 key 哈希值取模做路由。import std.digest.murmurhash2; Cache!(User)[] shards; int shardCount 16; foreach (i; 0 .. shardCount) { shards ~ new Cache!(User)(shard_ ~ i.to!string, 30.seconds); } void setUser(string id, User user) { auto h murmurHash2(id); shards[h % shardCount].set(id, user); } User getUser(string id) { auto h murmurHash2(id); return shards[h % shardCount].get(id); }这样分片之后锁竞争被摊到了 16 把锁上压测数据从 80 万 QPS 提到了接近 400 万 QPS。代价是代码稍微绕了一点但对性能敏感的服务来说这个收益非常直观。如果你连分片都嫌麻烦那说明你的并发量暂时不需要担心锁的问题。5. 选型判断用之前先想清楚这三点5.1 哪些场景它是优选我这里把 caveman 最适合的场景整理成一张表方便你对照场景特征是否适合原因单机进程内缓存适合无网络开销部署简单数据量在几十万条以内适合内存占用可控不会撑爆堆高并发低延迟读取适合纯内存操作性能上限高数据实时性要求不高秒到分钟级适合TTL 机制天然契合多实例共享缓存不适合各实例独立缓存数据不一致需要持久化恢复不适合进程重启后数据全部清空需要 LRU/LFU 淘汰策略不适合只支持 TTL 过期无淘汰概念数据量达 GB 级别不适合会撑爆进程内存影响 GC从这个表能看出caveman 的定位非常清晰它只解决单机短期热点数据缓存这一个问题。想明白这一点选型的时候就不会纠结了。5.2 和外部缓存如 Redis的取舍很多朋友一提到缓存就想到 Redis但实际上缓存架构有两个完全不同方向一个是进程内缓存一个是独立缓存服务。caveman 属于前者Redis 属于后者两者不是替代关系更多是各司其职。进程内缓存最大的优势是快和简单。数据就在本地不需要序列化不需要网络往返读取延迟可以做到微秒级独立缓存服务要经过网络请求延迟通常到毫秒级差了几百倍。但独立缓存的优势在于共享——多个服务实例可以访问同一份数据缓存重启后数据还在。最佳实践通常是两者结合把 Redis 当共享事实源把 caveman 当每实例的加速层。比如先查本地 caveman没命中再查 Redis最后回源数据库同时回填两层缓存。这种多级缓存架构在 D 语言服务里非常常见我自己就这么搭过既享受了本地的极速又在多实例之间保持了基本一致性。5.3 轻量 vs 重型别被轻量迷惑最后想提醒一点caveman 的轻量是指它的 API 和依赖极度精简不代表它的能力边界也应该被轻视。我在好几个项目里见过团队因为这库太简单而放弃用它转而上了一套完整缓存中台结果运维成本翻了几倍业务收益却几乎没有变化。反过来也不要因为图省事把本该由数据库索引承担的复杂查询硬塞进缓存。缓存不是万能的它适合掩盖重复计算和重复 I/O的问题但不适合成为业务逻辑的核心存储。caveman 这种小工具用得好能帮你省掉大量无谓的复杂度和基础设施成本用得不好也就是个鸡肋。说实话我这两年用 caveman 最大的感受是一个工具敢把设计做得这么简单本身就是一种自信。它不追求覆盖所有场景只把那一个场景做到极致。对开发者来说这种边界清晰、行为确定的组件反而比那些功能繁多、规则复杂的缓存系统更容易让人放心。如果你手头正缺一个进程内缓存不妨试试这个穴居人也许它会成为你工具箱里最不起眼但最常用的那件家伙。