数据库分库分表策略

前言

随着数据规模的增大，单库的性能和成本不满意满足日常需求，需要进行分库分表。

确定分库分表基本信息

确定需要分库分表的表格有哪些

确定需要分库分表的表的分片键，一般可以是userId，city，之类的标识性的字段。

分库策略

全量基本信息+分库

会有一个全量的基本信息表，比如重要的字段：orderId，userId等，方便做列表维度的全量查询。

然后配合分库分表。

优点是可以查询全量数据，缺点是全量数据也会很大。

热库+分库

热库只存热数据，比如最近的订单。主要业务在热数据上，分库存的全量数据。

优点是冷热分离，缺点是需要双写或者数据同步，需要归档删除冷数据，不能查询全量数据。

只有分库

只有分库，切换到分库后删除主库。

优点是逻辑简单，存储成本也低。缺点是不能查询全量数据。

以只有分库为例，如何做分库分表

建立分库分表

确定分库分表的数量，确定分片键，比如订单16*16,16个库，每个库16个表。

同步数据

做一个数据同步的服务，将主库的历史数据同步到分库分表。

历史数据的同步

同步程序，将历史数据同步到分库分表。

写一个同步接口，每次查询2000条（可配置），定时任务调用，同步到分库分表，接口需要加分布式锁防止并发调用出问题。

根据updateTime和主键排序，同步完将updateTime和主键存到缓存中作为游标，下次查询要以updateTime和主键作为游标查询。

数据量不大可以单台机器同步即可，数据量大的情况下可以多台机器同步。

多台机器同步逻辑：单次查询2000条，发送mq，多机器消费同步数据，提高效率

实时增量数据同步

适用于热库+分库方式，一般情况下不推荐，因为成本和复杂度会提高很多。

如果代码单写需要实时同步，代码双写不需要实时同步。
canal+mq+服务同步实时增量数据，不过滤delete操作，当mq收到delete操作的时候，删除数据。注意顺序消费。

代码改造

我们项目选择用shardingsphere做的分库分表，可以参考基于shardingsphere实现分库分表_shardingsphere 逻辑分库-CSDN博客

主键改成雪花id

双写，双读，灰度

双写：数据既写到主库，也写到分库，后续单读分库后灰度切换到单写分库

双读：数据在双写时写读主库，历史数据同步完后灰度读分库，最后单读分库。

最后单写分库，单读分库后就可以删除主库的访问。

注意的事项

分库分表策略选择

分片键确定

灰度计划设计，代码改造，灰度过程要快，避免其他业务开发后还要合并代码可能产生的问题

历史数据校验，避免数据同步遗漏或者不一致（写一个类似同步程序的检验程序，定时任务检验），一个是看数据存不存在，一个是看数据一不一致，数据一致性不好判断可以抽取几个关键字段判断，比如updateTime。