Redis系列选型咨询：海量键存在性校验及内存概率计算问题

1. Redis Stack部署所需内存大小 #

核心开销来自布隆过滤器，结合你的业务情况：

• 按当前50万唯一键+工作日波动，建议按100万预期最大元素数预留冗余。
• 用布隆过滤器内存公式计算：m = -(n * ln(p)) / (ln(2))²（n为预期元素数，p为碰撞概率）。比如取碰撞概率1%，算出来约1.2MB比特内存，换算后不到2MB。
• 若仅用布隆过滤器，Redis Stack本身的额外内存可忽略，准备2-4MB完全足够；要是还要用到Redis Search、JSON等其他组件，再根据实际需求叠加内存即可。

2. 可接受碰撞概率及计算方法 #

• 碰撞概率完全由业务容忍度决定：
  • 若误判（键不存在却返回存在）会导致漏处理交易这类严重问题，需把概率压到**0.001%（1e-5）**甚至更低；
  • 若误判影响较小（比如仅跳过重复检查），0.1%-1%的概率都可接受。
• 计算步骤：
  1. 先确定两个核心值：预期最大元素数n、可接受碰撞概率p
  2. 计算所需比特数m：m = -(n * ln(p)) / (ln(2))²
  3. 计算最优哈希函数数量k：k = (m/n) * ln(2)，取整数即可
     最终理论最低碰撞概率可通过公式验证：p = (1 - e^(-k*n/m))^k

3. 其他合适方案 #

• Redis Set：直接将所有唯一键存入Set，用SISMEMBER命令判断存在性。优点是100%准确无碰撞；缺点是内存比布隆过滤器高，50万平均10字节的键仅占5MB，对现代服务器来说几乎无压力，适合绝对不能接受误判的场景。
• Redis HyperLogLog：主打统计唯一元素的基数（数量），虽能间接判断“是否可能存在”，但不如布隆过滤器直接，适合同时需要统计每日唯一键数量的场景，单独做存在性判断没必要。
• Redis Search：若你的键本身有结构化属性，或后续需做搜索查询，用它的索引做存在性判断也可行，但内存开销比前两者大，单纯做存在性判断属于大材小用，仅推荐本来就要用它做其他业务操作的情况。

内容的提问来源于stack exchange，提问作者pintekus