Redis高级数据结构：魔法仓库里的四件神器

可视化演示

一、Bitmap 位图：仓库的开关面板

想象你管理着一座能容纳上亿人的魔法仓库。为了知道“每个人今天有没有来过”，你请工匠做了面巨大的开关墙：每个固定位置对应一位客人，位置号就是客人 ID。某人来过，就把他的开关拨到“开”。这面墙神奇的地方在于——一千万个开关，占用的墙面却只有一张 A4 纸那么厚。

这面“开关墙”在 Redis 中的名字叫 Bitmap（位图）。它并不是第五种魔法数据类型，而是寄居在 String 身体里的“位级操作术”。你可以通过 SETBIT 在指定下标写入 0 或 1，用 GETBIT 想读哪个读哪个，用 BITCOUNT 统计所有被拨到“开”的开关总数——也就是今天来过的人数。

假设要给 N 个用户每人分配一个开关位，内存开支就是 N/8 个字节。为什么这么省？因为一位（bit）是计算机的最小存储单位，8 个位才凑成一个字节。一个亿级用户的系统，如果每个用户用一个整数 ID 存 Set，至少数百 MB；而 Bitmap 只需要 1.25MB。

回到那面开关墙：与其说你在写代码，不如说你在安排一个个小小的金属拨片。Bitmap 的最大魅力不是“能存”，而是“能掐着内存算着存”——这正是它在高并发统计场景里经久不衰的原因。

二、HyperLogLog：门口的客流估算器

仓库门口又添了一件新宝贝——一个巴掌大的青铜匣子。每位客人进门时只需轻轻“拍”一下匣子，匣子并不记录客人是谁，只在内部某个角落留下一道刮痕。晚上下班，你敲敲匣子，它报出一个数：“今日不同访客约 32850 人”。你清点人工记录，实际是 33120 人，误差不到 1%。

青铜匣子就是 HyperLogLog，简称 HLL。它解决的是“基数统计”问题——统计不重复元素的个数。它不存每个元素本身，而是把每个元素“拍”成一道哈希痕迹，从而用极小内存估算基数。Redis 提供的命令也很简单：PFADD 负责“拍”，PFCOUNT 负责“报数”，PFMERGE 合并多个匣子。

HLL 内部有 16384 个寄存器，每个寄存器占 6bit，所以总内存固定在 16384×6/8=12288 字节，约 12KB。当一个元素进来时，Redis 计算它的哈希值，再看这个哈希值的二进制串开头有多少个连续的 0（这叫“前导零”）——连续 0 越多，说明这个数越“稀有”——把这个信息更新到对应寄存器中。最后，用调和平均把 16384 个值融合成估算基数。

匣子虽然说不清“每个人是谁”，但在“今天大概来了多少人”这种问题上，它用 12KB 的恒定内存，把答案估得八九不离十。对于海量 UV 统计，这种“模糊的正确”远胜“精确的昂贵”。

三、GeoHash：地板上的魔幻网格

为了帮客人快速找到货架，你让魔法师在仓库地板上画了一套网格。每块格子都有唯一的编号，譬如“北一-东三-中五”。只要你报出编号，管家立刻能跑到对应格子上。而且编号越接近，说明格子挨得越近——不需要拿尺子量。

这套网格就是 GeoHash。它的目标是把地球表面切成一层层越来越小的“方格”，并把经纬度这个二维坐标压缩成一串一维字符串。Redis 里的地理位置命令（GEOADD、GEOSEARCH）内部都用 GeoHash 实现。存入深圳的坐标，和存入广州的坐标，因为网格前缀不同，一眼就能判断相隔很远。

GEOADD key lon lat member 负责把某个成员的经纬度写进一个 ZSET（有序集合），score 就是 GeoHash 编码后的整数。GEOSEARCH 则把“附近的人”查询转换为 score 范围查询。编码过程分三步：先对经度区间 [-180,180] 做二分，落在右边记为 1、左边记为 0；再对纬度区间 [-90,90] 同样二分；然后把经度位和纬度位交替穿插，最后每 5 个二进制位用 Base32 编码成一个字符。

现在你明白为什么说“编码越接近，物理距离越近”——因为两个仓库格子挨得越近，它们共享的网格前缀就越长。这就是 GeoHash 把空间几何问题变成字符串比较问题的魔法精髓。

四、Stream：写不完的流水账卷轴

仓库角落那卷泛黄的账本，是件自动延伸的魔法道具。每次进货或出货，账本自动在末尾流出一行新记录：时间、货物、数量，绝无涂改。更厉害的是，几个店员可以组成“小组”分头看账，每笔账目只能被小组里一个人认领，干完活要在账上画个勾——其他人看到勾就知道不必再干。

这卷账本就是 Stream，Redis 5.0 引入的“消息流”数据结构。它不像 List 那样只是临时队列，也不像 Pub/Sub 那样发完就消失。Stream 里的消息会持续累积，支持按 ID 范围读取、消费者组分配、消息确认和断点续读。这让它成为轻量级可靠消息队列的首选。

XADD 向 Stream 末尾追加一条消息；XREAD 从某个 ID 之后读取新消息；XGROUP CREATE 为消费组分配游标；XREADGROUP 让组内消费者各自领到不同消息；XACK 确认处理完毕。每一条消息都有一个自动生成的 ID，由“毫秒时间戳”和“序列号”两部分用短横线拼接而成。Redis 保证同一个实例内 ID 全局有序且唯一。

账本上每一行的“时间-序号”双联编号，让你既能按时间线重放所有流程，又能确保每笔账都被一个店员认真处理且只处理一次——这正是可靠消息队列最需要的两样东西。

五、场景选型：给神器贴工作标签

四件神器各有绝活，但用错地方就会闹笑话。你不能靠门口的估算匣子确定一个人今天是否来过，也不能在账本卷轴上做签到统计。作为仓库管家，最重要的能力不是背出每件神器的参数，而是“见活拿器”。

先看几个典型需求：签到/日活，每个用户只有“有/无”两种状态，选 Bitmap；页面 UV，只关心不同访客总数且可容忍误差，选 HyperLogLog；附近的人，需要经纬度和距离排序，选 GeoHash；订单/任务流，需要顺序消费和多人协作，选 Stream。

用一个内存估算公式可以直观看到选型差距。假设要统计 N 个用户 ID：用 Set 逐个存 ID，每个 ID 至少 100 字节；用 Bitmap 每位用户只要 1 位；用 HLL 不管多少人都只占 12KB。

给神器贴标签这件事，本质上是把“数据的形状”和“结构的特长”配对：状态类数据找开关墙，总数类数据找估算匣子，坐标类数据找网格地图，流程类数据找账本卷轴。

六、内存与性能：神器的体力图谱

选对了神器，还要了解它们的“体力上限”。开关墙的拨动速度极快，但墙再多也不可能无限生长；估算匣子永远 12KB，几乎零负担；网格地图能精确定位，但每次画格子都要算半天；账本卷轴写起来顺畅，却要额外维护“读到哪一行”。

用时间复杂度和空间复杂度来画这幅“体力图谱”。复杂度不关心具体耗时数值，只看数据量翻倍时成本怎么变化。对高并发系统来说，这个“增长趋势”才是选型的真正依据。

Set 存 ID，内存是 O(N) 线性增长；Bitmap 同样是线性，但斜率是 1/8，所以是小头线性；HLL 直接 O(1)，恒定 12KB。读写时间上，Bitmap 和 HLL 都是 O(1)，GeoHash 需要额外计算编码，Stream 的写入是 O(1) 追加、消费靠游标推进，非常轻。

有了这张体力图谱，你就不再是只会背命令的新管家，而是懂得“哪个神器在哪些活上永不疲惫”的资深调度员。Redis 高级数据结构的真正价值，不是炫技，而是帮你在大规模场景下精准控制每字节成本。

---

AI 应用场景

Python 演示

import redisimport random # 连接 Redis (本地默认端口)r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)  def bitmap_demo():    """Bitmap: 记录 1000 个用户某天的签到状态"""    key = 'sign:20240101'    r.delete(key)    for uid in range(1000):        if random.random() > 0.4:            r.setbit(key, uid, 1)    signed = r.bitcount(key)    print(f'Bitmap 签到人数: {signed}/1000')    print(f'8号用户是否签到: {bool(r.getbit(key, 8))}')  def hll_demo():    """HyperLogLog: 估算首页 UV"""    key = 'uv:homepage'    r.delete(key)    real_users = set()    for _ in range(50000):        uid = random.randint(0, 9999)        r.pfadd(key, f'user:{uid}')        real_users.add(uid)    estimate = r.pfcount(key)    real = len(real_users)    ratio = abs(estimate - real) / real * 100    print(f'HLL 估算 UV: {estimate}, 真实 UV: {real}, 偏差 {ratio:.2f}%')  def geohash_demo():    """GeoHash: 存入商家坐标并搜索附近"""    key = 'geo:shops'    r.delete(key)    shops = [        ('cafe', 116.397, 39.909),        ('bookstore', 116.410, 39.920),        ('hotel', 116.405, 39.915),    ]    for name, lon, lat in shops:        r.geoadd(key, (lon, lat, name))    near = r.geosearch(key, longitude=116.400, latitude=39.912,                       radius=2, unit='km')    print(f'GeoHash 附近 2km 商家: {near}')  def stream_demo():    """Stream: 生产订单事件并消费"""    key = 'stream:orders'    r.delete(key)    msg_id = r.xadd(key, {'order_id': 'A001', 'amount': '99'})    print(f'Stream 消息 ID: {msg_id}')    msgs = r.xread({key: '0'}, count=5)    for stream_id, entries in msgs:        for mid, fields in entries:            print(f'消费事件: {mid} -> {fields}')    r.xdel(key, msg_id)  if __name__ == '__main__':    bitmap_demo()    hll_demo()    geohash_demo()    stream_demo()

1. r.setbit(key, uid, 1)把第 uid 个开关拨到“开”，表示该用户签到。
2. r.bitcount(key)统计开了多少个开关，即签到总人数。
3. r.pfadd(key, f'user:{uid}')把访客 ID“拍”进 HLL 小匣子，不存原文。
4. r.pfcount(key)让匣子报出估算的独立访客数。
5. r.geoadd(key, (lon, lat, name))把商家的经纬度编码为网格 score 存入 ZSET。
6. r.geosearch(...)以某点为中心，搜索半径 2km 内的所有商家名称。
7. r.xadd(key, {...})向 Stream 账本末尾追加一条订单消息，返回自动生成的 ID。
8. r.xread({key: '0'}, count=5)从 ID=0 开始读取，即从头消费所有消息。

常见误区

面试题