分库分表简要方案

Posted 2021-04-25 媛道

根据实际的业务场景和技术成本，分库分表大概有以下几种实现方案：

1. 并发不高，但单表数据量突破 1000w+，可以考虑单库多表，开发手动编写路由规则，需要升级程序，简单，运维不需要调整现有架构。

2. 如果读压力大，但数据量并不大，可以考虑读写分离。

2. 分片规则，取模还是时间？看业务需要，尽量避免跨表 JOIN，如果避免不了可以通过冗余数据到 NOSQL 中。

3. 历史数据业务上还需要用吗？如果不用可以把历史数据备份迁移出去，减少单表数据量，开发代码不需要改动，运维操作即可。

4. 使用中间件  MyCat, 工作量主要在运维侧，需要配置逻辑库，逻辑表，数据节点，分片规则等；通过 VIP 方式，程序的配置文件需要只修改数据库链接字符串即可。

5. 使用中间件 Sharding Sphere , 工作量在开发侧，需要在程序中配置分片规则等。

以上的分库分表需要数据库的支撑，以 mysql 为例，常用的架构方案如下：

1. 一主一备，主机负责读写，从机负责备份数据

场景：适合中小型业务访问请求,读和写都不多，推荐使用(适合写、读并发不高，也适用数据量比较大的情况)。

2. 一主一丛，主机负责写，从机负责读取数据

场景：程序可以做读写分离。

3. 一主多丛，主机负责写，从机负责读取数据

场景：从机可以做高可用，程序可以做读写分离。

4. 一主一备多从，主机负责写，从机负责读取数据

 场景：备机可以做高可用，程序可以做读写分离，推荐使用（适合写不多，读多的情况，读写分离，也适用数据量比较大的情况）。

5. 多主多从，一般三个主机写，每个主机有多个从

场景：适合高并发情况，从机做高可用，主机负责读写，数据进行分片，推荐使用（支撑读写高并发，数据可分片）。

欢迎关注公众号：媛道

在一起  

长按左侧二维码，识别关注