数据库分库解决方案

当业务数据量很是大，单数据库没法支撑的时候，有多是单库已经写满了，也可能数据库读写比较频繁，已经触碰到单库的io瓶颈了，这时就须要考虑分库。

下面聊一下该怎么分库，如何优化：

刚开始只有数据库A, 后来又加了数据库B。

假如数据表都是有时间戳字段，并且数据查询条件都带一个时间戳字段，这样咱们能够根据数据建立的时间范围来分库，好比给数据库按年份命名db_2019， 到2020年新生成一个库db_2020， 在业务端进行数据读写操做时，先根据时间戳条件获取到年份，而后选择相应年份的数据库进行操做。

但上面这种方式只适合这种特定的业务场景，并且这种方式，可能旧数据不多读取，新数据会比较频繁读取，会致使不一样数据库负载是不均匀的。因此会不会有更好的分片方式呢？ 答案是确定的。几乎任何一张表都会有键字段，假如键值是数字类型，能够键值与数据库数量取模的方式进行分片，好比键值是100，数据库数量是2， 那么100%2获得0，就应该存储到索引为0的数据库。假如键值是字符串呢，能够经过crc32(value)算出一个数字，而后再经过数字取模的方式获得相应的数据库。

假如在使用过程当中，数据库又不够用了，须要再扩容，怎么办？ 

停服，根据新的分片逻辑进行数据迁移，起服上线新的分片逻辑。没毛病，假如业务容许停机一段时间， 这也是一种稳妥方式。假如业务不容许停机，或只容许停机很短的时间，这时该如何数据库扩容呢，或者说该如何平滑地进行数据库迁移而不影响业务呢？

 

能够经过下面步骤来

方案一：

• 修改写数据库逻辑：对须要迁移的数据，进行双写（写原数据库和要迁往的数据库）
• 写一个迁移脚本：从原数据库迁数据到目标数据库
• 校验原数据库是否跟跟目标数据库数据一致（在迁移的瞬间可能发生了原数据库删除了数据，而目标数据库依然写入），删掉目标数据库多余的数据。
• 修改数据库分片逻辑，去掉双写逻辑
• 删掉各个数据库冗余的数据

 

若数据库双倍分库扩容有更好方案

方案二：

• 原数据库和要迁往的数据库设计成双主同步
• 修改数据库分片逻辑
• 删掉各个数据库冗余的数据

后面找个时间再补充一些图表，以便读者能更直观得理解。

 

还有一些问题：

问题一：假如方案一中，进行双写的时候一个写成功，一个写失败，该如何处理？

问题二：分库后，如何分页查询数据？

 

后面会再写一篇较大篇幅的文章分析如何跨数据库分页查询数据。