在面临海量用户场景时，你会怎样基于 Redis 来完成独立访客数（UV）的统计？请阐述你的技术思路与具体实现方案。
考察说明
考察候选人对 Redis 不同数据结构特性的理解以及在统计大量用户唯一访问量场景下的选型与应用能力。
回答思路
- 【回答框架 1】对 UV 统计的核心要求是保证用户的唯一性。由此引出对 Redis 提供的多种候选数据结构的对比分析。
- 【回答框架 2】采用 Set 结构时，可直接利用其元素唯一特性，通过 SADD 添加用户 ID，SCARD 获取基数。该方案简单直观，但内存占用会随着用户数量线性增长，当用户量极大时可能产生可观的内存开销。
- 【回答框架 3】考虑到大规模场景下的内存效率，可选用 HyperLogLog。它通过概率算法估算不重复元素数量，标准误约为 0.81%，极大节省内存。添加元素用 PFADD，估算数量用 PFCOUNT，但结果为近似值，且无法直接获取具体用户列表。
- 【回答框架 4】若需在统计 UV 的同时支持更复杂的分析，可采用 Bitmap 技术。通过为每个可能用户分配一个位，使用位操作记录访问状态，计算 UV 时统计位为 1 的数量。其内存占用固定为最大用户编号对应的位数，适合用户编号相对连续且总量可控的场景。
- 【回答框架 5】综合对比：若允许近似统计且对内存要求苛刻，优先选 HyperLogLog；若需绝对精确且用户量在可接受内存范围内，选用 Set；Bitmap 更适合用户 ID 可映射为有序数值且量级较大的场景。实际需关注 Redis 单机内存限制，必要时可考虑集群方案。
- 【关键点 1】UV 统计的关键是确保用户唯一性识别。
- 【关键点 2】Redis Set 可提供精确的 UV 统计，通过 SADD 与 SCARD 实现。
- 【关键点 3】HyperLogLog 提供近似统计，内存占用极低，标准误约 0.81%，适合海量数据。
- 【关键点 4】Bitmap 可通过位数组记录用户访问，内存空间利用较高，但受限于用户 ID 的连续性。
- 【关键点 5】选择方案需权衡精确度、内存占用与功能需求。
- 【易错点 1】切勿使用基于字符串拼接的普通变量累加，因无法去重且实现复杂。
- 【易错点 2】关注 HyperLogLog 的近似性，若业务要求精确计数则不可采用。
- 【易错点 3】要注意 Redis 单实例内存限制，若数据量巨大需预先规划分片或集群方案。