数据库架构演变过程

简介: 背景在互联网初创时期,企业往往采用单体架构去搭建自己的应用系统,但是,随着企业的不断壮大,系统访问量不断随之上升,数据量也急剧增长。数据的存储是首先要解决的问题,在这个大数据时代,数据就是企业的命根子,数据库的单体架构很难满足数据的存储,这时,我们要对数据进行切分,数据的切分又分为垂直切分和水平切分。

背景

在互联网初创时期,企业往往采用单体架构去搭建自己的应用系统,但是,随着企业的不断壮大,系统访问量不断随之上升,数据量也急剧增长。数据的存储是首先要解决的问题,在这个大数据时代,数据就是企业的命根子,数据库的单体架构很难满足数据的存储,这时,我们要对数据进行切分,数据的切分又分为垂直切分和水平切分。

数据切分和数据库架构

在数据切分之前,我们的所有业务都放在一个数据库中,比如:我们的用户业务,商品业务,订单业务。数据库的架构如下:

1571966651393

在业务发展到一定规模时,一个数据库很难满足数据的存储,并且导致数据的访问比较慢,导致用户的流失。这时,我们要对数据进行切分,使其从单一的数据库的存储分散到多个数据库的存储。在进行数据切分时,我们要遵循先垂直水平的原则。

数据的垂直切分也就是数据的纵向切分,按照业务将数据进行切分。在上面的例子中,我们将一个数据库切分为:用户库,商品库,订单库。将原来的一个数据库分为了三个数据库,分散了数据的存储压力,同时也分散了数据的读取压力。如图所示:

1571967238429

但是,随着业务的发展,单个业务库也会遇到存储的瓶颈,比如:用户的急剧增长,导致单一的用户库无法存储,用户访问的速度变慢等。这时,我们就要对数据进行水平切分了,将用户按照某种规则平均分配到多个数据库中,也就是将原来的单一的用户库进行了水平扩展。如图所示:

1571967893765

这里,我们只是水平的拆分了两个库,大家可以根据自己的系统情况,拆分成更多的数据库。

分库分表中间件MyCAT

数据库的整体架构我们规划好了,那么我们在进行开发的时候,怎么确定一条数据从哪个数据库读取呢?或者插入一条数据的时候,这条数据要插入到哪一个数据库呢?数据库的选择是交给开发人员负责呢?还是统一的设置一个代理层呢?开发人员在开发的时候,关注的焦点是业务,复杂的业务已经占据了他们大部分的精力,如果再让他们去考虑数据库的问题,对他们的压力是非常大的,而且每个开发人员的代码风格也不一样,导致项目混乱,臃肿,难以维护。所以,我们往往采用代理层统一处理数据的分片,这时,我们的MyCAT分库分表中间件就登场了,它去做统一的数据库层的代理。如图:

1571968892640

MyCAT统一做数据库层的代理,对外暴露一个地址,应用系统直接连接MyCAT,就像连接普通的MySQL一样,没有任何的区别。所有的CRUD操作都直接对应MyCAT,再由MyCAT做具体的数据分片,数据分片的过程对于开发人员来说是透明的,不需要额外的处理,这样,开发人员只需要关注业务就可以了。

MyCAT集群

可用性对于一个系统来说是非常重要的,尤其是在当今的互联网时代,系统宕机1分钟,带来的损失都是非常严重的,所以,我们在搭建系统时,往往采用集群方式,某一个节点的不可用,不影响整体系统的可用性。在前面的例子中,我们所有的节点都是单节点,存在着单点故障,这是我们不希望看到的,所以我们要搭建集群。6个业务数据库我们都可以做主从,这时,用户1库可以搭建为 用户1(主)和用户1(从),用户2库可以搭建为 用户2(主)和用户2(从)。订单库和商品库也可以做同样的操作,如图:

1571970520540

这样我们的业务数据库不存在单点故障了,但是MyCAT成为了单点,如果MyCAT发生故障,或者MyCAT承载了大量的数据库的请求,MyCAT成了整个系统的唯一瓶颈。那么MyCAT我们如何搭建集群呢?有的小伙伴可能会说了,我们再部署一个MyCAT,这个MyCAT和前一个MyCAT配置一样就可以了。是的,这只是其中的第一步,我们有了两个MyCAT连接数据库,那么我们的应用系统也需要连接两个MyCAT吗?两个MyCAT我们要如何分配请求呢?这是不是又增加了应用系统的复杂性呢?所以,我们在两个MyCAT上面再增加一个负载均衡器,它可以将请求按照某种规则分配到两个MyCAT上,这个负载均衡器我们采用HAProxy。整体架构如图:

1571971467183

这样MyCAT的单点故障解决了,但是HAProxy又成了单点,这是不是很有意思,似乎总有一个单点解决不了。在这里最后一个单点HAProxy,我们使用KeepAlived做故障转移就可以解决了,两个KeepAlived可以提供一个虚拟IP,业务系统直接连接这个虚拟IP,后面的过程对于应用系统是透明的。如图所示:

1571971864731

这就是我们最终的数据库架构,不存在任何的单点故障。

分布式事务与分布式ID

进行了分库分表后,随之而来的问题也就出现了,那就是ID的问题和分布式事务的问题,分布式ID和分布式事务在MyCAT中都有相应的解决方案,我们在MyCAT中进行配置就可以了。
如果想要深入学习,请关注《JAVA架构师成长体系课》

目录
相关文章
|
28天前
|
存储 缓存 关系型数据库
鱼和熊掌如何兼得?一文解析RDS数据库存储架构升级
阿里云RDS率先推出新型存储类型通用云盘,提供低延迟、低成本、高持久性的用户体验。
鱼和熊掌如何兼得?一文解析RDS数据库存储架构升级
|
2天前
|
存储 监控 安全
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
为了提供更好的日志数据服务,360 企业安全浏览器设计了统一运维管理平台,并引入 [Apache Doris](https://doris.apache.org/) 替代了 Elasticsearch,实现日志检索与报表分析架构的统一,同时依赖 Doris 优异性能,聚合分析效率呈数量级提升、存储成本下降 60%....为日志数据的可视化和价值发挥提供了坚实的基础。
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
|
23天前
|
NoSQL 数据管理 数据库
浅谈微服务架构下的数据库设计策略
在当今快速发展的软件工程领域,微服务架构以其灵活性和可扩展性成为了众多企业和开发者的首选。然而,随着服务的细分,数据管理和存储面临着前所未有的挑战。本文将探讨微服务架构下的数据库设计策略,包括服务间数据的独立性、事务一致性问题的处理、以及数据迁移和备份的最佳实践。我们将通过对比传统单体架构与微服务架构下的数据库设计差异,提出几种有效的数据库设计方案,旨在为开发者提供在微服务环境下处理复杂数据问题的思路和方法。
14 0
|
24天前
|
敏捷开发 弹性计算 架构师
浅谈微服务架构下的数据库设计与实践
在当今快速发展的软件工程领域,微服务架构因其高度的模块化和灵活性而受到广泛欢迎。然而,随之而来的是对数据库设计和管理提出了新的挑战。本文将探讨在微服务架构下,如何有效地设计和实践数据库以支持服务的独立性、数据的一致性和系统的扩展性。我们将从微服务的数据库隔离策略谈起,深入分析数据库的分库分表、事务管理、数据一致性解决方案等关键技术,并通过实例说明如何在实际项目中应用这些原则和技术。本文旨在为软件开发者和架构师提供一份指南,帮助他们在微服务架构的环境下,更好地进行数据库设计和管理。
105 1
|
1月前
|
NoSQL Java 关系型数据库
基于java Swing 和 mysql实现的飞机订票系统(源码+数据库+ppt+ER图+流程图+架构说明+论文+运行视频指导)
基于java Swing 和 mysql实现的飞机订票系统(源码+数据库+ppt+ER图+流程图+架构说明+论文+运行视频指导)
|
2月前
|
存储 SQL Java
数据库TiDB-01.数据库架构概述
TiDB兼容MySQL 5.7协议,支持水平扩容或者缩容的金融级高可用的云原生分布式数据库。
86 2
数据库TiDB-01.数据库架构概述
|
2月前
|
存储 网络协议 Dubbo
Rpc编程系列文章第一篇:RPC概述和架构演变
Rpc编程系列文章第一篇:RPC概述和架构演变
|
2月前
|
运维 Oracle 关系型数据库
LIS实验室信息管理系统功能模块(Oracle数据库、Client/Server架构)
LIS实验室信息管理系统功能模块(Oracle数据库、Client/Server架构)
41 0
|
2月前
|
运维 关系型数据库 MySQL
阿里大牛的595页MySQL笔记,透彻即系数据库、架构与运维
数据库运维的变革,经历从手工造到脚本化、系统化、平台化、智能化的转变,逐步实现DBA对数据库的规范化、自动化、自助化、可视化、智能化、服务化管理,从而保障数据库的安全、稳定、高效运行。
|
5天前
|
监控 数据可视化 关系型数据库
微服务架构+Java+Spring Cloud +UniApp +MySql智慧工地系统源码
项目管理:项目名称、施工单位名称、项目地址、项目地址、总造价、总面积、施工准可证、开工日期、计划竣工日期、项目状态等。
56 6