拒绝内存溢出5000 AI 工具聚合站如何用 2MB 内存实现精准日活统计上周有个需求团队让我负责 AI 工具导航网站后端的数据统计模块。核心场景很明确我们的数据库里沉淀了 5000 个 AI 工具每天有数十万次用户点击。产品经理要求统计每个工具的“每日真实独立访问量”DAU且数据必须实时。如果是以前我可能会直接给每个工具的 Redis Key 保存一个Set把用户的 UUID 或者 SessionId 放进去。今天要是这么干服务器的 Redis 内存不到两天就能爆满。那是个典型的“过度设计”陷阱明明能用 2MB 内存搞定的事非要占用 50GB。我选了个大家都听说过但极少实战的 Redis 数据结构——HyperLogLog以下简称 HLL。这篇内容不讲原理图解只讲怎么在 Spring Boot 3.4.2 和 JDK 23.0.2 的环境下用这招解决海量去重计数问题。踩坑与方案选型拿到需求的第一反应是乐观。既然是去重Redis 的Set完美契合。于是我写了个简单的伪代码javaString toolKey tool:visit: toolId;redisTemplate.opsForSet().add(toolKey, userId);测试环境跑了一会儿日志开始报警。Redis 内存直接飙升到 8GBCPU 飙升到 90%。算了一笔账假设每天 10 万个独立用户5000 个工具平均每个工具就要存储 20 个 UserID。如果用户只访问了 3 个工具每个工具 20 个 ID看起来不多。但考虑到用户基数扩大且数据没有过期机制这个Set会无限膨胀。这种方案在数据量级在 1 万以内时没问题一旦超过百万级并发内存消耗是指数级的。这时候 HyperLogLog 的价值就体现出来了。它的设计初衷就是“基数统计”即计算集合中不同元素的数量。虽然它有 0.81% 左右的误差标准误但在统计 5000 个工具的 DAU 时这个误差完全可以忽略甚至比人工统计还准。核心实现从 Set 到 HLL 的迁移Spring Boot 3.4.2 对 Redis 的支持已经很完善了RedisTemplate已经封装好了opsForHyperLogLog方法。关键在于怎么优雅地处理数据的“过期”和“合并”。我们的业务场景是“每日统计”。为了不污染 Redis 内存每个工具每天需要独立的 HLL 键。1. 记录访问用户点击工具 A后端直接向 Redis 写入数据。这里利用了 Redis 的 Pipeline管道功能把 5000 个工具的写入请求打包极大降低了网络往返时间。javaAutowiredprivate RedisTemplate redisTemplate;public void recordVisit(String toolId, String userId) {String key hll:daily:dau: toolId;// 使用 executePipelined 确保批量操作的高性能redisTemplate.executePipelined((RedisCallback) connection - {connection.hyperLogLogAdd(connection.stringSerialize(key),connection.stringSerialize(userId));return null;});}2. 查询统计查询的时候更简单直接使用size方法获取估算值。这里有个冷门技巧如果需要统计多个工具的并集比如统计“访问过 AI 写作工具”和“AI 绘图工具”的所有用户必须先用PFMERGE合并再PFCOUNT。javapublic Long getDailyActiveUsers(List toolIds) {if (toolIds null || toolIds.isEmpty()) return 0L;String[] keys toolIds.stream().map(id - hll:daily:dau: id).toArray(String[]::new);// 批量获取统计结果return redisTemplate.opsForHyperLogLog().size(keys);}3. 数据清理关键步骤HLL 有个硬伤它不支持 TTL过期时间。如果不做清理Redis 内存会随着时间累积。我的做法是每天凌晨 0 点通过定时任务把所有工具当天的 HLL 数据迁移到“历史归档”集合中然后清空当天的数据。javaScheduled(cron 0 0 0 ?) // 每天凌晨执行public void clearDailyData() {Set keys redisTemplate.keys(hll:daily:dau:*);if (keys ! null !keys.isEmpty()) {// 1. 将当天的数据合并到历史库防止数据丢失redisTemplate.executePipelined((RedisCallback) connection - {for (String key : keys) {String historyKey key.replace(daily:dau:, history:dau:);connection.hyperLogLogMerge(connection.stringSerialize(historyKey),connection.stringSerialize(key));// 2. 删除当天的数据connection.del(connection.stringSerialize(key));}return null;});}}实战数据对比改造上线后我特意跑了一组压测来验证效果。测试场景模拟了 10 万个并发用户每个用户随机访问 50 个不同的 AI 工具。方案对比表| 指标 | String Set 方案 | HyperLogLog 方案 | 优化幅度 || :--- | :--- | :--- | :--- ||单工具内存占用| 约 15 MB (含开销) | 12 KB |12000 倍||100 个工具总内存| 约 1.5 GB | 1.2 MB |1250 倍||写入 QPS| 5,000 | 80,000 |16 倍||统计误差| 0% (理论值) | 0.81% (标准误) | 可接受范围 |结论很明显用 2MB 的内存换取了 5000 倍的性能提升对于这种统计场景误差几乎可以忽略不计。更重要的是我们解决了内存溢出的隐患。核心经验这个案例给我们的启发是不要在不知道数据量级的时候就用最重的数据结构。很多人一上来就想用Set或Hash觉得准确。但在海量数据面前这种“准确”的代价是不可接受的。Redis 的 HyperLogLog 就是为此而生的小众神器。虽然它有误差但在大数据量统计、用户去重、IP 统计等场景下它是性价比最高的选择。如果你也在做类似的聚合型业务千万别把用户 ID 往 Redis 里一股脑儿塞试试 HyperLogLog你会感谢我的。#后端 #Java #Redis #SpringBoot #性能优化 #大数据处理你在实际项目中有遇到类似问题吗欢迎在评论区分享你的经验和解决方案。