你有没有算过一笔账：1 亿用户每天签到，如果每个状态一个普通 Key，Redis 内存会爆成什么样？

我是老李，最近在帮一个团队做 Redis 成本优化。他们业务里有三件事：用户签到、网站 UV 统计、附近门店推荐。代码里清一色用 String 存签到、用 Set 装 UV、用 MySQL 算经纬度距离。功能没问题，但数据量一上来，内存和延迟曲线就很难看。

这三个场景其实都有对应的 Redis 专用数据结构：Bitmap、HyperLogLog、Geo。它们不是新东西，但很多同学只记住了 Redis 五大基础类型，没把这些“进阶结构”用在刀刃上。今天这篇文章，我想把原理、选型和 Spring Boot 落地代码一次说清楚。

## 01、痛点

先看三个典型场景的朴素实现，以及它们带来的成本。

第一个场景：用户签到。假设产品要支持 30 天签到，用户量 1 亿。最简单的做法是每个用户每天一个 Key，比如 `sign:10001:20240601`，value 存 1 或 0。这样一个用户一天一个 Key，1 亿用户每天就是 1 亿个 Key。Redis 里一个 Key 本身有元数据开销，包括 dictEntry、redisObject、SDS 等，即使 value 只有几个字节，一个 Key 实际占用往往在 50～100 字节以上。按 80 字节算，1 亿 Key 大约是 8GB，仅一天的签到状态。30 天就是 240GB，这还没算过期、集群分片和复制带来的放大。更麻烦的是，Key 数量本身会拖慢 Redis 的字典和过期扫描。

第二个场景：网站 UV。产品要统计每天访问网站的去重用户数。传统做法是用 Set，每个 UV 就是一个 member。如果一个网站日活 1000 万，Set 里存 1000 万个用户 ID，每个 ID 假设 8 字节，加上 Set 的哈希表开销，轻松几个 GB。如果 ID 是 UUID，内存更大。而且这个统计通常不需要精确到个位数，只要趋势和量级对就行。

第三个场景：附近门店。用户打开 App，要看到 5km 内的门店。传统做法是把门店经纬度存在 MySQL，每次查询时用 haversine 公式计算距离，或者简单粗暴地按经纬度范围扫一遍。数据量小还能忍，门店几十万、上百万时，这种计算和扫描会拖垮数据库，尤其在高峰期。

这三个痛点的共同点：数据是海量但单个状态很小，或统计允许误差，或查询本质是空间距离。用错数据结构，不是常数优化问题，而是数量级问题。

## 02、是什么

Redis 官方文档里，除了 String、List、Set、ZSet、Hash 五大基础结构，还提供了一系列“扩展结构”，其中就包括 Bitmap、HyperLogLog、Geo。它们底层大多复用基础结构，但提供了更专门的 API。

Bitmap 不是一种新类型，它是 String 的二进制位操作。一个 String 最大 512MB，也就是 2^32 个 bit。你可以把 Bitmap 想象成一个超长的布尔数组，每个 bit 只能存 0 或 1，通过偏移量（offset）定位。比如 `setbit key 100 1` 就是把第 100 位设为 1。用它存签到状态，一个用户只占 1 bit，跟用户 ID 对齐后，1 亿用户只用约 12.5MB。

HyperLogLog 是一种概率数据结构，专门做基数统计，也就是统计不重复元素个数。它基于概率算法，标准错误率约 0.81%。关键是，无论你添加多少元素，它只占用 12KB 左右的内存。比如统计 UV，你不需要知道具体是哪些用户，只需要知道有多少不同用户，用它非常合适。Redis 提供了 `pfadd`、`pfcount` 等命令。

Geo 是 Redis 基于 Sorted Set 实现的地理位置结构。它把经纬度编码成 geohash 分数，存储在 ZSet 里，并提供 `geoadd`、`georadius`、`geodist` 等命令。这样既能利用 ZSet 的高效范围查询，又能直接按半径搜索，比如 5km 内的门店。

## 03、为什么

核心是五个字：数量级成本。

拿签到场景对比。同样 1 亿用户，普通 Key 方案一天大约 8GB 以上，而 Bitmap 方案只需 12.5MB（1 亿 bit / 8 / 1024 / 1024 ≈ 11.92MB）。这个差距不是百分之几十，而是几百倍。再算上 30 天，Bitmap 可以用 30 个 Key 表示每天的全体签到，每天 12.5MB，一个月 375MB；普通 Key 方案则要 240GB。两者根本不在一个数量级。

UV 统计同理。用 Set 存 1000 万用户 ID，内存可能在 1GB 以上；用 HyperLogLog 只要 12KB，误差约 0.81%。对于运营看趋势，这个误差完全可以接受。你甚至可以用更小的内存换取更低的误差（Redis 支持设置稀疏/稠密编码，但默认 12KB 已经足够大多数场景）。

附近门店的加速也很明显。基于 Geo 的 `georadius` 命令底层使用 ZSet 的分数范围查询，时间复杂度为 O(logN + M)，其中 N 是门店总数，M 是命中的门店数。而 MySQL 全表扫描距离是 O(N)，且每行都要计算三角函数。当 N 达到百万级时，差距是秒级和毫秒级的区别。

所以选型时不要只看功能能否实现，要问自己：这个数据是布尔状态吗？是海量去重计数吗？是空间距离查询吗？如果是，就去找对应的专用数据结构。

## 04、架构

在 Spring Boot 里落地这三个功能，架构并不复杂，关键是拆分职责和设计 Key 规范。

整体上，我们使用一个 Redis 实例或集群，通过 Spring Data Redis 提供的 `RedisTemplate` 或 `StringRedisTemplate` 访问。对于 Bitmap 操作，`ValueOperations` 提供 `setBit` 和 `getBit` 方法；对于 HyperLogLog，有专门的 `HyperLogLogOperations`（可以通过 `redisTemplate.opsForHyperLogLog()` 获取）；对于 Geo，有 `GeoOperations`（`redisTemplate.opsForGeo()`）。

Key 设计需要遵循业务维度。签到场景建议按天聚合：`sign:20240601`，偏移量为用户 ID（要求用户 ID 是数字且连续或可以映射）。这样一天的签到用一个 Key，30 天就是 30 个 Key，内存可控。如果要查某个用户 30 天的签到情况，可以用 `bitfield` 或循环 `getBit` 读取每一天的偏移。

UV 场景按天聚合：`uv:20240601`，使用 HyperLogLog 添加用户标识（比如 userId 或设备号）。每个 Key 自动占用约 12KB，可以定期过期。

门店 Geo 场景使用一个固定 Key：`shop:geo`，每个 member 是门店 ID，保存门店名称等可通过另一个 Hash 或 String 查询。`GeoOperations` 的 `add` 方法接受 `Point` 和 member，`radius` 方法按坐标或成员查询距离范围内的 member。

需要注意的是，如果用户 ID 不是连续数字而是 UUID，Bitmap 的偏移量会巨大且稀疏，此时需要先做一层映射，把 UUID 映射到连续自增 ID，否则 Bitmap 会浪费大量空间甚至不可用。

## 05、实战

下面用 Spring Boot 实现三个功能的核心代码。依赖使用 `spring-boot-starter-data-redis`，配置文件连接 Redis。

```java
@Service
public class SignService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    public void sign(long userId, LocalDate date) {
        String key = "sign:" + date;
        redisTemplate.opsForValue().setBit(key, userId, true);
    }

    public boolean isSigned(long userId, LocalDate date) {
        String key = "sign:" + date;
        return Boolean.TRUE.equals(redisTemplate.opsForValue().getBit(key, userId));
    }
}
```

上面用 `setBit` 和 `getBit` 完成单日签到和查询。`key` 格式为 `sign:yyyyMMdd`，偏移量是 `userId`。如果要统计一个用户最近 30 天连续签到天数，可以遍历每一天调用 `getBit`，或者使用 `bitfield` 一次性取回多个 bit 再判断。

```java
@Service
public class UvService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    public void recordVisit(String userId, LocalDate date) {
        String key = "uv:" + date;
        redisTemplate.opsForHyperLogLog().add(key, userId);
    }

    public long getUv(LocalDate date) {
        String key = "uv:" + date;
        return redisTemplate.opsForHyperLogLog().size(key);
    }
}
```

HyperLogLog 的添加和统计方法名是 `add` 和 `size`。注意 `opsForHyperLogLog` 是 Spring Data Redis 提供的操作类。

```java
@Service
public class ShopGeoService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    public void addShop(String shopId, double longitude, double latitude) {
        redisTemplate.opsForGeo().add("shop:geo", new Point(longitude, latitude), shopId);
    }

    public List<GeoResult<GeoLocation<String>>> findNearbyShops(double longitude, double latitude, double radiusKm) {
        Distance distance = new Distance(radiusKm, Metrics.KILOMETERS);
        Circle circle = new Circle(new Point(longitude, latitude), distance);
        GeoResults<GeoLocation<String>> results = redisTemplate.opsForGeo().radius("shop:geo", circle);
        return results.getContent();
    }
}
```

`Point` 构造时经纬度顺序通常是 `(经度, 纬度)`，`Distance` 可以指定单位。返回的 `GeoResult` 包含距离和 member。你可以再根据 member 去查门店详情缓存。

这三个代码片段加起来不到 50 行，但解决了三个典型的高成本问题。

## 06、洞见

写代码久了，容易陷入“功能优先”的惯性。但 Redis 这类基础组件，选型直接决定了你的系统能撑多大。

Bitmap 最大的优势是空间，但它有前提：偏移量要连续且密集。如果你的用户 ID 是雪花算法生成的长整型，或者 UUID，直接作为偏移量会导致 Bitmap 长度达到几十亿甚至更大，虽然 Redis 会自动扩容，但稀疏的 1 会浪费大量内存。解决方法是先在应用层做 ID 映射，比如用一个自增序列把 UUID 映射成紧凑数字，或者用分片 Bitmap。

HyperLogLog 则是典型的用误差换空间。0.81% 的误差对运营看 UV 趋势几乎无感，但如果你要精确到个位数，比如财务对账，那它就不合适。另外，HyperLogLog 不能判断某个元素是否存在，只能统计基数，所以它不能代替 Set 做去重集合。

Geo 底层是 ZSet，这意味着你可以用 ZSet 的所有命令去操作 Geo key，例如 `zrem` 删除门店、`zcard` 统计门店数。Geo 的 geohash 编码保证了地理相邻的 member 在分数空间上也相邻，所以范围查询高效。但注意 Geo 的半径查询返回的是大致矩形范围后再精确过滤，极端情况下可能有少量误差，对门店推荐足够。

更深一层的洞见是：性能优化往往不是把已有操作跑得更快，而是换一种数据结构，让算法复杂度直接降一个数量级。这种“数量级成本”思维，比调 JVM 参数、加索引更根本。

## 07、行动

学完这些，你可以从下面几步开始落地。

第一，梳理当前系统里所有 Redis Key 和数据结构。找出存布尔状态的、做海量去重统计的、涉及距离计算的，标记为候选场景。

第二，做内存评估。用 `redis-cli` 的 `memory usage` 或 `DEBUG OBJECT` 估算现有 Key 的开销，再对比 Bitmap/HyperLogLog/Geo 的理论内存，确认收益。

第三，设计 Key 规范和 ID 映射。确保用户 ID 适合 Bitmap 偏移，如果不适合，提前做好映射方案。

第四，先在测试环境用真实数据量模拟，验证误差和性能是否符合预期。特别是 HyperLogLog 的误差，要拿到业务方确认。

第五，灰度上线，监控内存、命中率、延迟。如果使用腾讯云 Redis，可以直接在控制台观察这些指标，必要时调整容量。

## 08、小结

Redis 的能力远不止五大基础结构。Bitmap 用 1 bit 存布尔状态，让亿级签到成本从 GB 级降到 MB 级；HyperLogLog 用 12KB 搞定海量 UV 近似统计；Geo 借助 ZSet 让附近门店查询进入毫秒级。它们的共同点是：用正确的数据结构，把成本降低一个数量级。

下次再遇到签到、在线状态、UV、附近的人等需求，先别急着写 String 和 Set，多想一步。

## 09、链接与概念说明

- Redis 官方文档数据结构页：https://redis.io/docs/data-types/  
- Bitmap 命令：https://redis.io/commands/setbit/  
- HyperLogLog 命令：https://redis.io/commands/pfadd/  
- Geo 命令：https://redis.io/commands/geoadd/  
- Spring Data Redis 文档：https://docs.spring.io/spring-data/redis/docs/current/reference/html/  
- 腾讯云 Redis 产品：https://cloud.tencent.com/product/crs

概念说明：

- Bitmap：基于 String 的位图操作，每个 bit 表示一个布尔状态，适合海量布尔数据。
- HyperLogLog：概率基数统计算法，固定约 12KB 内存，标准误差 0.81%，适合 UV 等近似去重计数。
- Geo：基于 Sorted Set 的地理位置索引，支持距离和范围查询，适合附近的人、门店等。
- 数量级成本：指通过选择合适的数据结构，将内存、时间或复杂度从 O(N) 降到 O(logN) 或常数级，而不是微调参数。

你有没有算过一笔账：1 亿用户每天签到，如果每个状态一个普通 Key，Redis 内存会爆成什么样？

《Redis 8.10 + Spring Boot 实战》第6招 Bitmap、HyperLogLog、Geo——Redis 如何用极少内存解决特殊统计问题

别再拿 String 存签到状态、拿 Set 统计 UV 了。Bitmap、HyperLogLog、Geo 是 Redis 里的三把省内存利器。本文用 Spri

架构师

数据库

后端

开发工具

用错Redis数据结构，1亿用户签到需8GB内存，UV统计存Set轻松几个GB，附近门店用MySQL算距离拖垮数据库。Bitmap用1bit存签到状态，内存降至12.5MB；HyperLogLog用12KB搞定千万级UV，误差0.81%；Geo借助ZSet实现毫秒级半径查询。本文通过原理剖析、内存对比和SpringBoot实战代码，帮你掌握三种进阶结构的选型与落地技巧，实现数量级成本优化。

数据结构

代码解释

MySQL

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

用错Redis数据结构，1亿用户签到需8GB内存，UV统计存Set轻松几个GB，附近门店用MySQL算距离拖垮数据库。Bitmap用1bit存签到状态，内存降至12.5MB；HyperLogLog用12KB搞定千万级UV，误差0.81%；Geo借助ZSet实现毫秒级半径查询。本文通过原理剖析、内存对比和SpringBo...

《Redis 8.10 + Spring Boot 实战》第6招 Bitmap、HyperLogLog、Geo——Redis 如何用极少内存解决特殊统计问题-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第6招 Bitmap、HyperLogLog、Geo——Redis 如何用极少内存解决特殊统计问题

《Redis 8.10 + Spring Boot 实战》第6招 Bitmap、HyperLogLog、Geo——Redis 如何用极少内存解决特殊统计问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐