从抖音、淘宝面试题看Redis

Java八股文
5109 字
11 分钟阅读
redis

亿级流量下的数据挑战：

在当今这个数据爆炸的时代，像抖音、淘宝、微博这样的平台，每天都要处理数以亿计的用户请求和数据。如何高效地收集、清洗、统计并展现这些海量数据，是衡量一个系统架构是否优秀的关键。这不仅是技术挑战，更是各大厂面试中频繁考察的核心能力。

本文将通过两道经典的面试题，深入探讨亿级数据场景下的痛点，并引出Redis中的ZSet、Bitmap、HyperLogLog等高级数据结构，看它们如何巧妙地解决聚合、排序、二值和基数统计这四大类问题。

实时列表的排序与展现

场景描述：

  1. 抖音电商直播： 主播介绍的商品有大量评论，需要实时展示最新的10条。
  2. App签到打卡： 钉钉或微博的每日签到，如何统计当天有哪些用户来了？
  3. 网站访问监控： 淘宝首页，如何统计每天的总浏览量（PV）和独立访客数（UV）？

这些场景的共同点是，一个对象（商品、签到日、网页）关联了一系列记录，并且需要进行快速的排序和展现。

网站访问监控海量数据的多维度统计

场景描述：

  1. 用户增长： 统计每天的新增用户数和次日留存用户数。
  2. 用户行为： 统计一个月内连续打卡的用户。
  3. 核心指标： 统计网站的独立访客（UV）量。

这类需求的核心是 “多维度统计” ，尤其是在亿级数据背景下，如何平衡内存消耗和计算效率成为最大的挑战。

亿级系统中的四种常见统计类型

1. 聚合统计 (Aggregation)

聚合统计主要是对多个集合进行交、并、差运算。例如，计算两个用户群体的共同关注、所有付费用户的总和等。

  • Redis实现： 使用Set数据结构，通过SINTER（交集）、SUNION（并集）、SDIFF（差集）等命令高效完成。

2. 排序统计 (Sorting)

即面试题一中的场景，通过ZSet实现实时排序和Top-N查询。

3. 二值统计 (Binary State)

指集合元素的值只有0和1两种状态。最典型的场景就是签到打卡，用户要么“来了”（1），要么“没来”（0）。

  • Redis实现： 使用Bitmap。Bitmap的底层是字符串，但它可以对字符串的每个bit位进行操作。我们可以用一个bit位来表示一个用户在某天的状态，极大地节省了存储空间。例如，用一个Bitmap记录所有用户在某天的签到情况，用户ID就是bit位的偏移量。统计连续签到天数，只需对多天的Bitmap进行BITOP AND（按位与）操作即可。

4. 基数统计 (Cardinality)

基数统计是指 统计一个集合中不重复元素的个数。这是非常核心且常见的需求，例如网站的UV统计。

关键指标定义：

  • PV (PageView): 页面浏览量，用户每访问一次页面就+1，无需去重。
  • UV (Unique Visitor): 独立访客数，同一用户一天内多次访问只算一次，需要去重。
  • DAU/MAU (Daily/Monthly Active Users): 日/月活跃用户数，指登录或使用过产品的用户数，也需要去重。

基数统计的挑战与终极方案：HyperLogLog

以淘宝首页UV为例，假设每天有1.5亿的独立访客。我们该如何存储和统计？

方案演进与瓶颈：

  1. MySQL： 在亿级数据量下，使用SELECT COUNT(DISTINCT ip) FROM ...进行去重统计，性能极差，基本不可行。
  2. Redis Hash/Set： 将每个IP地址或用户ID存入Hash或Set。我们来计算一下内存：1.5亿个IPv4地址（每个约15字节） 1.5亿 * 15B ≈ 2.25GB。这仅仅是一天的量，一个月就是近70GB，成本高昂，Redis实例难以承受。
  3. Redis Bitmap： Bitmap通过bit位映射，内存占用显著减少。假设用户ID是数字，要覆盖1.5亿的用户ID，需要的内存大约是 150,000,000 / 8 / 1024 / 1024 ≈ 17.8MB。这对于单个UV统计来说非常优秀。但如果我们需要统计1000个不同页面的UV，内存消耗就会变成 17.8MB * 1000 ≈ 17.8GB，依然是一笔巨大的开销。Bitmap的优点是 计算结果精确。

面对海量数据和有限的内存，我们必须做出取舍。在很多业务场景下，我们并不需要一个100%精确的数字，一个误差率极低的估算值就足够了。

终极解决方案：Redis HyperLogLog

HyperLogLog (HLL) 是一种概率性数据结构（probabilistic data structure），它被设计用来解决基数统计问题。

核心优势：

  • 空间占用极小且固定： 在Redis中，无论你向一个HyperLogLog键添加多少个元素，它的内存消耗始终固定在12KB左右。
  • 可接受的误差率： 它提供的是一个带有标准误差的近似值，Redis实现的版本标准误差仅为0.81%。 对于亿级的UV统计，这点误差完全可以接受。

工作原理：
HyperLogLog不存储元素本身，而是通过对元素进行哈希，并根据哈希值的特征来“预估”集合的基数。它就像一个数学魔术，通过牺牲绝对的准确性，换来了空间复杂度的巨大优化。

Redis命令：

  • ​PFADD key element [element ...]：向HLL中添加一个或多个元素。
  • ​PFCOUNT key [key ...]：计算一个或多个HLL的近似基数。
  • ​PFMERGE destkey sourcekey [sourcekey ...]：将多个HLL合并成一个，用于统计聚合数据（如统计整个网站的总UV）。

使用HyperLogLog来统计1.5亿的UV，内存消耗仅为12KB，相比于Bitmap的17.8MB或Set的2.25GB，优势不言而喻。

‍

回到最初的面试题，我们可以得出清晰的结论：

  • 对于实时排序、Top-N、最新列表等场景，如果数据更新频繁且需要分页，ZSet 是不二之选。
  • 对于需要精确统计二值状态（如签到、用户在线状态）的场景，Bitmap 能极大地节省内存。
  • 对于海量数据的基数统计（如UV、DAU） ，当对内存有极致要求且能容忍微小误差时，HyperLogLog 是业界的标准解决方案。

‍

抖音电商直播痛点分析

核心需求是 “存得进、取得快” 。当一个热门商品的评论区瞬间涌入成千上万条评论时，系统必须能够：

  1. 高效写入： 快速接收并存储新评论。
  2. 实时排序： 按照时间戳等维度对评论进行排序。
  3. 快速读取： 毫秒级响应，拉取最新的N条记录用于前端展示，并支持分页。

Redis ZSet

对于需要频繁更新、实时排序和分页的场景，ZSet是一个绝佳的选择。

ZSet（Sorted Set）是一个有序的集合，它的每个元素都会关联一个score（分数），Redis正是通过这个分数来为集合中的成员进行从小到大的排序。

设计思路：
以抖音评论为例，我们可以这样设计：

  • Key： comment:商品ID​
  • Score： 评论创建时的时间戳​
  • Value： 评论的具体内容或其ID

操作演示：

  1. 添加新评论： 每当有新评论（例如 “v1”, “v2”, “v3”）产生时，使用ZADD命令将其加入ZSet，以当前时间戳作为分数。

    ZADD comment:商品ID <时间戳1> "v1"
ZADD comment:商品ID <时间戳2> "v2"
ZADD comment:商品ID <时间戳3> "v3"

  2. 获取最新评论： 为了展示最新发布的评论，我们需要按时间倒序排列。使用ZREVRANGE命令即可轻松获取分数最高（即时间戳最新）的评论。

    • 获取最新的3条评论：ZREVRANGE comment:商品ID 0 2​
    • 结果将是："v3", "v2", "v1"​

  3. 分页加载： 获取第2页的10条评论（即第11到20条）：ZREVRANGE comment:商品ID 10 19​

通过ZSet，我们能够以极高的性能实现实时排行榜和最新列表功能，完美契合面试题中的需求。

App签到打卡

具体实现与例子

场景： 统计网站用户在2025年09月22日的签到情况。假设用户ID都是数字。

1. 记录签到 (SETBIT)

当用户签到时，我们就在今天的“签到表”上标记他。

  • 签到表的名字 (Key): signin:2025-09-22​
  • 用户ID (Offset/偏移量): 比如用户ID为 8 的用户来了。
  • 标记 (Value): 1​
# 用户ID为 8 的用户签到了
# 命令: SETBIT key offset value
# 意思是：在 signin:2025-09-22 这张表里，把第 8 个位置标记为 1
SETBIT signin:2025-09-22 8 1

# 用户ID为 100 的用户也签到了
SETBIT signin:2025-09-22 100 1

# 用户ID为 3 的用户也签到了
SETBIT signin:2025-09-22 3 1

执行完后，Redis 内部就维护了一个类似 000100001... 的二进制字符串，在第3、8、100的位置上都是 1。

2. 查询某个用户是否签到 (GETBIT)

我想查一下用户ID为 8 的今天来了吗？

# 命令: GETBIT key offset
# 意思是：查看 signin:2025-09-22 这张表里，第 8 个位置是 0 还是 1
GETBIT signin:2025-09-22 8
# 返回: (integer) 1  (表示来过了)

# 再查一下用户ID为 50 的来了吗？我们没记录过他。
GETBIT signin:2025-09-22 50
# 返回: (integer) 0  (表示没来)

3. 统计今天总共有多少人签到 (BITCOUNT)

这是 Bitmap 最强大的功能之一：一键统计。

# 命令: BITCOUNT key
# 意思是：数一下 signin:2025-09-22 这张表里，总共有多少个 1
BITCOUNT signin:2025-09-22
# 返回: (integer) 3  (因为我们记录了3个用户)

这个命令速度极快，无论你的“签到表”有多大，它都能迅速给出结果。

4. 进阶：统计连续两天都签到的用户 (BITOP)

假设我们还有一张昨天的签到表 signin:2025-09-21。现在想知道，哪些用户是昨天和今天都签到的“铁杆粉丝”？

# 假设昨天是用户 3, 8, 999 签到了
SETBIT signin:2025-09-21 3 1
SETBIT signin:2025-09-21 8 1
SETBIT signin:2025-09-21 999 1

# 使用 BITOP 进行 "与" (AND) 运算
# 命令: BITOP operation destkey key [key ...]
# 意思是：对 21号和22号这两张表进行 AND 运算，结果存到一张新表 two_days_active 里
BITOP AND two_days_active signin:2025-09-21 signin:2025-09-22‍```
*   **运算逻辑：** 只有在两张表中同一个位置都为 `1` 的，结果才为 `1`。
    *   用户 3：昨天是1，今天是1 -> 结果是1
    *   用户 8：昨天是1，今天是1 -> 结果是1
    *   用户 100：昨天是0，今天是1 -> 结果是0
    *   用户 999：昨天是1，今天是0 -> 结果是0

现在，我们来统计一下这张新表 `two_days_active`：
‍```redis
BITCOUNT two_days_active
# 返回: (integer) 2

我们就立刻得出了有2个用户连续两天签到。

特性Redis Bitmap
优点1. 极度节省空间 (一个用户只占1 bit)。
2. 计算速度极快 (位运算是CPU原生支持的)。
3. 结果100%精确。
缺点1. ID依赖严重：如果用户ID非常大且分散（比如ID是1和1亿），它会创建一个非常大的、中间很空的Bitmap，造成空间浪费。
2. 只适用于数字ID：非数字ID（如UUID）需要先映射成数字。

‍

二、HyperLogLog：不求精确但求快的 “估算大师”

核心思想

当你不需要知道 “具体有谁来过” ，也不需要100%精确的 “来了多少人” ，你只想快速知道一个 “大概来了多少人” 的数量级时，HyperLogLog 就是你的最佳选择。

它的核心是一种概率算法。你可以把它想象成一个聪明的数学家，你不断地给他看游客的身份证号，他不记下任何一个号码，只是在自己的小本本上做一些神秘的数学计算。最后，你问他：“大概来了多少个不同的人？” 他能给你一个非常接近真实值的数字。

具体实现与例子

场景： 统计淘宝首页在2025年09月22日有多少独立访客（UV）。访客标识是IP地址。

1. 记录访问 (PFADD)

每当有一个IP地址访问首页，我们就把它“喂”给 HyperLogLog。

  • UV统计表 (Key): uv:homepage:2025-09-22​
  • 访客标识 (Element): IP地址，例如 “192.168.0.1”
# 命令: PFADD key element [element ...]
# 意思是：向 uv:homepage:2025-09-22 这个统计器里添加一个元素

# ip_A 访问了
PFADD uv:homepage:2025-09-22 "192.168.0.1"

# ip_B 访问了
PFADD uv:homepage:2025-09-22 "10.0.5.2"

# ip_A 又访问了一次 (重复的)
PFADD uv:homepage:2025-09-22 "192.168.0.1"

# ip_C 访问了
PFADD uv:homepage:2025-09-22 "202.108.22.5"

HyperLogLog 内部会自动处理重复的元素。“192.168.0.1” 虽然加了两次，但只会被算作一个独立访客。

2. 获取UV估算值 (PFCOUNT)

现在，我们想知道首页今天大概有多少UV。

# 命令: PFCOUNT key [key ...]
# 意思是：估算一下 uv:homepage:2025-09-22 这个统计器里有多少个不重复的元素
PFCOUNT uv:homepage:2025-09-22
# 返回: (integer) 3

尽管我们添加了4次，但它正确地估算出去重后的数量是3。对于少量数据，它的结果通常是精确的；当数据量达到亿级时，它会给出一个误差在0.81%左右的近似值。

3. 进阶：合并多个页面的UV (PFMERGE)

假设我们还统计了商品详情页的UV uv:productpage:2025-09-22。现在老板想知道，今天访问过首页或商品页的总独立访客数是多少？

# 假设商品页有2个访客，其中一个和首页的访客重合
PFADD uv:productpage:2025-09-22 "192.168.0.1"  # (这是ip_A，和首页重合)
PFADD uv:productpage:2025-09-22 "114.114.114.114" # (这是ip_D，新访客)

# 使用 PFMERGE 合并两个统计器
# 命令: PFMERGE destkey sourcekey [sourcekey ...]
# 意思是：将首页和商品页的统计数据合并，结果存入一个新的统计器 total_uv 里
PFMERGE uv:total:2025-09-22 uv:homepage:2025-09-22 uv:productpage:2025-09-22‍```
现在，我们来查看这个合并后的总UV：
‍```redis
PFCOUNT uv:total:2025-09-22
# 返回: (integer) 4

结果是4，完全正确！(ip_A, ip_B, ip_C, ip_D)。这个合并操作非常高效，它不是简单地把元素加起来，而是合并了两个统计器内部的概率数据。

特性Redis HyperLogLog
优点1. 空间占用惊人地小且固定 (恒定12KB)。
2. 计算速度快，能处理海量数据。
3. 自动去重。
缺点1. 结果是估算值，有误差 (约0.81%)。
2. 无法获取具体的元素内容 (你不能问它“具体是哪4个IP访问了？”)。

总结对比

对比维度Redis Bitmap (签到表)Redis HyperLogLog (估算大师)
应用场景统计活跃用户、用户签到、在线状态等 精确 场景统计海量UV、DAU等 无需精确 的基数场景
精确度100% 精确约 99.19% 精确 (0.81%误差)
空间消耗与ID最大值有关，ID越大空间越大恒定 12KB
能否取回数据不能 (只能判断某个ID在不在)不能 (完全无法获取原始数据)

‍

‍

相关文章

jvm

3415 字

MySql

28205 字
最后更新：2025年09月22日
分享：