生日悖论是啥？我用它省了上百G的内存

生日悖论: 是指在很多于 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} < 0.0001$，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的内存，其实也就是一台服务器，即使放到将来也就是少扩容几台服务器。对公司而言就是每月节省几千的成本，我司这种大厂实际上是不会在意这点钱的。不过即使这几千的成本最终不会转化成个人工资或者奖金，但像这种优化该作仍是得作。若是每一个人都本着 用最低的成本作一样事 的原则去作好每一件事，就我司这体量，一个月上千万的成本仍是能省下来的。

参考资料

1. 百度百科 生日悖论
2. 百度百科 UUID
3. 布隆过滤器(BloomFilter)原理 实现和性能测试
4. RedisBloom 基于redis的布隆过滤器实现

本文来自 https://blog.csdn.net/xindoo