分库分表设计思想

大厂数据库设计模式
为了减轻数据库压力，一般采用一主多从的数据库设计。主库只用来写入数据，定时向从库同步数据。从库用来读数据。
一、什么时候适合分库分表
常用的数据库面对高并发的请求导致性能明显下降时就要分库分表。虽然说可以读写分离来减轻数据库压力，但即使只是写操作，当每秒超请求过多，或者单表数据量过大时。会导致数据库连接不够，读写出现瓶颈（例如淘宝双十一）。阿里推荐当单表超过500万行或者表容量超过2GB时，就应该进行分库分表。

二、分库分表的方式
垂直拆分—分库
分库一般与业务逻辑相关联，可以按照业务功能相关性进行拆分。最常见的现在微服务架构开发的系统，系统的各个子系统都有自己的一个或多个主数据库。子系统之间的数据库相互分开。大大减小了写并发的压力。

水平拆分—分表
分表常见的有两种方式。
一种是哈希分表。设置某一个字段为路由，一般是主键。写入时路由对于分表数取模，根据结果判断这条数据应该插入哪张表。读取时同样。例如某张订单表，要分成4张表。则设置订单ID为路由，订单Id%4，结果为0、1、2、3时，分别写入第1、2、3、4张表。
缺点：不好扩容。如果4张表也满了，后续想继续扩容不好实现。

另一种是按照范围分表。设置某一字段为路由，一般是主键。写入时设置其在某个范围内的话就存入某张表。读取时同样。例如某张订单表，要分成4张表。则设置订单ID为路由，订单ID在0-100万时，放入第一张表，100万-200万时放入第二张，以此类推。
缺点：热点问题。前100万条数据只写如第一张表时，高并发时压力很大。

目前用的较多的是第一种哈希分表。

三、分库分表后面临的问题及解决方案
1、分布式事务、多库事务（暂时没有学习到好的解决方案）
2、多个分表联合查询
解决思想：设置正确的路由。且同一业务维度的路由规则需要一致。

例：电商订单表，需要分为4张表。怎么设置路由。
1>用户端：需要根据userID查询，路由为userID。orderID可以设置为雪花算法Id+userID。
2>商家端：需要根据商家ID查询。一般会单独建一套冗余的订单数据。用商家ID为路由。
3>运营管理端：既要使用用户ID查询，也要用商家ID查询。可以分为实时查询/非实时查询。对于非实时查询，使用数据仓库。对于实时查询，使用elasticsearch。

数据仓库：原始数据库所有分表的数据，经过清洗、分析都存放于数据仓库中。数据量大、查询速度慢。

Elsticsearch：实现方式是将表的主键ID和常用的查询条件字段都存放与内存之中。例如本例中的用户ID和商家ID。以此达到快速查询的目的。

同一业务维度的路由规则一致是指，若订单表使用用户ID为路由，则订单支付表、订单物流表等业务相关表也要用用户ID为路由。如此才能在该业务维度上有效避免多表联合查询。

四、已运行一段时间的单表系统，怎么更换为新系统并进行分表
这个问题的一个关键点是将原来的单表数据迁移至分表。设计一个数据迁移系统，主要功能为从原来的单表中读取数据，并根据路由写入新表。若是系统能够直接停机迁移，则直接停机迁。若是不能，则需要实时迁移。实时迁移设计如下：

其中：
迁移批次表：原表查出1000条数据后写入。

迁移明细表：新表写入后写入迁移明细表。

为了防止迁移系统发生意外，导致迁移中断。有了这两张表后迁移中断就能够知道从哪个位置恢复迁移。

binLog：旧表数据库的操作日志，实时迁移的过程中，所有对原表的操作都记录在此。这部分数据借由这个日志工具进行增量同步。当update或者delete发生时，先在旧表中执行命令，再通过迁移批次表查看是否已经迁移，若已经迁移，直接增量同步。当insert发生时，直接增量同步。
此时，只有一种情况无法迁移，即原表update时，数据刚好在已查询出的1000条里，且尚未写入新表。此时，可以借助延迟队列。将update命令放入延迟队列中，等一会再操作。

数据同步完成后，做数据对比，对比一致后即算成功。

不过一般数据同步完成后新系统也不会直接上线。而是灰度发布。即新系统和旧系统同步运行，把旧系统的一部分流量迁至新系统。

以上，这次对于分库分表思想学习的总结和笔记，中间很多地方还是不求甚解。仅供学习。