亿级用户中心设计

数据库水平切分

范围法

优点

根据uid，1000万存db1,1000-2000万存db2，切分策略简单、扩容简单

缺点

uid必须自增
数据量不均，如新增db3 初期数据特别少
请求量不均，可能存在活跃用户都在某一台db上

哈希法

优点

切分策略简单，根据uid，按照hash很快定位到哪个库上
数据量均衡，uid是随机的
请求量均衡，uid是随机的
使用分布式id生成器，id一定是随机的

缺点

扩容麻烦，增加一个库，会导致重新hash

双倍扩容策略

采用双倍扩容策略，避免数据迁移。扩容前每个节点的数据，有一半要迁移至一个新增节点中，对应关系比较简单。

具体操作如下(假设已有 2 个节点 A/B，要双倍扩容至 A/A2/B/B2 这 4 个节点)：

• 无需停止应用服务器；

• 新增两个数据库 A2/B2 作为从库，设置主从同步关系为：A=>A2、B=>B2，直至主从数据同步完毕(早期数据可手工同步)；

• 调整分片规则并使之生效：

原 ID%2=0 => A 改为 ID%4=0 => A, ID%4=2 => A2；

原 ID%2=1 => B 改为 ID%4=1 => B, ID%4=3 => B2。

• 解除数据库实例的主从同步关系，并使之生效；

• 此时，四个节点的数据都已完整，只是有冗余(多存了和自己配对的节点的那部分数据)，择机清除即可(过后随时进行，不影响业务)。

基础补充-垂直分库分表

垂直分库：过将表按业务分类，然后分布在不同数据库，并且可以将这些数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果，但是依然没有解决单表数据量过大的问题
垂直分表：如商品信息，将访问频次较高的属性存到一张表中，将访问频次较低且内容多的存在另一张表中；
水平分库：垂直分库后，某个业务类别也无法再进行垂直拆分，则进行水平拆分，按照uid规则分到不同的库
水平分表：将同一数据结构的信息，根据算法，拆分不同的表

垂直：拆分不同业务（独立库-分库），拆分不同功能（独立表-分表）
水平：拆分同一业务（独立库-分库），拆分同一功能（独立表-分表）

用户中心，非id属性查询

用户端

单条查询，高可用，高性能

建立索引表

通过索引表 映射非id属性 与id之间的关系，在定位所在库

基因法

通过非id属性 通过算法 生成为一的id，这样非id属性和id就有关系了，但在入库前，又如何验证非id是否重复呢？

运营端

批量，复杂查询
冗余数据库或通过hive等大数据处理来满足需求