共计 2282 个字符，预计需要花费 6 分钟才能阅读完成。
生日悖论: 是指在不少于 23 个人中至少有两人生日相同的概率大于 50%。例如在一个 30 人的小学班级中，存在两人生日相同的概率为 70%。对于 60 人的大班，这种概率要大于 99%。从引起逻辑矛盾的角度来说，生日悖论并不是一种“悖论”。但这个数学事实十分反直觉，故称之为一个悖论。
生日悖论是有个有趣的概念，但这和我省上百 G 的内存有什么关系？
背景
首先介绍下背景，工作中我负责了一个广告数据系统，其中一个功能就是对同一次请求的广告曝光去重，因为我们只需要知道这次请求这个广告的一次曝光就行了，那些同一次请求产生的重复曝光记录下来没有意义，而且还耗会增加我们的存储成本。所以这里就需要有个逻辑去判断每条新到的曝光是否只之前已经记录过的，旧的方案是在 redis 中存储请求唯一标识 (uuid) 和广告 ID(adid)，每次数据过来我们就看 redis 里有没有 uuid+adid 这个 key，有就过滤掉，没有就不过滤并在 redis 记录下来已出现。
问题就来了，redis 记录的这份数很大(两天数据超过 400G)，而且随着我们业务的增长，我们的 Redis 集群快盛不下了…… 当然花钱加机器是最简单的方式，毕竟能用钱解决的问题都不是问题。而优秀的我，为了替公司省钱，走了优化的路。
如何优化？
首先可以肯定的是数据条数不会少，因为业务量就在那里，所以减少数据量的这条路肯定行不通。那是否可以减少每条数据的长度呢？
我们再来看下 redis 存储的设计，如下图：
这样下来一条记录总共用了 45 个字节，这个长度能不能缩短？当然能，我们可以截取部分 UUID，但这样又带来一个新的问题，截取 UUID 会增加重复的概率，所以首先搞清楚怎么截取，截多少？
这里我们用的是随机 UUID，这个版本中有效二进制位是 122 个，所以总共有 $2^{122}$ 个有效的 UUID。因为是随机产生的所以肯定有重复的概率，UUID 重复的概率有多少？要算这个重复概率，光有 $2^{122}$ 这个总数还不行，还得知道你拥有的 UUID 个数。我把这个问题具体下，求：在 $2^{36}$ 个 UUID 中有重复的概率是多少？
$$
p(n) \approx 1-e^{-\frac{n^{2}}{2 x}}
$$
这不就是生日悖论的数据放大版吗？当然这个概率可以根据上面公式计算，其中 x 是 UUID 的总数 $2^{122}$，n 是 $2^{36}$，引用百度百科的数据，概率为 $4 *10^{-16}$ 这比你出门被陨石撞的概率还小很多。
| n | 几率 |
|---|---|
| 2^36 | 4 x 10^-16 |
| 2^41 | 4 x 10^-13 |
| 2^46 | 4 x 10^-10 |
另外，从上面的公式也可以看出，在 n 固定的时候，随着有效二进制位的减少，概率 p 就会增加。回到我们广告去重的场景下，每天最大请求数 n 是基本固定的，而且我们也可以忍受一个较小的概率 p（小于万分之一），然后就可以反推出这个 x 有多大。
其实只要 $\frac{n^{2}}{2 x} >= 10$，p 就会小于万分之一。我可以从历史数中统计出 n 的大小，然后计算出 x，再留一定的 buff，然后根据 n 的大小重新设计了 redis 的 key。(因为涉及公司数据，这里不公布中间计算过程)
新设计
最终有效位我选取了 40 个有效二进制位 (10 个 16 进制位)，但我并没有直接截取 UUID 的前 10 位，因为 UUID 的前几位和时间有关，随机性并不强。我选择将整个 UUID 重新 md5 散列，然后截取 md5 的前 10 位，然后拼接 adId 形成最终的 key，如下图：
明显看出，key 的长度缩小了一半，总体上能节省至少 50% 的存储空间。备注：但其实我们 redis 的具体存储实现和上文描述略有差异，为了不喧宾夺主上文特意对实际实现做了简化描述，所以最终实际没有省一半以上的内存，只省了 35% 左右。
如何进一步优化？
实际优化就到这了，但其实还是不够极致，其实 adId 中也包含大量的冗余信息也可以截取，其实我们可以承受更高的重复率，其实我们可以把 redis 数据存储时间设的更短一些……
上面几种方法都可以进一步优化，但存储空间不会有量级级别的减少，而下面一种方式，可以将存储空间减小 99% 以上。
布隆过滤器(BloomFilter)
关于布隆过滤器的原理，可以参考我之前写的一篇文章布隆过滤器 (BloomFilter) 原理 实现和性能测试。布隆过滤器完全就是为了去重场景设计的，保守估计我们广告去重的场景切到布隆过滤器，至少节省 90% 的内存。
那为什么我没有用布隆过滤器，其实还是因为实现复杂。redis 在 4.0 后支持模块，其中有人就开发设计了布隆过滤器的模块 RedisBloom，但无奈我们用的 redis 还是 3.x 版本！我也考虑过应用端基于 redis 去实现布隆过滤器，但我们应用端是个集群，需要解决一些分布式数据一致性的问题，作罢。
结语
其实我们 redis 的具体存储实现和上文描述略有差异，为了不喧宾夺主上文特意对实际实现做了简化描述，所以最终实际没有省一半以上的内存，只省了 35% 左右。
最终 400G+ 优化后能减少 100 多 G 的内存，其实也就是一台服务器，即便放到未来也就是少扩容几台服务器。对公司而言就是每个月节省几千的成本，我司这种大厂其实是不会在乎这点钱的。不过即便这几千的成本最终不会转化成我的工资或者奖金，但像这种优化该做还是得做。如果每个人都本着 用最低的成本做同样事 的原则去做好每一件事，就我司这体量，一个月上千万的成本还是能省下来的。
参考资料
- 百度百科 生日悖论
- 百度百科 UUID
- 布隆过滤器 (BloomFilter) 原理 实现和性能测试
- RedisBloom 基于 redis 的布隆过滤器实现
本文来自 https://blog.csdn.net/xindoo
