Redis如何统计UV，Set去重最高效

SADD统计UV最直接因自动去重且O(1)时间复杂度；适用单日/稳定ID场景，禁用INCR/HSET误计；key须按时间窗口和业务维度设计并配EXPIRE；获取UV仅用SCARD，禁用SMEMBERS或KEYS；跨周期合并应预建周期key或离线计算。

为什么用 SADD 统计 UV 最直接

因为每个用户 ID 写入 SET 时，SADD 自动忽略重复值，底层哈希表保证 O(1) 去重 —— 不需要你写 if 判断是否存在，也不依赖外部逻辑兜底。

常见错误现象：INCR 或 HSET 误用：有人用 INCR uv:20240601 统计，结果把 PV 当 UV；或者用 HSET 存用户 ID + 时间戳，却忘了查重，导致重复计数。

• 适用场景：单日 UV、按设备 ID / 登录 ID / 匿名 token 统计（注意 ID 必须稳定且有业务意义）
• 不适用场景：需要实时精确到秒级去重的长周期 UV（如 30 天去重），SET 占内存高，建议用 HyperLogLog
• 性能影响：1000 万用户 ID 的 SET 约占 200–300MB 内存，比 PFADD 高 5–10 倍，但精度 100%

SADD 的 key 设计决定统计粒度

key 名不是随便拼的，它直接绑定时间窗口和业务维度。比如 uv:day:20240601 和 uv:hour:2024060114 是两个完全独立的集合，互不影响。

容易踩的坑：uv:user_id 这种 key 意味着全量用户塞进一个 set，无法分片、无法过期、无法清理 —— 一旦写错，内存只增不减。

• 推荐格式：uv:{time_window}:{scope}，例如 uv:day:20240601:web（Web 端单日 UV）
• 必须配 EXPIRE：写完 SADD 紧跟 EXPIRE uv:day:20240601 86400，否则 key 永久存在
• 避免中文或空格：uv:日活:20240601 会导致部分客户端解析异常，一律用英文+数字+下划线

如何安全地获取当日 UV 数量

SCARD 是唯一正确方式。别用 SMEMBERS 拉全量再 count，数据一过万就卡顿甚至触发慢日志。

常见错误现象：用 KEYS uv:day:* 扫所有日期 key 再逐个 SCARD —— 这在生产环境属于高危操作，阻塞主线程。

• 正确做法：应用层维护日期变量，明确调用 SCARD uv:day:20240601
• 批量查询多个日期？用 pipeline 封装多个 SCARD，不要用 KEYS 或 SCAN 做元数据扫描
• 注意返回值类型：SCARD 返回整数，若 key 不存在返回 0，不是 nil —— 别在代码里判 nil 导致逻辑跳过

跨天/跨周期 UV 合并的现实约束

Redis 原生命令不支持两个 SET 取并集后直接返回基数，SUNIONSTORE 会写新 key，SUNION 会把全部元素传回客户端 —— 100 万用户 ID 就是几 MB payload，网络和内存双开销。

真正能落地的方案只有两种：要么提前规划好周期 key（如用 uv:week:2024W23 单独维护），要么导出到离线系统用 Spark/Hive 计算。

• 别在 Redis 里做 SUNION + SCARD 组合：一次请求可能耗时数百毫秒，且不可缓存
• 如果必须运行时合并，用 SUNIONSTORE tmp:uv:merge uv:day:20240601 uv:day:20240602，再 SCARD，最后 DEL tmp:uv:merge —— 但要注意并发写冲突
• 更稳的做法：每天凌晨用 Lua 脚本原子化地把昨日 key merge 到周 key 中，避免白天查时临时计算

UV 统计看着简单，难点从来不在加法，而在 key 生命周期管理、内存水位预估、以及跨周期合并时对 Redis 特性的误判 —— 很多人卡在“以为 SADD 写进去就完了”，其实后面三步才是真功夫。