vault backup: 2026-06-08 23:08:57

hhs/Redis/13-HyperLogLog.md

@@ -1,5 +1,5 @@
 ---
-tags: [Redis, 缓存, 数据结构, HyperLogLog]
+tags: [Redis, HyperLogLog]
 create time: 2026-05-24 10:00
 ---
 
@@ -18,12 +18,16 @@ HyperLogLog（HLL）是 Redis 提供的**概率型基数估算数据结构**—
 
 HyperLogLog 的直觉来源于**伯努利试验**：抛一枚均匀硬币，连续出现 k 次正面的概率是 1/2^k。如果我们在所有试验中观察到最长的连续正面次数为 k，就可以反推大约有 2^k 个不同的试验。
 
+> [!tip] 生活化理解
+> 想象你在一个黑暗的房间里掷骰子，每次掷完只告诉你"前几个骰子是 1"。如果有人掷了 20 次才看到第一个不是 1 的骰子，你大概能猜出他掷了很多次——因为连续掷 20 个 1 的概率极低。HyperLogLog 就是用这个"前导零"的思想来估算数量。
+
 实际做法：
 
-1. **哈希映射**：对每个元素做哈希，得到一个均匀分布的比特串
+1. **哈希映射**：对每个元素做哈希，得到一个均匀分布的比特串（比如 `00010110...`）
 2. **分桶**：用前 14 位定位到 2^14 = 16384 个桶中的一个
 3. **记录前导零**：对剩余比特，统计第一个 1 出现前连续 0 的个数（取最大值）
-4. **调和均值**：所有桶的值通过调和均值公式合并，得到基数估算
+   - 例如 `00010110...` 的前导零是 3
+4. **调和均值**：所有桶的值通过调和均值公式合并，得到基数估算（避免极端值影响整体精度）
 
 > [!tip] 关键洞察
 > HLL 不存储元素，只存储每个桶的"最大前导零位数"。每个桶只需 6 个比特（能表示 0~63），所以总内存 = 16384 × 6 bit ≈ **12KB**，无论存 1 个元素还是 10 亿个元素。
@@ -39,6 +43,12 @@ HyperLogLog 的直觉来源于**伯努利试验**：抛一枚均匀硬币，连
 > [!question] 为什么命令叫 PF 开头？
 > PF 是 Philippe Flajolet 的名字缩写——他是 HyperLogLog 算法论文的主要作者。
 
+> [!warning] PFCOUNT 多 key vs PFMERGE 的区别
+> - `PFCOUNT key1 key2 ...`：临时计算多个 HLL 的并集基数，**不持久化结果**，每次都要重新计算
+> - `PFMERGE dest src1 src2 ...`：将多个 HLL 合并到 `dest`，**持久化结果**，之后 `PFCOUNT dest` 只需读单个 key
+>
+> 如果同一组 HLL 需要反复查询，应先 `PFMERGE` 再 `PFCOUNT`，避免重复计算开销。
+
 ## 二、UV 统计实战
 
 ### 用 Go 实现页面 UV 计数
@@ -70,7 +80,7 @@ func init() {
 // RecordVisit 记录一次页面访问，visitorID 为用户唯一标识
 func RecordVisit(page string, visitorID string) error {
 	key := fmt.Sprintf("uv:%s:%s", page, time.Now().Format("2006-01-02"))
-	// PFADD：如果 visitorID 已存在，不会重复计数（概率去重）
+	// PFADD：相同元素多次添加不会影响基数估算（HLL 不做去重，而是相同哈希值不产生新的前导零模式）
 	return rdb.PFAdd(ctx, key, visitorID).Err()
 }
 
@@ -98,6 +108,9 @@ func main() {
 > [!tip] 对比 Set 方案
 > 如果用 `SADD` + `SCARD` 实现同样功能，10000 个用户 ID 至少消耗 **数百 KB**；而 HyperLogLog 的 `uv:home:2026-05-24` 这个 key 始终只占 **12KB**。用户量越大，HLL 的优势越明显。
 
+> [!warning] 别忘了给日 UV key 设过期时间
+> 上面的代码按日期生成 key（如 `uv:home:2026-05-24`），如果不设置 TTL，历史 key 会永远堆积。建议在 `PFADD` 后追加 `Expire(ctx, key, 7*24*time.Hour)`，保留 7 天即可满足周报表合并需求，之后自动清理。
+
 ## 三、合并多个统计源
 
 实际业务中经常需要合并数据——比如从每日 UV 汇总出每周 UV。
@@ -129,6 +142,9 @@ func GetWeeklyUV(page string, weekStart time.Time) (int64, error) {
 > [!question] PFMERGE 是精确合并吗？
 > 是的。PFMERGE 会取每个桶在所有源 HLL 中的最大值，数学上等价于对并集重新计算 HLL。合并后再 PFCOUNT，得到的就是**并集的估算基数**，误差不会因为合并而放大。
 
+> [!warning] 无法用 HLL 计算交集
+> PFMERGE 计算的是并集基数。很多人误以为 `|A ∩ B| = |A| + |B| - |A ∪ B|` 可以推导交集——但这是**错误的**，因为 |A|、|B|、|A ∪ B| 都是估算值，三者相减的误差会被放大到完全不可用。如果需要交集计数，请用 Set 或 Bloom Filter。
+
 ## 四、误差分析
 
 HyperLogLog 的标准误差为 **1.04 / sqrt(m)**，其中 m 是桶数。Redis 使用 16384 个桶：
@@ -156,8 +172,10 @@ HyperLogLog 的内存占用是**固定**的，与元素数量无关：
 总内存 = 16384 × 6 bit = 98304 bit ≈ 12KB
 ```
 
-> [!tip] Redis 的内存优化
-> 当 HLL 计数的基数较小时（稀疏表示），Redis 会用更紧凑的编码存储，可能只占几百字节。只有当基数增长到一定程度，才会扩展到完整的 12KB。这个过程是自动的，对用户透明。
+> [!tip] Redis 的内存优化：稀疏 → 稠密
+> 当 HLL 计数的基数较小时，Redis 使用**稀疏表示**（sparse）——只记录有变化的桶，内存可能只占几百字节。随着基数增长，当稀疏编码的大小超过阈值时，Redis 会**一次性展开为 12KB 的稠密表示**（dense），之后不会再回退。
+>
+> 这个转换是自动的，但要注意：转换发生在 PFADD 写入时，可能造成一次**瞬间内存跳变**（几百字节 → 12KB）。在高并发场景下，大量 HLL key 同时触发转换会带来内存尖峰，建议提前预热或评估 key 数量。
 
 | 场景 | Set 内存 | HyperLogLog 内存 |
 |------|---------|-----------------|
@@ -181,6 +199,7 @@ HyperLogLog 的内存占用是**固定**的，与元素数量无关：
 - **数据量极小（< 1000）**：此时 Set 占用内存也很小，且精确无误
 
 > [!question] 三种方案怎么选？
+> 以下是三种数据结构的对比，帮你快速决策：
 
 | 维度 | HyperLogLog | Set | Bitmap |
 |------|------------|-----|--------|
@@ -196,12 +215,12 @@ HyperLogLog 的内存占用是**固定**的，与元素数量无关：
 
 ```mermaid
 graph LR
-    A["用户请求页面"] --> B["PFADD uv:page:date visitor_id"]
-    B --> C["Redis HyperLogLog"]
-    C --> D["PFCOUNT uv:page:date"]
-    D --> E["返回估算 UV 数"]
+    A["用户请求页面"] --> B["PFADD 写入元素"]
+    B --> C["EXPIRE 设置 TTL"]
+    C --> D["Redis HyperLogLog"]
+    D --> E["PFCOUNT 获取基数"]
     E --> F["展示在监控面板"]
-    G["每日凌晨"] --> H["PFMERGE uv:page:week daily_keys"]
+    G["每日凌晨"] --> H["PFMERGE 合并日 UV"]
     H --> I["周报 UV 汇总"]
 ```
 
@@ -209,4 +228,3 @@ graph LR
 
 - [[hhs/Redis/02-核心数据类型]]
 - [[hhs/Redis/12-Bitmap]]
-- [[hhs/Redis/README]]