最易懂的数据库异地多活方案（异地多活数据同步）

最易懂的数据库异地多活方案（异地多活数据同步）

前言

随着业务发展越来越快，数据量越来越多，用户也越来越多，业务出现故障的几率也越来越大，而可用性是衡量一个系统的关键指标，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 即可解决，但在跨机房，跨城市的网络中，就显得尤为复杂。

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。