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小时内删除侵权内容。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。