上海黄页企业名录,seo网站权重,崇礼做网站的公司,wordpress 支持woocommerce目录标题 一、垂直分表后带来的隐患二、水平分表后带来的问题1.多表联查问题2.增删改数据问题3.聚合操作问题 三、垂直分库后产生的问题1.跨库join问题2.分布式事务问题3.部分业务库依然存在的性能问题 四、水平分库后需要解决的问题1.聚合操作和连表问题2.数据分页问题3.ID主键… 目录标题 一、垂直分表后带来的隐患二、水平分表后带来的问题1.多表联查问题2.增删改数据问题3.聚合操作问题 三、垂直分库后产生的问题1.跨库join问题2.分布式事务问题3.部分业务库依然存在的性能问题 四、水平分库后需要解决的问题1.聚合操作和连表问题2.数据分页问题3.ID主键的唯一性问题4.流量迁移、容量规划、节点扩容 一、垂直分表后带来的隐患
垂直分表后当试图读取一条完整数据时需要连接多个表来获取对于这个问题只要在切分时设置好映射的外键字段即可。当增、删、改数据时往往需要同时操作多张表并且要保证操作的原子性也就是得手动开启事务来保证否则会出现数据不一致的问题。 这里可以看到垂直分表虽然会有后患问题但带来的问题本质上也不算大问题就是读写数据的操作会相对麻烦一些下面来看看其他的分库分表方案接下来是真正的重头戏 二、水平分表后带来的问题
水平分表就是将一张大表的数据按照一定的规则划分成不同的小表当原本的一张表变为多张表时虽然提升了性能但问题随之也来了~
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取模法否则依旧会造成扩容难度直线提升。同时双倍扩容法还有一种进阶做法被称之为从库升级法也就是给原本每个节点都配置一个从库然后同步主节点的所有数据当需要扩容时仅需将从库升级为主节点即可过程如下 二倍扩容
如果你在的公司财大气粗我推荐从库升级法因为从库升级法不仅仅能够避免数据迁移而且还能保证高可用当主节点宕机时可以让从节点直接上线顶替再配合KeepalivedVIP做重启基本上能够让数据库真正达到7x24小时不间断运行。
异步双写扩容法常用
前面聊到的水平双倍扩容法仅仅只是扩容时的一种方案除此之外还有另一种方案称之为异步双写扩容法大体示意图如下 对于需要扩容时的情况首先依旧把新的数据写入到老库中然后写完之后同步给MQ一份后续再由MQ的消费者去将新数据写到新库中同时新库在这期间会去同步老库中原有的数据这个动作持续到所有旧数据全部同步完成后再以老库作为校验基准核对数据无误后再将模式切换为扩容后的分库模式
稍微总结一下整个流程如下
第一步修改应用服务代码加上MQ双写方案配置新库同步老库数据然后部署。第二步等待新库同步复制老库中所有老数据期间新写入的数据也会通过MQ写入新库。第三步老库中的所有老数据全部同步完成后以老库作为校验基准校对新库中的数据。第四步校对新老库之间的数据无误后修改应用配置和代码将双写改为路由分片再次部署。
其实异步双写方案也可以用来做后续的节点扩容但会相对来说比较麻烦一些。 版权声明本文内容由网络用户投稿版权归原作者所有本站不拥有其著作权亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容请联系我们处理核实后本网站将在24小时内删除侵权内容。
