单key业务，数据库水平切分架构实践

为什么80%的码农都做不了架构师？>>>   

以用户中心为例：User(uid,login_name,passwd,nick_name,age,sex,email,phone,...)
一、问题：
1、如何实施水平切分
2、切分后常见的问题
3、常见的优化思路

二、常见切分算法
1、范围法
优点：
1）切分策略简单，根据uid，按照范围就可以定位到数据库
2）扩容简单，如果容量不够，只需要增加数据库即可
缺点：
1）uid 必须满足递增的属性
2）数据量不均匀，某一段时间内，数据都在一个库上
3）请求量不均匀，一般来说新生成的数据活跃度高，导致服务器利用率不均衡
2、哈希法
优点：
1）切分策略简单
2）数据量均匀
3）请求量均匀
缺点：
1）扩容麻烦，如果容量不够，重新哈希可能会导致数据迁移

三、切分后出现的问题
根据非uid属性上的查询，如何解决。例如login_name,phone等

四、非uid属性上查询业务分析
一般有两类业务需求
1、用户侧，用户访问
用户登录：根据login_name/email/phone查询 用户的实体，1%的需求
用户信息查询：根据uid查询用户实体，99%的需求
用户侧的查询基本是单条查询，访问量较大，服务要求高可用，并且对一致性要求较高
2、运营侧，后台访问
将login_name/email/phone作为查询条件，分页统计，由于是内部系统，访问量低，
对可用性要求不高，一致性也要求不高

五、问题解决的架构思想
针对用户侧：应该采用“建立非uid属性到uid的映射关联”
针对运营侧：应该采用“前台和后台分离”

六、用户侧最佳实践
1、“索引表法”
建立索引表记录    login_name->uid的映射关系，先根据login_name查询到uid，然后根据
uid路由到库，索引表属性较少，一般不需要分库，但是如果数据量很大，也可以login_name
分库。潜在不足，多一次数据库查询，性能下降一倍
2、“缓存关联法”    
访问索引表性能较低，可以把映射关系放到缓存中性能更佳
七、运营侧的最佳实践
前台，后台系统web、service、db分离解耦，避免后台低效查询导致前台抖动
可以采用 数据冗余设计方式
可以采用“外置索引”（例如SE搜索系统）或者“大数据处理”（例如hive）来满足后台变态的查询
 

转载于:https://my.oschina.net/riseee/blog/1552007