直接注入StringRedisTemplate调用opsForHyperLogLog()即可使用，无需额外配置Bean；注意Spring Data Redis 2.6+才默认支持RESP3协议，避免大基数返回值截断；序列化器必须设为StringRedisSerializer，禁用JdkSerializationRedisSerializer以防ClassCastException。
HyperLogLog在Spring Boot里怎么初始化
直接用 StringRedisTemplate 的 opsForHyperLogLog() 就行，不需要额外建 Bean。它底层自动适配 Redis 原生命令 PFCOUNT/PFADD，但注意：Spring Data Redis 2.6+ 才默认启用 RESP3 协议，否则某些大基数场景下返回值可能被截断（比如实际 1200 万，显示成 2147483647）。
常见错误是手动 new RedisTemplate 并设错序列化器——HyperLogLog 只存二进制指纹，必须用 GenericJackson2JsonRedisSerializer 或 StringRedisSerializer，千万别用 JdkSerializationRedisSerializer，会报 ClassCastException: byte[] cannot be cast to java.lang.String。
- 推荐配置方式：直接注入
StringRedisTemplate，调用opsForHyperLogLog() - 如果用了自定义
RedisTemplate，确保setValueSerializer(new StringRedisSerializer()) - 集群模式下，key 必须带 hash tag（如
uv:202405:{order}），否则跨 slot 写入失败
千万级 UV 写入时怎么避免阻塞和倾斜
PFADD 本身是 O(1) 时间复杂度，但高频写入（比如每秒 5w+ 用户访问）时，单个 key 会成为热点，尤其在 Redis 集群中容易打满某个节点 CPU。不能把所有 UV 都往一个 key（如 uv:total）里塞。
正确做法是按时间维度分片 + 用户标识哈希取模：
- 按天分 key：用
uv:20240520统计当日 UV；需要全量去重时再用PFMERGE合并多日数据 - 按用户 ID 哈希分桶：比如
PFADD uv:20240520:%d userId，其中%d = userId.hashCode() % 100，最后用PFMERGE聚合 100 个 key - 注意：分桶数别设太大（>1000），否则
PFMERGE内存开销飙升，单次合并可能卡住主线程
实测：100 分桶 + 每日 800 万 UV，单 key 平均大小约 12KB，合并耗时 PFADD 延迟从 0.2ms 涨到 8ms+。
怎么准确读取千万级 UV 值而不翻车
PFCOUNT 返回的是估算值，误差率约 0.81%，对千万级来说误差在 ±8 万左右。如果你看到返回 2147483647，八成是序列化器配错了或者用了老版本客户端（RESP2 下整数溢出）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键检查点：
- 确认 Redis 服务端版本 ≥ 2.8.9（
HyperLogLog是 2.8.9 引入的） - Spring Boot 项目里检查
spring-data-redis版本：2.6.x 起默认用 RESP3，之前版本需显式配置redis.client.config.setProtocol(ProtocolVersion.RESP3) - 读取代码别写成
template.opsForValue().get("uv:20240520")——这是读字符串，要用template.opsForHyperLogLog().size("uv:20240520")
示例正确调用：
long uv = stringRedisTemplate.opsForHyperLogLog()
.size("uv:20240520"); // 返回 long，不是 String
为什么 UV 突然不涨了或反复归零
最常见原因是 key 过期策略误伤。如果给 uv:20240520 设了 TTL，但业务还在持续写入，Redis 可能在某次 PFADD 前已删掉该 key，导致每次写都新建空结构，UV 永远只算最新一批用户。
还有两个隐蔽坑：
- 用户标识用了动态值（如带时间戳的 token），导致同一用户被当成多人：必须用稳定 ID（
userId、openId、设备 fingerprint 等） - 前端埋点重复上报未去重，后端没做幂等校验，
PFADD虽然幂等，但上游刷量会让 key 过早达到精度上限（约 2^64），之后再加也不变 - 集群环境下，如果 key 不带 hash tag 且用了
set类命令混用，可能因 slot 迁移导致部分数据丢失
查问题优先看 Redis 日志里的 expire 记录，再用 PTTL uv:20240520 确认 key 是否存活。
分片、序列化、过期控制这三块不抠细节，千万级 UV 看似能跑，实际每天悄悄少算几十万都很正常。
