分库分表实战

为什么

分表：解决单表数据量过大，查询性能下降，ddl困难问题

分库：解决单库连接数不足，写并发高，通过分摊压力提高吞吐量，单机瓶颈。

问题

引入了分布式复杂性

方式

垂直分库分表

按照业务模块拆分库

按列拆分表

水平分库分表

按行拆分，解决单表过大问题，应对大数据量核心手段

分片键

怎么选？

查询频率高的

路由算法

范围分片

按照id或时间分。扩容，查询方便

缺点，容易数据倾斜

哈希取模

分片键哈希取模，数据分布均匀

缺点，扩容困难，需要迁移数据

一致性哈希

解决扩容问题，节点变化前只需迁移少量数据。

缺点，实现复杂，存在哈希倾斜风险

分库分表数量为什么是2的幂次方

和hashMap是一个道理。

• 位运算优化：hash % 8 等价于 hash & (8-1)，性能更高。
• 均匀分配：便于将表均匀分配到多个库中。
• 易于扩容：从N张表扩容到2N张表时，只需迁移一半数据。利用了“高位运算”：因为容量永远是 2 的幂，扩容时只需看 hash 值新增的那一位高位是 0 还是 1。是 0 就留在原索引（低位），是 1 就迁移到 原索引 + 旧容量（高位）。

分布式ID

雪花算法，redis自增(挂了怎么办？)

跨库JOIN

• 常用字段冗余
• 全局表：每个库存一份变动少基础表(配置)。本地join
• 应用层组装，查好数据在内存中组装
• 相关联的数据，强制放在一个节点。比如订单和订单详情，相同的订单，数据要放在同一个节点。

分布式事务如何处理？

比如强一致性的二阶段提交。但是不建议使用，因为性能差。

最终一致性，比如tcc和saga。 Tcc比较复杂，每种事务都要实现三个方法 Try ，confirm和cancel。本地消息表加重试，或者rocket mq事务消息。

非分片键如何查询？

一，建立映射表，非分片键和分片键，建立映射表

二，异构索引，根据另一个维度，再建立一套分库分表。

三，基因法，将分片信息植入到id中。比如订单表和用户id。订单号包含用户id分片信息。

生成订单号的时候，可以将用户id生成二进制，然后放到订单号的尾部。查询的时候解析出来即可。

或者是生成雪花id的时候，专门划分几位，保存库表编号。

基因法的一个优点就是不用去查映射表，也不用去配置中心拉取路由规则，计算路由。速度会很快，就是单纯的位运算。那他的一个缺点也很明显，就是灵活性很差，比如说我一个节点挂了，或者发生数据倾斜，或者是要扩容，迁移数据的时候，就没有办法使用。

这里一个解决方案就是可以兜底，使用映射覆盖，就是在中间件层设置一个优先级更高的热迁移配置。如果有设置配置，那么就去读取配置强制使用配置中的路由，否则就使用id中的路由。

如何设计？

当查询遇到分页怎么办？

先查出来，然后再在内存中聚合。但是性能比较差。尽量能不分页就不分页，或者使用es。

如何设计动态扩容方案

一，停机扩容，但是不推荐，数量大的时候会很慢。

二，一次性规划好，预分配。一次性就设计好，32个库，每个库32张表，一共是1024张表。够用好久，避免扩容迁移数据。