问题： 微博有11亿的用户，其中大约50万是蓝V用户，用户用uid标示，试设计一套架构，判断一个用户是否是蓝V，画出架构图，并给出关键算法。要求消耗的内存最小，效率最高，同时能够适应蓝V用户的动态增减。
海量数据问题的处理 个人感觉：这个题不仅考察了基础，同时又有工程上的引申
- 思路：
（1）发现这是个类似redis的架构，KV（key-value）的结构：key是uid，（uid应是内部系统中用来表示用户的user id，是一个字符 串）；value用一个位表示即可，0或1，1表示是蓝V用户
（2）索引与hash，在涉及到查找的时候，可以使用一些数据结构中的知识，如红黑树，字典树，跳表，hash之类的，在这里，我考虑了一下，hash的效率是最高的，虽然它有大量的key是无法命中的，也会浪费一些存指针的空间，但是在瞬间性判断是否是该key的性能上是高的
（3）多机的可扩展性，由于数据量太大，单机的话内存可能无法hold住，这时候可以利用多机的可扩展性来解决，貌似涉及到分布式中的一致性哈希问题，这个不太熟悉，查阅后发现可以进行数据的动态处理的。
- 算法： 1、内存消耗最小 （1） 可以将所有的蓝V的uid通过hash变成一个key来表示，其余的非蓝V数据不存，这样的话在查找的时候直接就来判断是否命中 key，命中了那么就是蓝V； （2） 对于key，可以采用Bit-map和Bloom Filter来优化内存空间的消耗。由于采用了Bit为单位来存储数据，因此在存储空间方面， 可以大大节省。 2、效率最高 （1） 涉及到效率，就很容易想到hash和查找树，所以这个key很关键，在这里我采用了hash，虽然它有大量的key是无法命中的， 也会浪费一些存指针的空间，但是在瞬间性判断是否是该key的性能上是高的 （2） 关于uid，这是内部系统中用来表示用户的user id，是一个字符串，应该存在分级或者分布式存储的规律，比如省市级的数据分布区域划分，这样的话就可以减少查找的范围，优化效率 3、适应性增减 （1）这里由于数据量太大，单机下内存无法hold住，所以涉及到了多机的可扩展性，这里关于增加，可以采用一致性哈希来进行机器的平缓的添加，减少的话貌似需要根据数据量来先分配内存，具体的细节待思考。
- 涉及知识点： 一、Bloom Filter 基础操作 位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。 扩展性问题 Bloom filter将集合中的元素映射到位数组中，用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中。Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter，从而支持了元素的删除操作。Spectral Bloom Filter（SBF）将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率 二、hash索引 哈希查找是通过计算数据元素的存储地址进行查找的一种方法。哈希查找的操作步骤： ⑴用给定的哈希函数构造哈希表； ⑵根据选择的冲突处理方法解决地址冲突; ⑶在哈希表的基础上执行哈希查找。 哈希查找步骤为： 设哈希表为HST[0~M-1]，哈希函数取H（key），解决冲突的方法为R（x）； Step1 对给定k值，计算哈希地址 Di=H（k）；若HST为空，则查找失败； 若HST=k，则查找成功；否则，执行step2（处理冲突）。 Step2 重复计算处理冲突的下一个存储地址 Dk=R（Dk-1），直到HST[Dk]为 空，或HST[Dk]=k为止。若HST[Dk]=K，则查找成功，否则查找失败。 三、redis 基于redis分布式缓存兑现
