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

Posted 2021-01-09 jsjwk

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

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

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

针对多机的架构，常见有如下做法：

• 单中心数据集群

• 多中心数据分区

下面我们来具体看看：

一、单中心的数据集群架构（单中心多机）

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

• 数据集中模式

• 数据分散模式

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

1. 数据集中模式

如图，

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

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

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

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

2. 数据分散模式

如图，

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

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

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

二、多中心的数据分区架构（多中心多机）

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

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

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

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

• 集中备份式

• 独立备份式

• 相互备份式

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

1. 集中备份式

如图，

 

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

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

2. 独立备份式

如图，

（参考图片）

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

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

3. 相互备份式

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

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

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

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

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

本文原创发布于微信公众号「 不止思考 」，交流Java、Web、架构、大数据、职业发展、技术管理，欢迎关注。