搬运贴 - 水平分表分库整理

Posted 2020-12-16 lanse1993

 

整理自：https://mp.weixin.qq.com/s/8KTK_Bz8netP6R5MNSKeFw

搬运贴，如果有侵权请联系删除

• 场景：用户注册登录，用户中心服务查询
• 问题：当数据量越来越大，例如达到1亿注册量时，库无法承载所有的数据，此时需要对数据库进行水平切分。

 

---

 

常见的水平切分算法有“范围法”和“哈希法”

范围法：以用户中心的业务主键uid为划分依据，采用区间的方式，将数据水平切分到两个数据

优点：

1. 切分策略简单，根据uid，按照范围，user-center很快能够定位到数据在哪个库上；
2. 扩容简单，如果容量不够，只要增加user-db3，拓展2千万到3千万的uid即可；

缺点：

1. uid必须要满足递增的特性；
2. 数据量不均，新增的user-db3，在初期的数据会比较少；
3. 请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡；

数据库层面的负载均衡，既要考虑数据量的均衡，又要考虑负载的均衡。

 

哈希法：也是以用户中心的业务主键uid为划分依据，采用哈希的方式，将数据水平切分到两个

优点：

1. 切分策略简单，根据uid，按照hash，user-center很快能够定位到数据在哪个库上；
2. 数据量均衡，只要uid是随机的，数据在各个库上的分布一定是均衡的；
3. 请求量均衡，只要uid是随机的，负载在各个库上的分布一定是均衡的

缺点：

1. 扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移；

 

---

 

使用uid来进行水平切分之后，对于uid属性上的查询，可以直接路由到库，对于非uid属性上的查询，就悲剧了

非uid属性查询业务场景分析：

• 第一大类，用户侧，前台访问

1. 用户登录：通过登录名loginname查询用户的实体，1%请求属于这种类型；
2. 用户信息查询：登录之后，通过uid来查询用户的实例，99%请求属这种类型；

• 第二大类，运营侧，后台访问，根据产品、运营需求，访问模式各异，按照年龄、性别、头像、登陆时间、注册时间来进行查询

 

针对这两类业务需求，架构设计的核心思路为：

1. 用户侧，采用“建立非uid属性到uid的映射关系”的架构方案；
2. 运营侧，采用“前台与后台分离”的架构方案；

 

---

 

建立非uid属性到uid的映射关系

• （1）索引表法；

1. 建立一个索引表记录loginname与uid的映射关系；
2. 用loginname来访问时，先通过索引表查询到uid，再通过uid定位相应的库；
3. 索引表属性较少，可以容纳非常多数据，一般不需要分库；
4. 如果数据量过大，可以通过loginname来分库；

缺点：会增加一次数据库查询，性能会有所下降

• （2）缓存映射法；

1. loginname查询先到cache中查询uid，再根据uid定位数据库；
2. 假设cache miss，扫描所有分库，获取loginname对应的uid，放入cache；
3. loginname到uid的映射关系不会变化，映射关系一旦放入缓存，不会更改，无需淘汰，缓存命中率超高；
4. 如果数据量过大，可以通过loginname进行cache水平切分；

缺点：仍然多了一次网络交互，即一次cache查询

• （3）生成uid法；

1. 在用户注册时，设计函数loginname生成uid，uid=f(loginname)，按uid分库插入数据；
2. 用loginname来访问时，先通过函数计算出uid，即uid=f(loginname)再来一遍，由uid路由到对应库；

缺点：生成uid 函数设计需要非常讲究技巧，有uid生成冲突风险，一般不采用

• （4）基因法；

 

 

 

1. 在用户注册时，设计函数loginname生成3bit基因，loginnamegene = f(loginname)，如上图粉色部分；
2. 同时，生成61bit的全局唯一id（参考snowflake），作为用户的标识，如上图绿色部分；
3. 接着把3bit的loginnamegene也作为uid的一部分，如上图屎黄色部分；
4. 生成64bit的uid，由id和loginnamegene拼装而成，并按照uid分库插入数据；
5. 用loginname来访问时，先通过函数由loginname再次复原3bit基因，loginnamegene = f(loginname)，通过loginnamegene%8直接定位到库；

相对完美，在分库时经常使用

 

前台与后台分离最佳实践

1. 前台、后台系统 web/service/db 分离解耦，避免后台低效查询引发前台查询抖动；
2. 可以采用数据冗余的设计方式；
3. 可以采用“外置索引”（例如ES搜索系统）或者“大数据处理”（例如HIVE）来满足后台变态的查询需求；

不需要访问实时库，通过MQ或者线下异步同步数据，使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案