数据库架构设计（二）——单Key业务无限容量

今天说一说单Key业务无限容量的数据库架构设计方案。

首先什么是单Key业务，就好像用户中心业务，主要提供用户注册、登录、信息查询和增删改的服务，核心数据为：User(uid,loginName,passwd,nickName...)

一、水平切分方法

利用uid进行水平切分分为两类方法：一个是范围法，一个是Hash法

1、范围法：以用户中心uid为划分依据，按顺序切分到多个数据库实例上，例如：

user-db1：存储0到1千万的uid数据

user-db2：存储1到2千万的uid数据

优点：策略和扩容简单，能够按照范围快速定位数据库实例

缺点：uid必须为递增规则，数据量不平均，请求也会因为活跃度问题而造成服务器利用率不平衡

2、Hash法：根据hash取模来进行数据水平切分，例如：

user-db1：存储uid取模得1的uid数据

user-db2：存储uid取模得0的uid数据

优点：切分策略简单，数据量和请求量均衡。

缺点：扩容问题突出，如果增加新库，那么会导致数据迁移，要考虑平滑迁移。

二、业务需求

一般用户中心根据前后台分为两部分需求：

前台：根据登录名loginName，登录后为uid查询用户信息，而每次查询用户都为单行数据，并发高，吞吐量大，时延要求敏感。

后台：有多类条件和展示规则，并且要求分页、order by、offset、limit，并发低，时延要求不敏感

三、前后台最佳实践

用户前台业务需求架构不变，产品后台独立建立系统来支持，解除两者之间耦合：

1、可以去掉service层，web端之间访问dao层

2、不需要反向代理

3、通过MQ或者线下来异步同步前台用户数据

4、数据量如果超大，可以使用更高延时的“索引外置”或“HIVE”的设计方案，例如ES、Solr、HBase等

四、前台用户名登录定位方法

因为uid能直接定位到库，但是用户名不可以直接定位，可以通过用户名来查询uid，再定位数据库。一共有四类方法：

1、映射表法

建立索引表：t_map(loginName,uid)，用loginName来访问，通过索引查询到uid，再定位库。

2、缓存映射表法

和第一种方法同理，将映射关系放到缓存中，例如memache、redis等

3、loginName生成uid

用户注册时，设计函数：f(loginName)=uid，再按照uid分库插入数据，这样，在loginName访问时，可以按照函数得到uid，再定位数据库，缺点就是此类函数要考虑uid冲突风险

4、基因法

登录名生成基因值再放到uuid中。

1、用户注册时，设计函数根据loginName生成3bit基因

2、同时生成61bit的全局唯一id

3、再把3bit的loginName基因作为uid的一部分，生成64bit的uid，并按照uid分库插入数据

4、loginName访问时，根据函数复原3bit基因，通过loginName基因%8定位到库