大家好,我是不才陈某~ 在前面的文章中探讨了架构优化的两种方案:冷热分离、查询分离 查询分离其实就是利用了非关系数据库的高性能,但是不足之处也很明显:当主数据量越来越多,写操作缓慢;这种问题如何破局?可见任何一种优化方案都不是最终的银弹,只有不断的优化演变 这篇文章就来介绍一下解决方案:分库分表,将围绕以下几点介绍:
拆分后的存储选型?在介绍选型之前先来介绍下架构背景,笔者曾经做过电商系统的优化,该系统中包含的两个主体:
对于如此量级的数据,单库单表的情况下,无论是IO还是CPU都扛不住,架构上的优化是必然。 经过了多次探讨尝试,最终选择了分库分表。 说到分库分表首先想到的就是存储选型,关于持久层的选型主流的无非有如下几种:
1. 关系型数据库关系型数据库目前市面上主流无非三种:MySQL、Oracle、SqlServer,笔者更倾向于MySQL,也是很多新型企业在用的一种数据库,因此本篇文章也将重点围绕MySQL展开 在任何系统中关系型数据库的地位都是不可或缺的,它的强约束性、事务的控制、SQL语法、锁....这些功能可谓是久经考验,因此在功能上 MySQL 能满足我们所有的业务需求。 2. NoSQL说到NoSQL,第一个想到就是MongoDB ,它的分片功能从并发性和数据量这两个角度已经能满足一般大数据量的需求,但是仍然需要考虑如下几点:
3. NewSQLNewSQL目前比较主流则是TiDB,该技术比较新,虽然能够满足大数据量的存储,但是在选择上还是需要做些考量:
基于MySQL的分库分表什么是分表分库?分表是将一份大的表数据拆分存放至多个结构一样的拆分表;分库就是将一个大的数据库拆分成多个结构一样的小库。 前面介绍的三种拆分存储技术,在我以往的项目中我都没使用过,而是选择了基于 MySQL 的分表分库,主要是有一个重要考量:分表分库对于第三方依赖较少,业务逻辑灵活可控,它本身并不需要非常复杂的底层处理,也不需要重新做数据库,只是根据不同逻辑使用不同 SQL 语句和数据源而已。 目前市面上主流的分库分表分为两种模式:Proxy模式、Client模式 Proxy模式属于业务无侵入型,直接代理数据库,对于开发者一切都是无感知的,SQL 组合、数据库路由、执行结果合并等功能全部存放在一个代理服务中,比如 Client模式属于业务侵入型,将分库分表的逻辑放在客户端,客户端需要引入一个jar,比如Sharding-JDBC,架构图如下: 市面上对于分库分表中间件如下: 两种模式的优缺点也很明显:
分库分表的实现思路在落实分表分库解决方案时,我们需要考虑 5 个要点。 1. 分片键如何选择?针对订单这个业务,其中涉及到以下几个主要的字段:
经过考量,最终选择了 选择user_id作为ShardingKey需要结合业务场景,订单系统中常见的业务:
以上三种业务场景,判断下优先级,C端用户肯定是需要优先满足,因此使用user_id作为ShardingKey 这样在查询时需要将user_id传递过来才能定位到指定库、表 选择字段作为分片键时,我们一般需要考虑三点要求:数据尽量均匀分布在不同表或库、跨库查询操作尽可能少、这个字段的值不会变(这点尤为重要)。 2. 分片的策略是什么?选择user_id作为ShardingKey之后,需要考虑使用分片策略了,主要分为如下三种 1、范围分片 假如user_id是自增的数字,则可以根据user_id范围进行分片,每100万份分为一个库,每10万份分为一个表,此时单个库中将分为10张表,如下表: 2、Hash取模 这种方案是根据Hash值进行分片,比如Hash函数为: 3、范围分片和Hash取模混合 比如先按照范围对user_id拆分,每100万份分为一个库,在对这100万份数据进行Hash取模( 当然以上三种方案的优缺点也是非常明显,这里不再赘述了 需要注意的是:在拆分之前,为了避免频繁的扩容,一定要对未来5年或者10年数据增长做个判断,预留更多的分片 3. 业务代码如何修改业务代码的修改这里就不好说了,和自身的业务是强关联。 但是,在这里我想分享一些个人观点。近年来,分表分库操作愈发容易,不过我们需要注意几个要点。
4. 历史数据迁移?历史数据的迁移非常耗时,有时迁移几天几夜都很正常。而在互联网行业中,别说几天几夜了,就连停机几分钟业务都无法接受,这就要求我们给出一个无缝迁移的解决方案。 还记得讲解查询分离时,我们说过的方案吗?我们再来回顾下,如下图所示: 历史数据迁移时,我们就是采用类似的方案进行历史数据迁移,如下图所示: 此数据迁移方案的基本思路:存量数据直接迁移,增量数据监听 binlog,然后通过 canal 通知迁移程序搬运数据,新的数据库拥有全量数据,且校验通过后逐步切换流量。 数据迁移解决方案详细的步骤如下:
5. 未来的扩容方案是什么?随着业务的发展,如果原来的分片设计已经无法满足日益增长的数据需求,我们就需要考虑扩容了,扩容方案主要依赖以下两点。
分表分库的不足分表分库的解决方案讲完了,以上就是业界常用的一些做法,不过此方案仍然存在不足之处。
欢迎加入陈某的知识星球,一起学习打卡,交流技术。加入方式,扫描下方二维码: 已在知识星球中更新如下几个专栏,详情戳链接了解:
如果这篇文章对你有所帮助,或者有所启发的话,帮忙点赞、在看、转发、收藏,你的支持就是我坚持下去的最大动力! |
|
来自: woh5r1ofyffxnh > 《待分类》