1. 原理剖析：Redis HyperLogLog 的去重统计核心
1.1 核心思想与数据结构
在海量数据去重统计场景中，HyperLogLog 将每个输入元素通过高质量哈希映射到一个寄存器阵列中，并通过寄存器中记录的最大前缀零数来估算集合的基数。这是一种通过有限状态来近似大规模集合基数的算法，其核心优势是内存占用与精度之间的友好权衡。
HyperLogLog 的数据结构是一个寄存器数组，寄存器个数 m 是底层精度和内存消耗的关键参数，通常通过一个对数参数 p 来决定：m = 2^p。越多寄存器，估算越精确，内存开销也越大。
1.2 寄存器设计与估算公式
在实现中，每个寄存器保存一个较小的数值，用于记录哈希值的前缀零的最大值。当新的元素加入时，哈希后得到的位模式会影响对应寄存器的更新。
基数估算的核心公式是：E = alpha_m * m^2 / sum(2^{-M_j})，其中 M_j 是寄存器 j 的值，alpha_m 是对寄存器数量的常数系数，通常随 m 的大小确定。在 Redis 的实现中，m 常取 16384，因此估算误差在接近 0.8% 左右，适合大规模去重场景。
1.3 去重统计的近似特性
与精确计数相比，HyperLogLog 提供的是近似去重统计，但在大规模数据下的误差可控，通常用于毫秒级别实时统计与离线分析的结合。
通过多组寄存器并行工作，可以将统计维度扩展到跨时间、跨区域的去重统计，并通过 PFMERGE 将不同分区的结果合并成一个全局基数估算。
2. 在 Redis 中实现 HyperLogLog：PFADD、PFCOUNT、PFMERGE
2.1 核心命令与数据结构
Redis 将 HyperLogLog 的核心操作暴露为三类命令：PFADD、PFCOUNT、PFMERGE。PFADD 用于向一个 HLL 实例中增量添加元素，PFCOUNT 对一个或多个 HLL 实例进行基数估算，PFMERGE 将多个 HLL 的寄存器进行逐位合并以得到一个新的 HLL。
在实际生产中，使用 PFADD 时应确保哈希输入的多样性，避免单位时间内高并发对单一寄存器的冲击，这有助于稳定估算结果。
2.2 基本用法与示例
下面给出一个典型的使用场景：对用户唯一性进行跨日去重统计，将每日用户标识加入对应的 HyperLogLog，然后在需要时聚合到全局基数。
PFADD hll:day:20250101 1001
PFADD hll:day:20250101 1002
PFADD hll:day:20250102 1001
PFADD hll:day:20250102 1003
PFCOUNT hll:day:20250101
PFCOUNT hll:day:20250102
PFMERGE hll:all:2025 hll:day:20250101 hll:day:20250102
PFCOUNT hll:all:2025通过以上命令，可以实现对日级去重结果的统计，并通过 PFMERGE 实现跨日合并，进而得到全量的近似去重基数。
3. 落地实践：在大规模数据场景中的策略
3.1 分片与聚合策略
在大规模系统中，通常将数据按照时间、区域或业务维度进行分片，分别维护独立的 HyperLogLog，再通过 PFMERGE 将分片结果聚合为全局视图。
分片带来的好处是：并发写入更容易实现，单个 HLL 的内存占用更低，同时通过定期聚合实现全局趋势的近似统计。
3.2 内存成本与容量规划
HyperLogLog 的内存消耗与寄存器数量直接相关，以 m = 16384 的配置为例，大约需要 12KB 左右的内存用于一个 HLL 实例，且随并发键增多需要额外的寄存器集合。
在容量规划时，需关注：并发写入速率、每日增量、心跳合并窗口，以及在 Redis 集群中的路由分布，以确保 PFADD 的写入压力均匀分布。
3.3 跨维度统计与合并场景
对于多维度的去重需求，可以把不同维度的 HLL 放在不同的 Redis 键上，再通过 PFMERGE 将同一时间维度或同一业务维度的结果聚合，实现跨维度的全局基数估算。
PFMERGE hll:totals:202501 hll:day:20250101 hll:day:20250102
PFCOUNT hll:totals:2025014. 误差分析与对比：与其他去重方案的对比
4.1 误差来源与控制
误差主要来自于 寄存器数量以及哈希冲突带来的轻微偏差，此外在极端高并发、极端长尾分布下也会影响精度。
标准误差公式为 1.04 / sqrt(m)，m 越大，误差越小。在 16384 寄存器的情况下，误差大约在 0.8% 左右，适合对去重规模有清晰的近似需求的场景。
4.2 与其他去重方案的对比
与布隆过滤器等结构相比，HyperLogLog 专注于基数估算，适合大规模去重统计的场景，而布隆过滤器更擅长判定元素是否存在于集合中，缺乏直接的去重规模估算。
在实际应用中，将 HyperLogLog 与 Bloom Filter/Count-Min 等结构结合使用，可以覆盖从是否存在到基数统计的全链路需求，从而提升整体数据处理能力。
5. 实现案例：一条龙落地流程示例
5.1 部署与命名规范
在落地时，建议采用清晰的命名体系：按时间和业务维度拆分 HLL 键，例如 hll:day:YYYYMMDD、hll:segment:region，以便后续的聚合与维护。
同时，确保 PFADD 的幂等性设计，避免重复入库导致统计偏差，并在数据管道中引入统一的落盘时间点以实现一致性。
5.2 部署步骤与落地流程
核心落地步骤包括：数据采集、哈希分区、写入 HyperLogLog、定期聚合与监控，并在必要时通过 PFMERGE 合并不同分区以得到全局视图。
# 日级去重统计落地
PFADD hll:day:20250101 user1
PFADD hll:day:20250101 user2
PFCOUNT hll:day:20250101
# 跨日聚合
PFMERGE hll:totals:20250101 hll:day:20250101 hll:day:20250102
PFCOUNT hll:totals:20250101
5.3 性能监控与容量调整
监控是确保落地稳定的关键环节，可以通过 MEMORY USAGE key 查看单个 HLL 的内存占用，并结合 PFCOUNT 的返回值评估误差对业务的影响。
MEMORY USAGE hll:day:20250101
PFCOUNT hll:day:20250101
INFO memory
在持续运行中，根据增长趋势动态调整寄存器数量 m（通过 p 值调整）和分片策略，以保持期望的误差范围与系统吞吐。
