架构设计之「数据库集群方案」

简介:

b692a266f0b2e160d962ffbd0ec83fc2d98f23fc

在之前的文章中,我们知道数据库服务可能已经成为了很多系统的性能关键点,甚至是瓶颈了。也给大家介绍了数据库服务器从主备架构、到主从架构、再到主主架构的基础方案。但如果单台机器已经不能满足完整业务数据存储的时候,我们就需要考虑采用多机甚至多中心的部署方案了。

今天我们就再来聊一聊,在多机环境下,数据库集群的架构方案。

同样,这里先不看细节,不管底层数据源是什么数据库,我们先谈架构方案。因为无论底层是 Mysql 还是 Redis、MongoDB,我们在架构设计上都是相通的。

针对多机的架构,常见有如下做法:

  • 单中心数据集群

  • 多中心数据分区

下面我们来具体看看:

一、单中心的数据集群架构(单中心多机)

单数据中心多机器的集群又可以分为:

  • 数据集中模式

  • 数据分散模式

这两种的主要区别在于集群中的完整业务数据是全部集中在一台机器上,但是分散在多台机器上。

  1. 数据集中模式

如图,

6394c9bec0e3deda74720fc34cbba2cbd7bbf171

这种模式与「一主一从式」(主从式)比较类似,完整的业务数据还是存储在一台主机的上,主机承担读服务和写服务,从机只承担读服务。但是从机有多台机器,从机实时的从主机同步数据。所以这种模式,也可以理解为「一主多从」式。

因为有多个从机,那么也给这种架构带来了一些额外需要处理问题,比如:
1.1,主机需要实时的将数据同步到多台从机上,涉及到主机的处理压力问题。
1.2,需要保障多台从机之间的数据一致性的问题,如果出现数据不一致,如何处理。
1.3,多台从机是如何检测主机状态的,因为从机在关键时刻是要替换主机的,那么如果多台从机监测到的主机状态不一致,那又可能会带来其它问题。
1.4,从机切换为主机的时候,选择哪一台从机来切换呢,这涉及到多台从机之间如何进行选举的问题。

这些问题,在我们进行架构设计的时候,必须提前考虑。不过市面上也有一些工具可以辅助实现,例如 ZooKeeper等。

另外,由于数据集中模式的所有写操作都只到一台主机上,而读操作可以到N台从机上。因此这种模式比较适用于业务数据量不大、读操作远远大于写操作、集群规模较小的业务场景。

  1. 数据分散模式

如图,

1317f04045ae567e7616af585ec2a718a322628d

数据分散模式是指,完整的业务数据并非是全部存储在一台主机上的,而是由多台主机共同分担,分散存储。因此这种模式适用于大数据量、集群规模较大的场景。

使用这种模式,也有几点需要特别注意的:
1.1,尽量将数据均衡的分散的各个机上,这样才能保证资源的均衡使用和性能的最佳。
1.2,多台机器上的数据虽然不同,但是也需要互相进行数据的备份。
1.3,要能动态的增加和删除节点,这样可以便于随时扩展,通常采用一致性HASH的方法。

聊完了单数据中心的集群架构,我们再来看看多数据中心的数据分区架构。

二、多中心的数据分区架构(多中心多机)

出于容灾的考虑,通常会在多个不同地区部署多套的数据集群。毕竟在国内运营商网络故障、光纤被山东蓝翔技工铲断等事件还是不少的。轻则一个机房出问题,重则一个城市一个省份都可能故障。

如果我们数据存储服务只部署在一个机房,那如果这个机房出现了故障,很有可能导致不能服务甚至是无法恢复业务了。因此我们就需要考虑多中心的数据分区架构,将数据按照一定的规则进行分区,部署在不同机房/城市里,且每一个分区都存储一部分数据,通过这种方式来保障数据和服务的可用性。

在多中心的数据分区模式下,我们需要提前规划 “分区规则” 。毕竟将数据在地理位置上分区,在网络通讯方面是有时延的,所以必须要考虑好我们是要以区域、还是以城市、还是省份来分节点部署。

除了 “分区规则” ,我们还需要考虑 “备份规则” 。
因为分区之后,各区都只存储一部分数据,并不是完整数据。如果其中一个区出故障了,虽然不会影响全局,但是也会带来一定损失。因此我们需要考虑将每个区里的数据备份起来,备份有几种方式:

  • 集中备份式

  • 独立备份式

  • 相互备份式

下面将这三种备份方式解释一下:

  1. 集中备份式

如图,

42b36bb112d5ac3bd6adda9a2ec6d40b1b7acd8f

集中备份式是指建立一个独立的数据备份中心,将各分区(节点)的数据都定期同步到这个备份中心,以保障数据的安全性。这种备份方式可以随意的扩展分区(节点),不受分区的个数限制,并且结构很简单。但是

这种备份方式的缺点就是,投入成本有点高,因为需要额外建立这么一个备份数据中心,平时也是闲置的,有点浪费资源。另外,备份中心自身也可能会有单点的故障,且备份中心中需存储多个分区的数据,还可能会互相受到影响。

  1. 独立备份式

如图,

6c21a05296b90f534d5a6e3dbad600c15c0dddc1

独立备份式就是给每一个数据分区(节点)都建立一个额外的备份节点,这个备份节点部署在不同的地域/城市,这样才能起到容灾的作用。

这种备份方式相比较于 集中备份式 ,建设成本就更大一些了,毕竟每一个分区都需要额外建立一个备份节点。但是结构更清晰简单了,而且各个分区的数据之间还可以做到互不影响,完全是独立的。后续扩展分区(节点)的时候,对前面的备份节点也没有影响,扩展性好。

  1. 相互备份式

这个暂时没有找到合适的图。

相互备份式其实是结合了上面两种特性在一起的模式。上面的方式不是成本大么,那么这种方式就不额外建立备份中心了,让各个分区(节点)互相备份数据。比如 分区A 将自身数据同步一份给 分区B备份着,分区B 将自己的数据同步一份给 分区A 备份着,如果是三个以上分区,还可以做到循环备份。

这种备份方式,设计稍微复杂一些,扩展性也弱一些,但是可以节约资源。

无论采用哪种方式,都需要结合实际的业务场景来决定。

以上,就是对数据库在多机集群模式下的技术架构的分享,欢迎大家一起交流。



原文发布时间为:2018-10-11
本文作者:奎哥
本文来自云栖社区合作伙伴“云时代架构”,了解相关信息可以关注“云时代架构”。
相关文章
|
1月前
|
SQL NoSQL 前端开发
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
|
3月前
|
存储 缓存 关系型数据库
鱼和熊掌如何兼得?一文解析RDS数据库存储架构升级
阿里云RDS率先推出新型存储类型通用云盘,提供低延迟、低成本、高持久性的用户体验。
鱼和熊掌如何兼得?一文解析RDS数据库存储架构升级
|
4月前
|
存储 SQL Java
数据库TiDB-01.数据库架构概述
TiDB兼容MySQL 5.7协议,支持水平扩容或者缩容的金融级高可用的云原生分布式数据库。
264 2
数据库TiDB-01.数据库架构概述
|
4月前
|
中间件 关系型数据库 Java
MySQL数据库分库分表方案
MySQL数据库分库分表方案
136 0
MySQL数据库分库分表方案
|
21天前
|
存储 Java 应用服务中间件
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
【分布式技术专题】「架构实践于案例分析」盘点互联网应用服务中常用分布式事务(刚性事务和柔性事务)的原理和方案
42 0
|
21天前
|
canal 消息中间件 关系型数据库
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
66 0
|
1月前
|
存储 SQL 分布式计算
TiDB整体架构概览:构建高效分布式数据库的关键设计
【2月更文挑战第26天】本文旨在全面概述TiDB的整体架构,深入剖析其关键组件和功能,从而帮助读者理解TiDB如何构建高效、稳定的分布式数据库。我们将探讨TiDB的计算层、存储层以及其他核心组件,并解释这些组件是如何协同工作以实现卓越的性能和扩展性的。通过本文,读者将能够深入了解TiDB的整体架构,为后续的学习和实践奠定坚实基础。
|
1月前
|
Web App开发 监控 应用服务中间件
全新架构!日志服务 SLS 自研免登录方案发布
全新架构!日志服务 SLS 自研免登录方案发布
87432 7
|
1月前
|
SQL NoSQL 数据库
深入浅出:微服务架构下的数据库事务管理
【2月更文挑战第12天】 在当今微服务架构日益流行的背景下,如何有效地管理跨服务的数据库事务成为了开发与维护中的一大挑战。本文旨在探讨微服务环境下数据库事务管理的关键技术和策略,包括但不限于分布式事务的基本概念、常见的解决方案(如两阶段提交、补偿事务等),以及这些方案在实际应用中的优缺点比较。通过深入浅出的方式,本文希望能够帮助读者更好地理解并应对微服务架构下的数据库事务管理问题,进而提升系统的稳定性和可靠性。
|
2月前
|
SQL 存储 缓存
后端架构优化方案探讨
【2月更文挑战第6天】在当今互联网时代,后端的稳定性和高效性至关重要。本文从数据库设计、服务器负载均衡、缓存策略等方面,探讨了后端架构优化的方案,旨在提供一些实用性的建议。