编程学习网 > 数据库 > 最易懂的数据库异地多活方案
2019
07-09

最易懂的数据库异地多活方案

前言

随着业务发展越来越快,数据量越来越多,用户也越来越多,业务出现故障的几率也越来越大,而可用性是衡量一个系统的关键指标,application 由于是无状态的,可用性很好保证,当一个应用挂掉,直接切到另一个即可,最关键的是数据库的高可用,则是最复杂的。

今天我们将尝试探讨数据库的异地多活高可用。注意,我们讨论的都是超大数据量(50TB 级别)的数据库。

第一种

直接上分布式数据库,目前市面上常见的有 3 种,TiDB,阿里云 POLARDB,亚马逊 Aurora。

虽然 TiDB 可以将数据 sharding 到各个城市,但由于各个城市的物理距离导致的网络消耗,查询的效率可想而知(或许可以通过 Hash 的方式解决?)。 POLARDB 和 Aurora 是相同的思路,计算节点是分布式的,存储使用共享存储,带来的问题还是单机房问题。

因此,分布式数据库解决的还是超大数据的存储和单机房的 HA,一旦跨越城市,目前还没有看到好的方案。


第二种

在分库分表就能无限扩容吗一文中,我们提到了单元化。单元化说白了,就是先分库分表,然后,将数据库划分为固定的几个单元,使固定的业务进入固定的单元,这样,就不会出现每个业务都需要连接所有的数据库 —— 从而减小连接数。

在单元化的基础上,我们可以实现异地多活。

解释一下上图: 我们将 数据分成了 3 个数据库,同时,我们有3个城市的机房,红色表示为写节点,每个 shard 库最好只保证只有一个地方写,尽量避免双写的问题。 另外,杭州机房作为主机房。

上海机房的 shard 1 库在写入数据后,会同步到杭州主节点,北京机房的 shard 3 节点在写入数据后,也会同步到杭州主节点,杭州机房的 shard 2 写入数据后,也会同步到上海机房和北京机房。

其中,非红色数据库都是备库或读库。

我们假设,上海机房断电。

此时,杭州机房将会接管 shard 1 库,变成写入节点。

我们再假设,杭州机房断电。

杭州机房断电后,上海机房将会接管 shard 2 节点,同时,将 shard 2 节点的数据同步到北京机房,仍然保证可用性。

注意,这里为什么是上海机房的 shard 2 接管,而不是北京机房的 shard 2 接管呢?实际上,我是随便写的,在生产环境中,如果有超过 2 个副本,那么就需要使用 Raft 这种一致性协议来决策到底由谁来接管,这里为了简单,就写上海了。

我们观察到,其中,同步是核心,注意,使用 mysql 自带的同步是不可靠的,通常会自行开发一个稳定的,HA 的高可用复制系统,称之为 DRC,即数据复制中心,主要处理多城市或多机房的数据复制。

其中,阿里云已经有商业版的 DRC ,即 DTS,支持数据同步,数据订阅,数据迁移。而其底层则是 otter + canal,已经开源,不过比较简陋,想上生产环境的话,还需要二次开发和优化。

总结

本文简单的讨论了数据库的异地多活的方案,我们认为,在单元化的方案中,同步是核心,稳定的同步是保证数据一致的关键,而这,在单个机房中,只需要通过简单的 RPC 即可解决,但在跨机房,跨城市的网络中,就显得尤为复杂。

那么,如何打造一个高可用,低延迟,可靠的一致性,高吞吐的同步系统呢?

扫码二维码 获取免费视频学习资料

Python编程学习

查 看2022高级编程视频教程免费获取