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

最易懂的数据库异地多活方案_第1张图片

 
   

作者:莫那·鲁道
原文:http://thinkinjava.cn/2019/02/yddh/

前言

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

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

第一种

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

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

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

第二种

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

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

最易懂的数据库异地多活方案_第2张图片

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

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

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

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

最易懂的数据库异地多活方案_第3张图片

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

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

最易懂的数据库异地多活方案_第4张图片

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

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

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

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

总结

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

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

且听下次分享。

- MORE | 往期精彩文章 -

  • 我们不再需要 Chrome 了?

  • “菜鸟”程序员和“大神”程序员的差别竟然这么大...

  • 跑路必备|错误跳槽,何止是穷半年?

  • 高薪必备|Redis 基础、高级特性与性能调优

  • 《HR黑话大全》:那些残忍的潜台词

  • 全球最牛掰的 14 位大神,你知道几个??


如果你喜欢本文

请长按二维码关注民工哥技术之路

最易懂的数据库异地多活方案_第5张图片

转发朋友圈,是对我最大的支持。

最易懂的数据库异地多活方案_第6张图片

扫码加群交流

点击【阅读原文】公众号所有的精华都在这里

640?wx_fmt=gif

你可能感兴趣的:(最易懂的数据库异地多活方案)