Redis Bitmap、HyperLogLog、Geo 分别适合什么场景？

简化版

Bitmap 适合海量布尔状态，如签到、在线标记；HyperLogLog 适合低内存估算 UV，但有误差且不能取明细；Geo 适合经纬度附近位置查询，底层基于有序集合思想。三者都是为特定场景节省成本的结构，不适合替代通用明细存储。

详细版

Bitmap、HyperLogLog、Geo 常被问，是因为它们能体现 Redis 在工程场景里的空间效率。

• Bitmap：用 bit 表示状态，适合签到、活跃、布尔标签。
• HyperLogLog：估算基数，适合 UV、去重计数，典型误差约 0.81%。
• Geo：存经纬度并做附近查询，适合门店、司机、设备位置。

注意边界：

• Bitmap offset 太大可能撑大字符串。
• HyperLogLog 不能精确计数，也不能列出成员。
• Geo 不适合复杂 GIS，多维条件还要结合业务索引。

完整版教学

一、这三个结构为什么高频

面试官问它们，不是想听命令列表，而是想看你能不能用合适结构降低成本。很多业务不用 Redis 特殊结构也能做，但内存和复杂度会更高。

比如签到可以用 Set 存每天用户 ID，也可以用 Bitmap 把用户 ID 映射到 bit。一个用户一天只需要 1 bit，这就是数量级差异。

记忆钩子：Bitmap 省布尔状态，HyperLogLog 省去重计数，Geo 省附近位置检索。

二、Bitmap 适合布尔状态

Bitmap 本质上是 String 的位操作。一个 bit 表示一个状态，0 或 1。适合签到、是否活跃、是否领取权益等场景。

假设有 1000 万用户，用 Bitmap 表示某天是否签到，需要约：

10,000,000 bit / 8 = 1,250,000 byte ≈ 1.19 MB

如果用 Set 存用户 ID，即使每个 ID 只按 8 字节算，也要 80 MB 以上，还没算对象和哈希表开销。

三、Bitmap 的边界

Bitmap 的 offset 如果非常大，中间空洞也会占空间。例如直接用稀疏的全局用户 ID 做 offset，如果最大 ID 是 10 亿，即使只有少量用户签到，也可能撑出很大的字符串。

所以工程上常做 ID 映射，或者按日期、业务、用户段拆 key。

sign:2026-07-29:bucket:0
sign:2026-07-29:bucket:1

Bitmap 适合状态，不适合存复杂属性；要查明细也需要额外映射。

四、HyperLogLog 适合估算 UV

HyperLogLog 用很小内存估算基数，适合“有多少不同用户访问过”这类问题。Redis 的 HLL 常见只需要约 12 KB 就能估算大量元素基数。

PFADD uv:today user1 user2 user3
PFCOUNT uv:today
PFMERGE uv:week uv:day1 uv:day2

它的代价是有误差，Redis 官方常说标准误差约 0.81%。如果业务要求精确计费、精确风控，就不能只依赖 HLL。

五、HyperLogLog 不能取明细

HLL 只维护估算基数的信息，不能告诉你有哪些用户，也不能删除某个用户后准确回退。它适合统计，不适合明细查询。

需求	HLL 是否适合
估算 UV	适合
精确 UV	不适合
查询访问用户列表	不适合
多天 UV 合并估算	适合

如果既要估算又要明细，可以 HLL + 日志/数仓搭配，Redis 负责在线粗统计，离线系统负责精确分析。

六、Geo 适合附近位置查询

Geo 用来存经纬度位置，并支持按距离查询附近成员。典型场景是附近门店、附近司机、附近设备。

GEOADD shops 116.397 39.908 shop:1
GEOSEARCH shops FROMLONLAT 116.40 39.90 BYRADIUS 3 km WITHDIST

Redis Geo 底层可以理解为把经纬度编码后放进有序集合，利用排序能力做范围过滤，再计算距离。

七、Geo 的工程限制

Geo 适合简单附近查询，但不是完整 GIS。复杂多边形、道路距离、行政区划、交通耗时、多条件过滤，都需要业务系统或专业地理服务配合。

比如“附近 3 公里评分大于 4.8 且营业中的门店”，Redis 可以先查附近候选，再由业务层过滤评分和状态。候选太多时，要按城市、区域、业务类型拆 key。

能力	Redis Geo	专业 GIS
半径附近	适合	适合
路网距离	不适合	适合
多边形区域	不适合	适合
复杂空间索引	有限	更强

八、常见误区与追问

• 误区：Bitmap 一定比 Set 省内存。 offset 稀疏且最大值很大时，Bitmap 可能浪费空间。
• 误区：HyperLogLog 是精确去重。 它是概率估算，有误差，不能用于强精确场景。
• 误区：Geo 可以替代地图数据库。 Redis Geo 适合简单附近查询，不适合复杂 GIS。
• 追问：Bitmap 怎么统计连续签到？ 可以按日期 bitmap 做位运算，或按用户维度存月份签到位图。
• 追问：HLL 能不能删除元素？ 不能做精确删除后回退，因为它不保存明细集合。
• 追问：Geo 如何结合业务过滤？ 先按地理范围取候选，再用业务字段过滤，必要时拆 key 减少候选量。

九、加强记忆

记住“三个省”：Bitmap 省布尔状态空间，HyperLogLog 省 UV 统计空间，Geo 省附近检索实现成本。

答题时一定补边界：Bitmap 怕稀疏大 offset，HLL 有误差且无明细，Geo 不是完整 GIS。