【Redis】 高级类型与布隆过滤器 原理+场景全解析

大家好，我是程序员二叉。

简介

本文详细讲解 Redis 四大高级功能：HyperLogLog、Bitmap、Geo、Stream，以及面试高频考点 布隆过滤器。涵盖底层原理、使用场景、核心区别、实战要点，是后端进阶与面试必备干货。欢迎点赞收藏关注。

一、HyperLogLog：基数统计神器

1. 核心作用

只做一件事：统计一个集合中不重复元素的个数（基数统计）。
例如：统计网站 UV、独立访客数、每日活跃设备数。

2. 误差范围

• 标准误差率：0.81%（极小误差）。
• 内存占用：极小！ 每个 Key 最多占用 12KB 内存，无论统计 1000 条还是 10 亿条数据。

3. 优缺点

• 优点：内存占用极低、速度极快、支持合并统计。
• 缺点：只能统计数量，不能获取原始数据，存在微小误差。

4. 核心命令

• PFADD key element：添加元素
• PFCOUNT key：统计基数

5. 适用场景

• 页面 UV（独立访客）统计
• 日活、月活用户数（DAU/MAU）
• 海量数据去重计数（不要求 100% 精确）

二、Bitmap 位图：二进制状态存储

1. 底层原理

• 本质是一串连续的二进制数组（0 和 1），底层基于 String 实现。
• 一个 bit 位代表一个状态，极大节省内存。
• 1MB 内存 = 800 万 bit，可以记录 800 万个状态。

2. 核心命令

• SETBIT key offset value：设置第 offset 位的值（0/1）
• GETBIT key offset：获取状态
• BITCOUNT key：统计有多少个 1

3. 经典场景：用户签到

• Key 设计：sign:user:1001:202505
• Offset：日期（1~31）
• Value：1=已签到，0=未签到
• 优势：一个用户一个月仅占用 31 bit（约4字节）。

4. 经典场景：统计活跃用户

• Key 设计：active:20250501
• Offset：用户 ID
• 统计：BITCOUNT 算出当日活跃人数。
• 多日统计：BITOP 做与/或运算，算出连续活跃天数。

三、Geo 地理位置：附近的人/店

1. 实现原理

• 底层就是 ZSet（有序集合）。
• 使用 GeoHash 算法 将二维经纬度（经度、纬度）编码成一个分数 score。
• 利用 ZSet 的排序特性，实现范围查找。

2. 核心命令

• GEOADD key 经度 纬度 成员：添加位置
• GEODIST key 成员1 成员2：计算距离
• GEORADIUS key 经度 纬度 半径：查找附近元素

3. 适用场景

• 附近的人、附近的门店
• 外卖配送范围、网约车距离计算
• 同城推荐

四、Stream：专业消息队列

1. 核心原理

Redis 5.0 专为消息队列设计的数据结构，支持：持久化、多消费者、消息回溯、堆积。

2. 核心概念

3. 核心命令

• XADD：生产消息
• XREADGROUP：消费组消费
• XACK：确认消息（标记已消费）

4. 优势

• 消息持久化，重启不丢失。
• 支持堆积，百万消息无压力。
• 消费组 + 偏移量，实现可靠消息投递。

五、Bitmap vs HyperLogLog 核心区别

一句话总结

• 需要查单个用户状态用 Bitmap。
• 只需要统计总人数且省内存用 HyperLogLog。

六、布隆过滤器（Bloom Filter）：缓存穿透杀手

1. 核心原理

• 由一个超大的二进制数组 + 多个哈希函数组成。
• 添加元素时，通过多个 Hash 算法算出多个位置，把这些位置置为 1。
• 查询元素时，检查这些位置是否全为 1。

2. 优缺点

• 优点：内存占用极小、查询速度 O(1)、判断存在性高效。
• 缺点：
• 有误判率：判断存在的，可能不存在（假阳性）。
• 无法删除：置 1 容易，清零难。

3. 误判问题

• 一定会误判，但可以通过调大数组、增加 Hash 函数降低误判率。
• 对策：
  • 允许一定误判，容忍小概率错误。
  • 误判后请求数据库，数据库返回空则直接返回。

4. 核心使用场景

解决缓存穿透问题（大量查询不存在的数据，直接打穿到数据库）。

总结