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

很久没写了,要长草了。
今天咱们来聊聊高可用系统架构的热点——异地多活。
现在比较吊的多活方式是异地三节点,有多少公司真正实现了就不得而知了。为什么要做异地多活,主要是为了提升系统的容灾能力,比如单机房的网络故障、地震火灾等不可抗因素,都有可能造成整个机房瘫痪。
在上一家公司负责支付系统开发的时候,由于我们在天津机房的硬件设施太过老旧,经常时不时地网络故障,进而逼我们搭建了一个异地多活的架构。我们先来看看我们当时的做法。整个部署结构如下图:

            

  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

时间: 2016-08-15

聊聊高可用架构——异地多活的相关文章

2017QCon分享:从淘宝到云端的高可用架构演进

大家好,我今天分享的题目是<高可用实践:从淘宝到上云的差异>,取这个标题是因为会涉及到两个方面内容,一方面以淘宝为例子,传统的IDC的时候,我们稳定性是怎么做的,另外在云计算背景下,有很多创业公司是基于阿里云这样的公有云基础设施做研发,在公有云的环境下怎么做好我们系统的高可用. 长期做稳定性的人会有一些职业病,记得去年冬天有个周末,我要寄快递,穿着睡衣在门口填快递单,那时候我家里养了一只猫,因为怕猫跑出去,就把门关上了.寄完快递口袋一掏发现自己没带钥匙,冷静了3秒钟,打车到公司刚巧碰到同事,看

八年来我们到底经历了什么?——中间件专家带你“重走”双11高可用架构演进之路

双11的技术挑战 双11技术挑战的本质使用用有限的成本去是实现最大化的用户体验和集群整体吞吐能力,用最合理的代价解决零点峰值,支撑好业务的狂欢.阿里做双11已经有八年之久了,八年来双11的交易额增长200倍,交易峰值增长400多倍,系统复杂度和大促支撑难度以指数级攀升:并且经过多年的发展,双11技术实现链条中的变量不断增加,如峰值的增量和系统架构的变化.交易峰值的组成.拆单比.每个业务入口的访问量等,这些变量也给系统带来了不确定性.回顾这八年的双11零点之战,它推动了阿里的技术进步.推动了架构优

面向业务的立体化高可用架构设计

原文链接:http://www.csdn.net/article/2015-10-27/2826042 ======================================================== 面向业务的立体化高可用架构设计 发表于2015-10-27 10:47| 2924次阅读| 来源<程序员>杂志| 8 条评论| 作者李运华 <程序员>杂志2015年10月B架构李运华面向对象 摘要:为了实现阿里九游游戏接入系统的业务高可用,技术人员跳出传统的面向系统的

纯干货 | 从淘宝到云端的高可用架构演进

近日在Qcon开发者大会北京站上,来自阿里巴巴商家事业部技术专家沐剑在专场分享了题为<高可用实践:从淘宝到上云的差异>的演讲,主要介绍了其近几年在阿里电商平台及阿里云上的高可用设计的经验,分为两个部分:第一部分主要包括传统的淘宝店铺稳定性体系的建设及相关的基础链路设计.缓存和容灾方案的设计及部署:第二部分主要包括目前公有云高可用设计的主要思路.经典故障及应对措施等. 演讲全文: 沐剑 大家好,我今天分享的题目是<高可用实践:从淘宝到上云的差异>,取这个标题是因为会涉及到两个方面内容

【干货】阿里资深技术专家丁宇谈双11高可用架构演进之路

近日Velocity China 2016在京举行,会上阿里中间件技术部资深技术专家丁宇(花名叔同)发表了题为<零点之战–阿里双11高可用架构演进之路>的演讲.丁宇从2009年开始,参加了每年的阿里双11技术保障工作, 最近两年他分别以共享平台事业部双11项目负责人,和集团双11项目稳定性总负责人的身份参与其中. 阿里巴巴平台的业务规模在过去的8年呈指数级增长,给双11所带来的技术挑战是世界性的,特别是如何在零点峰值到来时确保系统的稳定性.零点技术挑战的本质是用有限的成本去实现最大化的集群整体

来自 Google 的高可用架构理念与实践

在 Google 我参与了两个比较大的 Project. 第一个是 YouTube,其中包括 video transcoding,streaming 等.Google 的量很大,每个月会有 1PB 级别的存储量.存储.转码后,我们还做 Global CDN.到 2012 年的时候,峰值流量达到 10 TBps,全球 10 万个节点,几乎每台机器都是 16/24 核跑满, 10G uplink 也是跑满的状态. 然后我加入了 Google Cloud Platform Team, 也就是 Borg

《高可用架构·中国初创故事(第3期)》一来自Google的高可用架构理念与实践

来自Google的高可用架构理念与实践 CTO @ coding.net .2007 - 2015 年初在 Google 的 Moutain View 担任 SRE (Site Reliability Engineering)职位. 参与了 Google 的两个项目:第一个是 Youtube,工作内容涵盖 Video transfer.Coding.Streaming.Global CDN 等:第二个是 Google Cloud Platform Team,主要工作是管理 Google 全球 1

MySQL小型高可用架构(组合)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换   服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构     MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案   服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为

《高可用架构·中国初创故事(第3期)》一会会:一个产品经理的创业方法论

会会:一个产品经理的创业方法论 高可用架构·中国初创故事(第3期) 会会的融资过程很传奇,李翔昊拿到经纬王华东的天使投资时,刚开始产品研发,甚至连公司注册都没有完成.一个尚处于设想中的产品可以获得知名VC的投资,李翔昊在职业社交领域多年积累的经验和思考起到了关键的作用.创业之前,李翔昊在人人.大街有多年产品设计和项目管理经验.作为曾经的企业管理者,现在站在创业者的角度,他对管理方式,开发节奏,产品设计有哪些思考和见解呢? 拒绝数字的诱惑,耐心打磨产品今天的中国互联网,用户推广是一件成本很高的事,