2. Phantom
微博还有一种场景是“存在性判断”，比如某一条微博某个用户是否赞过、某一条微博某个用户是否看过之类的。这种场景有个很大的特点，它检查是否存在，因此每条记录非常小，比如 Value 用 1 个位存储就够了，但总数据量又非常巨大。比如每天新发布的微博数量在 1 亿条左右，是否被用户读过的总数据量可能有上千亿，怎么存储是个非常大的挑战。而且还有一个特点是，大多数微博是否被用户读过的存在性都是 0，如果存储 0 的话，每天就得存上千亿的记录；如果不存的话，就会有大量的请求最终会穿透 Cache 层到 DB 层，任何 DB 都没有办法抗住那么大的流量。
假设每天要存储上千亿条记录，用原生的 Redis 存储显然是不可行的，因为原生的 Redis，单个 KV 就占了 65 个字节，这样每天存储上千亿条记录，需要增加将近 6TB 存储，显然是不可接受的。而用上面提到的微博自研的 CounterService 来存储的话，一个 Key 占 8 个字节，Value 用 1 个位存储就够了，一个 KV 就占大约 8 个字节，这样每天存储上千亿条记录，需要增加将近 800GB 存储。虽然相比于原生的 Redis 存储方案，已经节省了很多，但存储成本依然很高，每天将近 1TB。
所以就迫切需要一种更加精密的存储方案，针对存在性判断的场景能够最大限度优化存储空间，后来我们就自研了 Phantom。
就像下图所描述的那样，Phantom 跟 CounterService 一样，采取了分 Table 的存储方案，不同的是 CounterService 中每个 Table 存储的是 KV，而 Phantom 的每个 Table 是一个完整的 BloomFilter，每个 BloomFilter 存储的某个 ID 范围段的 Key，所有 Table 形成一个列表并按照 Key 范围有序递增。当所有 Table 都存满的时候，就把最小的 Table 数据清除，存储最新的 Key，这样的话最小的 Table 就滚动成为最大的 Table 了。
下图描述了 Phantom 的请求处理过程，当一个 Key 的读写请求过来时，先根据 Key 的范围确定这个 Key 属于哪个 Table，然后再根据 BloomFilter 的算法判断这个 Key 是否存在。
这里我简单介绍一下 BloomFilter 是如何判断一个 Key 是否存在的，感兴趣的同学可以自己搜索一下 BloomFilter 算法的详细说明。为了判断某个 Key 是否存在，BloomFilter 通过三次 Hash 函数到 Table 的不同位置，然后判断这三个位置的值是否为 1，如果都是 1 则证明 Key 存在。
来看下面这张图，假设 x1 和 x2 存在，就把 x1 和 x2 通过 Hash 后找到的三个位置都设置成 1。
再看下面这张图，判断 y1 和 y2 是否存在，就看 y1 和 y2 通过 Hash 后找到的三个位置是否都是 1。比如图中 y1 第二个位置是 0，说明 y1 不存在；而 y2 的三个位置都是 1，说明 y2 存在。
