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

以下内容已屏蔽图片优化访问速度
[IMG]
作者:莫那·鲁道
原文:[IMG]由于是无状态的,可用性很好保证,当一个应用挂掉,直接切到另一个即可,最关键的是数据库的高可用,则是最复杂的。
今天我们将尝试探讨数据库的异地多活高可用。注意,我们讨论的都是超大数据量(50TB 级别)的数据库。
第一种
直接上分布式数据库,目前市面上常见的有 3 种,TiDB,阿里云 POLARDB,亚马逊 Aurora。
虽然 TiDB 可以将数据 sharding 到各个城市,但由于各个城市的物理距离导致的网络消耗,查询的效率可想而知(或许可以通过 Hash 的方式解决?)。 POLARDB 和 Aurora 是相同的思路,计算节点是分布式的,存储使用共享存储,带来的问题还是单机房问题。
因此,分布式数据库解决的还是超大数据的存储和单机房的 HA,一旦跨越城市,目前还没有看到好的方案。
第二种
在分库分表就能无限扩容吗一文中,我们提到了单元化。单元化说白了,就是先分库分表,然后,将数据库划分为固定的几个单元,使固定的业务进入固定的单元,这样,就不会出现每个业务都需要连接所有的数据库 —— 从而减小连接数。
在单元化的基础上,我们可以实现异地多活。
[IMG]
解释一下上图: 我们将 数据分成了 3 个数据库,同时,我们有3个城市的机房,红色表示为写节点,每个 shard 库最好只保证只有一个地方写,尽量避免双写的问题。 另外,杭州机房作为主机房。
上海机房的 shard 1 库在写入数据后,会同步到杭州主节点,北京机房的 shard 3 节点在写入数据后,也会同步到杭州主节点,杭州机房的 shard 2 写入数据后,也会同步到上海机房和北京机房。
其中,非红色数据库都是备库或读库。
我们假设,上海机房断电。
[IMG]
此时,杭州机房将会接管 shard 1 库,变成写入节点。
我们再假设,杭州机房断电。
[IMG]
杭州机房断电后,上海机房将会接管 shard 2 节点,同时,将 shard 2 节点的数据同步到北京机房,仍然保证可用性。
注意,这里为什么是上海机房的 shard 2 接管,而不是北京机房的 shard 2 接管呢?实际上,我是随便写的,在生产环境中,如果有超过 2 个副本,那么就需要使用 Raft 这种一致性协议来决策到底由谁来接管,这里为了简单,就写上海了。
我们观察到,其中,同步是核心,注意,使用 mysql 自带的同步是不可靠的,通常会自行开发一个稳定的,HA 的高可用复制系统,称之为 DRC,即数据复制中心,主要处理多城市或多机房的数据复制。
其中,阿里云已经有商业版的 DRC ,即 DTS,支持数据同步,数据订阅,数据迁移。而其底层则是 otter + canal,已经开源,不过比较简陋,想上生产环境的话,还需要二次开发和优化。
总结
本文简单的讨论了数据库的异地多活的方案,我们认为,在单元化的方案中,同步是核心,稳定的同步是保证数据一致的关键,而这,在单个机房中,只需要通过简单的 RPC 即可解决,但在跨机房,跨城市的网络中,就显得尤为复杂。
那么,如何打造一个高可用,低延迟,可靠的一致性,高吞吐的同步系统呢?
且听下次分享。
- MORE | 往期精彩文章 -
我们不再需要 Chrome 了?

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

跑路必备|错误跳槽,何止是穷半年?
高薪必备|Redis 基础、高级特性与性能调优

《HR黑话大全》:那些残忍的潜台词
全球最牛掰的 14 位大神,你知道几个??



如果你喜欢本文
请长按二维码关注民工哥技术之路
[IMG]
转发朋友圈,是对我最大的支持。
[IMG]
扫码加群交流
点击【阅读原文】公众号所有的精华都在这里
[IMG]
华为员工发飙:遇到了几个垃圾基层主管,动不动就谩骂和威胁员工 起底春晚的秘密!捧红羊肉串,一秒值万金......前边35年你都白看了 2019裁员潮启示录:有一种强大,叫“随时可以离开” 耐克创始人奈特:懦夫从不出发,弱者死于路中 日本“脑残”网红,用脚丰胸!200多款沙雕发明迟早把人类的头笑掉!
好看吗?
总执行时间0.07492542266845703,文章查询时间0.048253774642944336,分类查询时间0.009977579116821289,其他脚本0.00029015541076660156,模板渲染0.016403913497924805