适合，但只适合“去重后的粗略设备数”，误差率约0.81%，用12KB内存统计上亿ID；不支持反查、删除、交并差（Redis 7.0+仅支持简单合并）；适用大盘监控，不适用精准去重或ID对齐。
HyperLogLog 适合统计广告曝光的设备数吗？
适合，但只适合“去重后的粗略设备数”，不是精确值。它用 12KB 固定内存就能统计上亿个设备 ID，误差率约 0.81%，代价是无法反查具体有哪些设备、不能删除单个设备、不支持交并差（Redis 7.0+ 才支持 PFCOUNT + PFMERGE 做简单合并）。
常见错误现象：PFCOUNT 返回值远低于实际请求量，误以为漏统计；或拿 PFADD 当集合用，反复塞同一设备却期待能查出该设备是否已存在——它根本不存原始数据。
- 适用场景：每日/每小时广告曝光的「独立设备触达数」大盘监控，不要求精确到个位
- 不适用场景：需要剔除测试机、识别重复点击、做设备黑名单、或需与用户画像系统对齐 ID 列表
- 参数差异：
PFADD ad:expo:20240520 device_abc123每次加一个设备 ID；多个可一次加：PFADD ad:expo:20240520 device_abc123 device_def456
怎么避免把同设备多次曝光算成多次独立触达？
关键在设备标识的稳定性和粒度。用 IP 或 User-Agent 会严重高估（NAT 共享 IP、浏览器指纹漂移）；用 广告 SDK 生成的 AAID/IDFA/IDFV 更准，但 iOS 14+ 限制 ATT 后获取率下降；Web 端可用 fingerprintjs 生成设备指纹，但隐私合规风险需自行评估。
实操建议：
- 服务端记录曝光时，优先取请求中带的
device_id字段（由客户端 SDK 上报）， fallback 到cookie中的_did（需提前种好且未过期） - 绝不直接用
request.remote_addr或UA做PFADD输入 - 如果客户端未上报且无 cookie，宁可丢弃这次计数，也不用降级方案污染 HyperLogLog 数据
如何验证 PFADD 是否真生效、没被误覆盖或限流？
Redis 不会静默失败，但常见坑是：命令发错 key、客户端自动 trim 字符串、或中间件（如 Twemproxy）不支持 PF* 命令导致报错被吞。
验证步骤：
- 先用
redis-cli手动测：PFADD test_hll abc def abc→ 返回(integer) 1表示新增，(integer) 0表示已存在 - 立刻
PFCOUNT test_hll，应返回2（去重后） - 检查客户端日志里是否出现
ERR unknown command `PFADD`（说明 Redis 版本 - 注意：某些云 Redis（如阿里云老版本）默认禁用
PF*命令，需在控制台手动开启
和 SET 相比，为什么不用 SADD + SCARD？
内存和性能差距巨大。1 亿设备 ID 存 SET 至少占 2–3GB 内存（字符串编码开销大），而 HyperLogLog 永远只占 12KB；SADD 写入延迟随基数线性增长，PFADD 是 O(1)。
但代价明确：
- 无法做
SISMEMBER查询某设备是否已计入 - 不能用
EXPIRE给 HyperLogLog 单独设过期（得靠 key 层面的 TTL，比如SETEX ad:expo:20240520 86400 ...） - 如果业务要求“当天曝光设备数”且每天归零，必须主动用
DEL ad:expo:20240520或用日期作为 key 后缀，别指望自动清理
真正容易被忽略的是：HyperLogLog 的误差不是均匀分布的，小基数（PFCOUNT 值较真。等设备量上到万级，误差才稳定在 0.8% 左右。
