分库分表数据落地方案

 

这里的分库分表是指代“水平分库分表”，即 Horizontal Sharding.

将单个数据库拆分，单个表拆分为多个表；根据指定字段值或者值的部分计算数据库索引和表索引；

 

一个典型的数据分布（示例为一库多表，选择一库单表还是一库多表按业务实际情况）：

　　

　这里按 2 库2 表举例，装填临界:4；

　　　计算分库索引公式：

　　　　一. 自然递增id：

　　　　　　适合同类别仓储管理类业务场景（即货物区分类别相同，如同一工厂生产的一种啤酒，来什么货物存什么货物）；

　　　　　　1.  当分库表字段值  {fieldValue} 大于等于4时，需要先对4取余，跳转 2.，小于4时 跳转 2.；

　　　　　　2.  db_index = {fieldValue} / db_indices_count；

　　　　　　3.  table_index = {fieldValue} % [一个物理库内分表总数]；

　　　　二. 预先分配库表索引编号：

　　　　　　用户注册时就按照用户的地区、性别、年龄、选择的产品类型等信息决策出用户的分库、分表索引值（决策逻辑公式应该要满足足够的分布性）；

　　　　　　1. 直接按照用户的分库分表属性值路由分库、分表；

　　　

分库分表数据装填概况（依次插入id 1~16的数据分布情况）：

 

　　　　　id值

db_0 : { 
　　user_0 4  8  12 16
　　user_1 1  5  9   13 
}

db_1: {
　　user_0 2  6  10 14
　　user_1 3  7  11 15 
}

 

找到分库、分表索引后，再根据SQL的Command Type （如SELECT、UPDATE） 或者用户强制指定情况来决定是走 master/slave  Leader / Follower （政治正确统称）库，

如果主、从有多个物理实例，则需要按照一定的规则（随机或者RoundRobin之类）来挑选一个物理节点（host / port）连接；

 

其中：

　　1. 修改新增update、insert 必须使用主节点连接；

　　2. 查询则需要判断区分 普通 SELECT 还是 SELECT FOR UPDATE / SELET IN SHARE MODE 事务操作，普通SELECT在容忍主从延迟的业务场景下可以到从执行，其他到主执行；

　　3. 一个SQL执行完毕之后可能要清除路由上下文；

　　4. 大多数web2.0 业务场景（如抖音用户信息页）都需要按照user_id 值或值的部分来计算分库、分表索引；