聊聊高可用架构——异地多活

简介: 相较于目前主流的“两地三中心”,“异地多活”技术实现了质的飞跃,可以为用户“提供‘丝般柔顺’的用户体验”。本文就聊聊异地多活的高可用架构。
很久没写了,要长草了。
今天咱们来聊聊高可用系统架构的热点——异地多活。
现在比较吊的多活方式是异地三节点,有多少公司真正实现了就不得而知了。为什么要做异地多活,主要是为了提升系统的容灾能力,比如单机房的网络故障、地震火灾等不可抗因素,都有可能造成整个机房瘫痪。
在上一家公司负责支付系统开发的时候,由于我们在天津机房的硬件设施太过老旧,经常时不时地网络故障,进而逼我们搭建了一个异地多活的架构。我们先来看看我们当时的做法。整个部署结构如下图:
             7497cfece9ffdfacadf67f646a24dc1a7287510f
  1. 通过域名做负载均衡,将请求路由到最近的可用服务的机房
  2. 服务全部机房内自治,不进行跨机房访问
  3. DB(mysql)仅有一个,机房2跨机房访问机房1的DB进行读写
整个架构看起来是可行的,并且当时也是有在生产环境使用。但是不难看出,机房2的服务,在响应时间上肯定要比机房1更慢。因为跨机房访问数据库带来了一定的网络延时,在最正常的情况下,通过当时购买的专线,可以控制在数十ms以内。
当机房1故障时,通过dns切换(据说可以智能切换,不过我们当时并没有实施)关闭机房1的请求,然后将机房2的数据库从slave升级为master,就可以完成整个容灾过程。看起来并不是全自动的,但至少比服务长时间瘫痪等待机房修复要好。而且,dns切换以及db切换,都可以通过自动的方式来实现。
上面的方案实现简单,对于一般的业务也够用了。但是,存在以下几个问题。而这几个问题,也是异地容灾跨不过的坎。
  1. 机房间延时。不管是机房2访问机房1的DB,还是DB之间的主从同步,都进行了跨机房的网络请求,其延时是难以避免的。
  2. 专线网络需要花钱,而且不便宜。严格来讲,你拉一条专线网络,这也是一个单点服务。如果要做到专线网络容灾,价格应该至少要翻番吧。
  3. 数据同步。对于实时性要求不高的业务,比如微信发朋友圈,可以允许延时。但对于支付(账号余额)这种数据来讲,必须是强一致性的。如果机房1挂了,机房2备份库的数据还是一份脏数据,那必然会带来重大的损失。所以,这种数据同步方案,对于强一致性要求的数据,是不可接受的。对于强一致性的数据,只有通过人为修复确保都更新到位后,才能恢复服务。也就是在此期间,其实服务也处于不可用状态。
通过以上分析,我们不难看出,1.2两个缺点,可以勉强花钱解决,但是对于3,花钱也解决不了。那么,对于强一致性要求的数据,我们如何来做容灾呢?
  1. 机房1、机房2实现双主(Master-Master)的数据库架构。两个数据库分别置于机房1和机房2,实现读写。master之间通过mysql的内部实现,进行数据同步。这个方案其实跟之前的方案区别不大,只是减少了服务去访问数据库的网络延时,属于一个伪数据强一致性方案。而且双主很依赖网络延时进行数据同步,同时容易出现脑裂现象,个人不推荐使用。
  2.  通过业务层来实现分布式事务,以此来确保两个机房数据的强一致性。两个数据库分别置于两个机房中,通过业务程序来实现分布式事务,也就是通过业务层来确保数据库1和数据库2都更新成功,才视为更新成功。这样确实可以保证数据库1和数据库2的数据强一致性。但是增加了系统的实现复杂度,也增强了对开发人员能力的要求。另外,分布式事务会增加业务处理时长以及失败率,如果单机房故障一年都仅有几个小时,这种分布式的代价是否值得呢?
  3. 将服务状态化。对用户进行分区,将用户请求固定路由到机房1或机房2。如此一来,两个机房不会对同一份数据进行更新,也就避免了数据强一致性的要求。同时,这两个数据库之间,仍然通过主备进行数据备份。当其中一个机房故障时,通过人为修复该机房同步到另外一个机房的数据后,再恢复机房1中的服务。对比在上家公司已实现的方案,这种方案有两个优点:减小了跨机房访问数据库的延时;减小了受灾用户群体。个人觉得该方案不错,但是如何在dns解析域名时进行状态化呢?如果又引入中间件,那不是又单点了吗?

好吧,如果细读了CAP理论,就会发现这个问题是没有十全十美的解决方案的。在这个问题上,我更加倾向于的解决方案是:使用阿里云服务,增加可用性。你有更好的方案吗,欢迎给我留言。


本文转载自 微信公众号 chiukong_diary

原文链接 : http://mp.weixin.qq.com/s?__biz=MzI0MzQ5MzMwMg==&mid=2247483662&idx=1&sn=e45bf4b395e727f543edc827fc050ee5&scene=1&srcid=0814e9DLDRSshqsi6PaGq116&from=groupmessage&isappinstalled=0#wechat_redirect


目录
打赏
0
0
0
0
455
分享
相关文章
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
550 57
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
450 21
RocketMQ原理—5.高可用+高并发+高性能架构
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
678 3
Mysql高可用架构方案
控制员工上网软件:高可用架构的构建方法
本文介绍了构建控制员工上网软件的高可用架构的方法,包括负载均衡、数据备份与恢复、故障检测与自动切换等关键机制,以确保企业网络管理系统的稳定运行。通过具体代码示例,展示了如何实现这些机制。
192 63
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
315 0
云端问道9期实践教学-省心省钱的云上Serverless高可用架构
详细介绍了云上Serverless高可用架构的一键部署流程
108 10
卓越效能,极简运维,Serverless高可用架构
本文介绍了Serverless高可用架构方案,当企业面对日益增长的用户访问量和复杂的业务需求时如何实现更高的灵活性、更低的成本和更强的稳定性。
如何基于服务网格构建高可用架构
分享如何利用服务网格构建更强更全面的高可用架构
阿里云 SAE 邀您参加 Serverless 高可用架构挑战赛,赢取精美礼品
阿里云 SAE 邀您参加 Serverless 高可用架构挑战赛,赢取精美礼品。
卓越效能,极简运维,体验Serverless高可用架构,完成任务可领取转轮日历!
卓越效能,极简运维,体验Serverless高可用架构,完成任务可领取转轮日历!

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问