用户中心，1亿数据，架构如何设计？( 二 ) _架构

运营侧的查询，基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格。
对于这两类不同的业务需求，应该使用什么样的架构方案来解决呢？
总的来说，针对这两类业务需求，架构设计的核心思路为：
（1）用户侧，采用“建立非uid属性到uid的映射关系”的架构方案；
（2）运营侧，采用“前台与后台分离”的架构方案；
用户侧，如何实施“建立非uid属性到uid的映射关系”呢？
常见的方法有四种：
（1）索引表法；
（2）缓存映射法；
（3）生成uid法；
（4）基因法；
接下来，咱们一一介绍。
什么是，索引表法？
索引表法的思路是：uid能直接定位到库，login_name不能直接定位到库，如果通过login_name能查询到uid，问题便能得到解决。
具体的解决方案如下：
（1）建立一个索引表记录login_name与uid的映射关系；
（2）用login_name来访问时，先通过索引表查询到uid，再通过uid定位相应的库；
（3）索引表属性较少，可以容纳非常多数据，一般不需要分库；
（4）如果数据量过大，可以通过login_name来分库；
索引表法，有什么缺点呢？
数据访问，会增加一次数据库查询，性能会有所下降。
什么是，缓存映射法？
缓存映射法的思路是：访问索引表性能较低，把映射关系放在缓存里，能够提升性能。
具体的解决方案如下：
（1）login_name查询先到cache中查询uid，再根据uid定位数据库；
（2）假设cache miss，扫描所有分库，获取login_name对应的uid，放入cache；
（3）login_name到uid的映射关系不会变化，映射关系一旦放入缓存，不会更改，无需淘汰，缓存命中率超高；
（4）如果数据量过大，可以通过login_name进行cache水平切分；
缓存映射法，有什么缺点呢？
仍然多了一次网络交互，即一次cache查询。
什么是，生成uid法？
生成uid法的思路是：不进行远程查询，由login_name直接得到uid 。
具体的解决方案如下：
（1）在用户注册时，设计函数login_name生成uid，uid=f(login_name)，按uid分库插入数据；
（2）用login_name来访问时，先通过函数计算出uid，即uid=f(login_name)再来一遍，由uid路由到对应库；
生成uid法，有什么缺点呢？
该函数设计需要非常讲究技巧，且有uid生成冲突风险。
画外音：uid冲突，是业务无法接受的，故生产环境中，一般不使用这个方法。
什么是，基因法？
基因法的思路是：不能用login_name生成uid，但可以从login_name抽取“基因”，融入uid中。
假设分8库，采用uid%8路由，潜台词是，uid的最后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的“基因” 。
具体的解决方案如下：

文章插图

（1）在用户注册时，设计函数login_name生成3bit基因，login_name_gene = f(login_name)，如上图粉色部分；
（2）同时，生成61bit的全局唯一id，作为用户的标识，如上图绿色部分；
（3）接着把3bit的login_name_gene也作为uid的一部分，如上图屎黄色部分；
（4）生成64bit的uid，由id和login_name_gene拼装而成，并按照uid分库插入数据；
（5）用login_name来访问时，先通过函数由login_name再次复原3bit基因，login_name_gene = f(login_name)，通过login_name_gene%8直接定位到库；
画外音：基因法，有点意思，在分库时经常使用。
用户侧，如何实施“前台与后台分离”的架构方案呢？
前台用户侧，业务需求基本都是单行记录的访问，只要建立非uid属性login_name到uid的映射关系，就能解决问题。
后台运营侧，业务需求各异，基本是批量分页的访问，这类访问计算量较大，返回数据量较大，比较消耗数据库性能。
此时的架构，存在什么问题？
此时，前台业务和后台业务共用一批服务和一个数据库，有可能导致，由于后台的“少数几个请求”的“批量查询”的“低效”访问，导致数据库的cpu偶尔瞬时100%，影响前台正常用户的访问（例如，登录超时）。
画外音：本质上，是系统的耦合。