📚 课程目录第3章 Redis高级数据结构

3. Redis 高级数据结构：Bitmap、HyperLogLog、GEO、Stream 的使用场景与边界

在搜索缓存闭环中，基础数据结构（String、Hash、List、Set、Sorted Set）已能解决大部分缓存问题。然而，面对海量用户签到、UV 统计、LBS 检索、消息队列等特定场景，Redis 提供了四种高级数据结构，以极低的内存成本实现特定功能。本章深入剖析 Bitmap、HyperLogLog、GEO、Stream 的核心原理、适用边界及在搜索架构中的实战位置。

3.1 Bitmap：海量二值状态与签到场景

Bitmap 本质上是 String 类型的位操作扩展，通过 SETBIT / GETBIT / BITCOUNT / BITOP 等命令，将每个 bit 位映射为一个布尔状态。在搜索缓存中，Bitmap 常用于用户签到、日活统计、布隆过滤器等场景。

  核心优势： 1 亿个用户仅需约 12 MB 内存即可记录每日签到状态，相比 Set 或 String 存储 userId 列表，内存节省 90% 以上。

3.1.1 使用场景

用户签到 / 打卡： 以 userId 为 key，日期偏移量为 offset，SETBIT user:sign:20250101 12345 1 标记用户 12345 在 2025-01-01 已签到。
布隆过滤器（Bloom Filter）： 使用多个 hash 函数对 key 进行映射，将对应 bit 位置 1，用于缓存穿透防护——判断某个 key 是否“一定不存在”。
在线状态统计： 记录用户在线/离线状态，BITCOUNT 快速统计在线人数。
连续签到天数计算： 通过 BITFIELD 命令获取连续 bit 为 1 的区间长度。

3.1.2 边界与限制

边界维度	说明
最大长度	String 类型最大 512 MB，即 Bitmap 最多支持 2^32 个 bit（约 42.9 亿位）。
稀疏场景	若只有极少数位被置 1，Bitmap 仍会占用完整位图空间，不如 Set 或 IntSet 节省内存。
跨天统计	不同日期需使用不同 key，跨天连续签到需多次 BITOP 或客户端合并。
误判率	布隆过滤器存在假阳性（可能误判存在），无法删除元素。

搜索架构建议： 在搜索缓存穿透防护中，使用 Bitmap 实现的布隆过滤器应放在缓存层之前，拦截 99% 以上不存在的查询 key，避免穿透到数据库。

3.2 HyperLogLog：超低内存基数统计

HyperLogLog（HLL）是一种概率性数据结构，用于在极低内存下估算集合中不重复元素的数量（基数）。标准实现下，12 KB 内存即可统计 2^64 个元素的基数，误差率约 0.81%。在搜索缓存中，HLL 常用于 UV 统计、搜索词去重计数等场景。

  内存对比： 统计 1 亿独立 UV，Set 需约 800 MB，HLL 仅需 12 KB，内存节省 6 万倍以上。

3.2.1 使用场景

页面 UV 统计： PFADD page:uv:20250101 user123 user456，PFCOUNT page:uv:20250101 获取估算值。
搜索词去重计数： 统计当天独立搜索词数量，无需精确去重。
多日 UV 合并： PFMERGE result page:uv:20250101 page:uv:20250102 合并多天基数。

3.2.2 边界与限制

边界维度	说明
误差率	标准误差约 0.81%，无法精确到个位数，不适合需要精确计数的场景（如支付对账）。
无法回查元素	HLL 只存储基数估算值，不存储具体元素，无法获取“哪些用户访问过”。
小基数偏差	当基数小于几千时，误差可能偏大，Redis 内部使用稀疏存储优化，但仍有偏差。
不可删除	无法从 HLL 中移除某个元素，只能重建。

搜索架构建议： 在搜索推荐系统中，使用 HLL 统计热门搜索词的独立用户数，配合 ZSet 排序，可大幅降低内存开销。注意：HLL 结果仅用于趋势分析，不用于精确计费。

3.3 GEO：地理位置检索与 LBS 搜索

GEO 是 Redis 3.2 引入的地理位置数据结构，底层基于 Sorted Set 实现，通过 GeoHash 编码将经纬度映射为一维 score。支持添加位置、计算距离、范围查询、附近的人等 LBS 功能。

3.3.1 使用场景

附近的人 / 附近商家： GEORADIUS nearby:users 116.397 39.908 5000 km WITHDIST 查询 5 公里内的用户。
搜索服务节点就近路由： 根据客户端 IP 定位城市，选择最近的搜索集群节点。
物流配送范围判断： 判断用户地址是否在配送范围内。

3.3.2 边界与限制

边界维度	说明
精度限制	GeoHash 编码存在精度边界，极地地区或跨 180 度经线时可能出现误差。
范围查询性能	半径越大，扫描的 Sorted Set 范围越大，性能下降。建议配合分片或限制最大半径。
不支持多边形	GEO 只支持圆形范围查询，不支持多边形区域（如行政区划边界）。
数据量限制	单个 key 的 Sorted Set 元素数量建议不超过千万级，否则 ZRANGEBYSCORE 性能下降。

避坑提示： 不要使用 GEO 做实时轨迹追踪（高频更新位置），每次更新需删除旧元素再插入新元素，频繁写操作会导致 Sorted Set 内部结构重平衡，影响性能。轨迹追踪应使用时序数据库。

3.4 Stream：轻量级消息队列与事件驱动

Redis Stream 是 Redis 5.0 引入的类 Kafka 消息队列数据结构，支持消息持久化、消费者组、ACK 确认、阻塞读取等特性。在搜索缓存闭环中，Stream 常用于异步索引更新、缓存失效通知、日志采集等场景。

3.4.1 使用场景

搜索索引异步更新： 当数据库内容变更时，将变更事件写入 Stream，搜索服务作为消费者异步重建索引。
缓存失效通知： 缓存更新后，通过 Stream 广播失效事件，各节点本地缓存同步失效。
搜索点击流日志： 用户搜索点击行为写入 Stream，下游分析系统批量消费。

3.4.2 边界与限制

边界维度	说明
消息堆积	Stream 基于内存，消息堆积过多会耗尽内存。建议设置 `MAXLEN` 限制长度，或使用 `XTRIM` 定期裁剪。
持久化	Stream 依赖 RDB/AOF 持久化，宕机可能丢失少量未刷盘数据，不适合严格 Exactly-Once 语义。
消费者组重平衡	消费者增减时，Stream 不会自动重平衡分区，需手动调整 `XGROUP` 或使用外部协调。
性能上限	单节点 Stream 吞吐量受限于 Redis 单线程模型，高并发场景（>10 万 msg/s）建议使用 Kafka 或 Pulsar。

  搜索架构建议： Stream 适合中小规模（日消息量千万级）的异步索引更新。对于大规模搜索集群，建议使用 Kafka 作为消息中间件，Redis Stream 仅作为本地缓存失效的轻量级通道。

3.5 四种高级数据结构对比总结

数据结构	核心能力	内存效率	精度	搜索缓存典型场景
Bitmap	位操作、二值状态	极高（1 亿位 ≈ 12 MB）	精确	布隆过滤器、签到、在线状态
HyperLogLog	基数估算	极高（12 KB 统计 2^64 元素）	约 0.81% 误差	UV 统计、搜索词去重计数
GEO	地理位置检索	中等（基于 Sorted Set）	精确（受 GeoHash 精度限制）	附近搜索、就近路由
Stream	消息队列、事件驱动	中等（受 MAXLEN 控制）	At-Least-Once	异步索引更新、缓存失效通知

选型原则： 需要精确二值状态用 Bitmap；需要超低内存基数统计用 HyperLogLog；需要 LBS 检索用 GEO；需要轻量级异步消息用 Stream。避免在需要精确计数、元素回查、严格 Exactly-Once 语义的场景中使用概率性数据结构。