直接用PFCOUNT+PFMERGE无法满足原子性去重统计需求，因两步执行间可能被并发修改导致结果不一致；Redis事务不能保证中间状态隔离，而Lua脚本可原子执行合并与统计。
为什么直接用 PFCOUNT + PFMERGE 无法满足原子性去重统计需求
当你需要对多个 key 的 HyperLogLog 数据做「先合并、再统计」，又要求整个过程不可被并发打断时，PFMERGE 和 PFCOUNT 分两步执行是危险的。中间可能有其他客户端插入新数据、甚至覆盖目标 key，导致结果不一致。Redis 的事务（MULTI/EXEC）也不能保证 PFMERGE 后立刻 PFCOUNT 的原子性——因为 EXEC 只保证命令排队执行，不保证中间状态对外不可见；而 Lua 脚本在 Redis 单线程中运行，天然具备原子性。
用 Lua 脚本封装 PFMERGE + PFCOUNT 的正确写法
核心是把合并与计数压进一个脚本，且避免副作用（比如意外修改源 key）。注意：Lua 中不能直接调用 PFMERGE 的返回值，必须显式用 redis.call("PFMERGE", ...) 执行合并，再单独调用 redis.call("PFCOUNT", ...) 获取结果。
- 脚本接收至少两个参数：
KEYS[1]作为临时合并目标（建议用带前缀的随机名或ARGV[1]指定），KEYS[2..n]是待合并的原始 HLL key - 务必检查
KEYS数量 ≥ 2，否则PFMERGE会报错ERR wrong number of arguments - 不要复用业务 key 做临时目标（如直接用
KEYS[1] = "user:active:hll"），否则会污染原始数据；应生成唯一临时 key，用redis.call("DEL", tmp_key)清理（或依赖 TTL） - 示例脚本：
local tmp_key = KEYS[1]
redis.call("DEL", tmp_key)
redis.call("PFMERGE", tmp_key, unpack(KEYS, 2, #KEYS))
local count = redis.call("PFCOUNT", tmp_key)
redis.call("DEL", tmp_key) -- 立即清理，避免残留
return count调用方式：redis-cli --eval hll_merge_count.lua tmp:hll , user:hll:202401 user:hll:202402 user:hll:202403
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
PFMERGE 在 Lua 中的坑：unpack 与空 key 处理
如果传入的某个 KEYS[i] 实际不存在（即对应 key 在 Redis 中未创建），PFMERGE 会静默忽略它——这本身是正常行为，但容易误以为数据丢了。更危险的是，当 KEYS 只有一个（即只有目标 key，无源 key），unpack(KEYS, 2, #KEYS) 返回空，PFMERGE 就变成 PFMERGE tmp_key，触发错误。
- 安全做法：在脚本开头加校验
if #KEYS - 若需容忍空源 key，可先用
redis.call("EXISTS", key)过滤出真实存在的 key，再构造新数组传给PFMERGE - Redis 7.0+ 支持
PFDEBUG，但 Lua 中不可用；调试时可用redis.log(redis.LOG_WARNING, "merged keys: ", #KEYS)输出日志（仅开发环境）
性能和内存要注意的边界情况
HyperLogLog 单个 key 最大内存约 12KB，但 PFMERGE 是浅合并（只合并寄存器），不产生新内存分配；真正耗资源的是后续 PFCOUNT 的估算计算——它本身是 O(1)，但若合并后基数极大（>1e9），误差率仍可控（标准误差 0.81%），无需担心精度崩坏。
- 高频调用该脚本时，避免每次生成新临时 key —— 可复用固定 key（如
hll:merge:tmp），但必须加锁或确保单线程调用，否则并发写会冲突 - 如果原始 HLL key 数量动态变化（比如从 ZSET 或 SCAN 结果中获取），应在客户端拼好
KEYS列表再传入，不要在 Lua 里做 SCAN（Lua 不支持 SCAN） - 脚本总执行时间应 BUSY 错误，此时需改用异步方案（如先
PFMERGE到持久化 key，再另起任务PFCOUNT）
临时 key 的生命周期管理最容易被跳过——不是所有团队都记得加 DEL，也不是所有场景都适合设 TTL；漏掉这步，积累的临时 key 会悄悄吃掉内存。
