MySQL之分库分表后带来的“副作用”你是怎么解决的？

一、垂直分表后带来的隐患

垂直分表后当试图读取一条完整数据时，需要连接多个表来获取，对于这个问题只要在切分时，设置好映射的外键字段即可。当增、删、改数据时，往往需要同时操作多张表，并且要保证操作的原子性，也就是得手动开启事务来保证，否则会出现数据不一致的问题。

这里可以看到，垂直分表虽然会有后患问题，但带来的问题本质上也不算大问题，就是读写数据的操作会相对麻烦一些，下面来看看其他的分库分表方案，接下来是真正的重头戏

二、水平分表后带来的问题

水平分表就是将一张大表的数据，按照一定的规则划分成不同的小表，当原本的一张表变为多张表时，虽然提升了性能，但问题随之也来了~

1.多表联查问题

• 全局表：对于一些不经常更新但需要频繁联查的小表，可以将其设置为全局表，每个分片都有一份完整的副本。这样在进行联查时，可以直接使用本地的全局表数据。
• 中间件支持：使用如ShardingSphere这样的分布式数据库中间件，它们能够智能地解析SQL语句，并在必要时从多个分片获取数据，然后在中间件层合并结果。
• 预聚合与缓存：对于一些固定模式的联查，可以在后台定期执行并存储结果到缓存或专门的汇总表中！
• 放入第三方中间件中，然后依赖于第三方中间件完成，如ES。一些大企业选用的方案。

2.增删改数据问题

• 分片键策略定位具体库表

3.聚合操作问题

• 放入第三方中间件中，然后依赖于第三方中间件完成，如ES。一些大企业选用的方案。

三、垂直分库后产生的问题

垂直分库是按照业务属性的不同，直接将一个综合大库拆分成多个功能单一的独享库，分库之后能够让性能提升N倍，但随之而来的是需要解决更多的问题，而且问题会比单库分表更复杂！

1.跨库join问题

• Java系统中组装数据，通过调用对方服务接口的形式获取数据，然后在程序中组装后返回。

2.分布式事务问题

分布式事务应该是分布式系统中最核心的一个问题，这个问题绝对不能出现，一般都要求零容忍，也就是所有分布式系统都必须要解决分布式事务问题，否则就有可能造成数据不一致性。

• ①Best Efforts 1PC模式。
• ②XA 2PC、3PC模式。
• ③TTC事务补偿模式。（柔性事务）
• ④MQ最终一致性事务模式。（常用）

3.部分业务库依然存在的性能问题

• 再做水平分库即可

四、水平分库后需要解决的问题

1.聚合操作和连表问题

• 放入第三方中间件中，然后依赖于第三方中间件完成，如ES。一些大企业选用的方案。

2.数据分页问题

• 放入第三方中间件中，然后依赖于第三方中间件完成，如ES。一些大企业选用的方案。

3.ID主键的唯一性问题

• 在业务系统中，利用特殊算法生成有序的分布式ID，比如雪花算法、Snowflake算法等。

4.流量迁移、容量规划、节点扩容

线上环境从单库切换到分库分表模式，数据该如何迁移才能保证线上业务不受影响，对于这个问题来说，首先得写脚本将老库的数据同步到分库分表后的各个节点中，然后条件允许的情况下先上灰度发布，划分一部分流量过来做运营测试。

如果没有搭建完善的灰度环境，那先再本地再三测试确保没有问题后，采用最简单的方案，先挂一个公告：“今日凌晨两点后服务器会进入维护阶段，预计明日早晨八点会恢复正常运转”！然后停机更新，但前提工作做好，如：Java代码从单库到分库分表要改进完善、数据迁移要做好、程序调试一切无误后再切换，同时一定要做好版本回滚支持，如果迁移流量后出现问题，可以快捷切换回之前的老库。

根据实际情况先做垂直分库，然后再对于核心库做水平分库，水平分库的节点数量要保证的是2的整倍数，方便后续扩容。

扩容一般是指水平分库，也就是当一个业务库无法承载流量压力时，需要对相应的业务的节点数量，但扩容时必须要考虑本次增加节点会不会影响之前的业务，因为很多情况下，当节点的数量发生改变时，可能会影响数据分片的路由规则，这时就要考虑扩容是否会影响原本的路由规则。

扩容一般都是基于水平分库的基础上，进一步对水平库做节点扩容，目前业内有两种主流做法：水平双倍扩容法、异步双写扩容法。

水平双倍扩容法

想要使用双倍扩容法对节点进行扩容，首先必须要求原先节点数为2的整数倍，同时路由规则必须要为数值取模法、或Hash取模法，否则依旧会造成扩容难度直线提升。同时双倍扩容法还有一种进阶做法，被称之为从库升级法，也就是给原本每个节点都配置一个从库，然后同步主节点的所有数据，当需要扩容时仅需将从库升级为主节点即可，过程如下：

二倍扩容！！

如果你在的公司财大气粗，我推荐从库升级法，因为从库升级法不仅仅能够避免数据迁移，而且还能保证高可用，当主节点宕机时可以让从节点直接上线顶替，再配合Keepalived+VIP做重启，基本上能够让数据库真正达到7x24小时不间断运行。

异步双写扩容法（常用）

前面聊到的水平双倍扩容法，仅仅只是扩容时的一种方案，除此之外还有另一种方案称之为异步双写扩容法，大体示意图如下：

对于需要扩容时的情况，首先依旧把新的数据写入到老库中，然后写完之后同步给MQ一份，后续再由MQ的消费者去将新数据写到新库中，同时新库在这期间，会去同步老库中原有的数据，这个动作持续到所有旧数据全部同步完成后，再以老库作为校验基准，核对数据无误后，再将模式切换为扩容后的分库模式

稍微总结一下整个流程，如下：

• 第一步：修改应用服务代码，加上MQ双写方案，配置新库同步老库数据，然后部署。
• 第二步：等待新库同步复制老库中所有老数据，期间新写入的数据也会通过MQ写入新库。
• 第三步：老库中的所有老数据全部同步完成后，以老库作为校验基准，校对新库中的数据。
• 第四步：校对新老库之间的数据无误后，修改应用配置和代码，将双写改为路由分片，再次部署。

其实异步双写方案，也可以用来做后续的节点扩容，但会相对来说比较麻烦一些。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们处理，核实后本网站将在24小时内删除侵权内容。