阿里李运华:异地多活有哪些Impossible Mission?

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

《碟中谍》系列电影中,汤姆克鲁斯主演的亨特特工,无论什么情况,什么环境下都能够有惊无险的完成那些看似不可能的任务。


对于技术人员来说,如果也能像汤姆克鲁斯那样,不管什么mission impossible最后都能解决,那迎娶白富美,当上CTO,走向人生巅峰都不是问题!


“异地多活”看起来就是这样一个万能的大杀器,很多人理想中认为只要实现了“异地多活”,不管是新奥尔良水灾,美加大停电,蓝翔挖掘机。。。。。。等等都不再是问题。

 

不过,事实上,作为一个解决方案,异地多活是否最终有效,既取决于实施方如何去使用方案如何去设计(千万不要以为捡到倚天剑就是武林盟主),也取决于工具方案本身还有哪些不如意之处固有的约束和限制。要知道,即便是淘宝这样能够做到“异地多活”的公司而言,实际上也仍然有不够完美的地方。如果不意识到这些impossible mission,那么对于异地多活的理解就是错误的。


Impossible Mission1 - “实时异地多活”


异地多活本质上是通过异地的数据冗余,来保证在极端异常的情况下业务也能够正常提供给用户,因此数据同步是异地多活设计方案的核心。

 

通过网络将数据从A地同步到B地,会受限于一个普遍的物理规则,即:光速真空传播是每秒30万公里,在光纤中传输的速度大约是每秒20万公里,再加上传输中的各种网络设备的处理,实际还远远达不到光速的速度。


除了距离上的限制外,中间传输各种不可控的因素也非常多,例如挖掘机把光纤挖断,中美海底电缆被拖船扯断、骨干网故障等,这些故障是第三方维护,业务方根本无能为力也无法预知。

 

例如广州机房到北京机房,正常情况下RTT大约是50ms左右,遇到网络波动之类的情况,RTT可能飙升到500ms甚至1s,更不用说经常发生的线路丢包问题,那延迟可能就是几秒几十秒了。

 

因此“实时异地多活”是不可能实现的,因为不管是购买优质的运营商网络,还是采用云方案,甚至是自己拉光纤,都不可能突破物理上的限制,也不可能预防所有的意外情况。在设计异地多活方案的时候,业务上必须考虑这种时延或者中断的情况,不能认为底层传输是绝对可靠的。


Impossible Mission2 - 所有用户异地多活


不能实现“实时异地多活”就意味着某些极端情况下,肯定会有部分用户的数据无法及时同步到异地机房,这部分用户的业务在切换到异地机房后短时间内会异常。比如说小明在A机房成功发布了一条#某某明星出轨#相关的微博,此时A机房故障,数据还没有同步到B机房,我们将业务切换到B机房,此时小明登录到B机房就看不到自己刚才发的微博了!

 

这种情况下,运气好一些的话(比如说只是网络设备坏了)需要等到A机房业务恢复,数据重新同步到B机房;运气不好的话(比如说机器坏了,硬盘没坏)需要人工来修复数据,可能耗时几十分钟,也可能耗时几个小时;运气最差的情况下(比如说机房起火,硬盘被烧掉了)可能这些未同步的数据就永久丢失了。

 

站在用户的角度这样肯定很不爽(甚至直接打电话投诉开骂之类的),但这种现象也是无法完全避免的,异地多活不能保证每一个用户的业务无论在什么场景下都不受损,只要能保证绝大部分用户的业务在异常的场景下继续可用,就是很好的异地多活方案了。

 

虽然我们无法做到100%可用性,但并不意味着我们什么都不能做,除了抓紧时间恢复业务恢复数据外,为了让用户心里更好受一些,我们可以采取一些措施进行安抚或者补偿,例如:安抚、挂公告(“技术哥哥正在紧急处理”)、事后补偿(代金券、小礼包)等。


Impossible Mission3 - “所有业务异地多活”


异地多活效果看起来很诱人,但如果不假思索贪大求全的要求所有业务都实现异地多活的话,就会把自己带到坑里去。

 

第一个原因是异地多活是有成本的,包括开发成本和维护成本。需要实现异地多活的业务越多,方案越复杂,投入的设计开发时间越多;同时维护成本也会越高,需要更多的机器,需要更多的带宽。

 

第二个原因是有的业务理论上就无法实现异地多活。典型的有“余额”和“库存”这两个业务。


以余额为例,假设我们实现了余额的异地多活业务,用户小明有10000块钱,在A机房给女友转账了5000块,还剩余5000块;如果此时A机房异常且数据还没同步到B机房,小明登录到B机房发现自己又有10000块了,小明感觉中彩票了,赶紧又转了10000块给女友,最后出现了小明只有10000块却转账了15000块的问题,对于和资金相关的业务,这样的问题是绝对无法容忍的,哪怕一个用户有问题都不行。

 

所以,异地多活也不能保证所有业务都异地多活,在设计异地多活方案的时候,需要从业务和用户的角度出发,识别出核心和关键业务,明确哪些业务是必须实现异地多活,哪些是可以不实现异地多活,哪些是不能实现异地多活的。比如“登录”必须实现异地多活、“注册”和“修改用户信息”不一定要实现异地多活。


Impossible Mission4 - “通用的异地多活”


异地多活方案设计的关键是数据同步,提到数据同步我们自然而然的就想到了底层存储的同步功能,例如Oracle的数据复制、MySQL的数据同步、Redis的数据集群、云数据库跨机房复制等。如果使用这些底层存储方案的同步功能就能实现异地多活,那异地多活方案实现就很轻松了。

 

但现实显然没有这么美好,原因就在于这些底层存储的同步方案是通用的解决方案,无法基于业务的特点来有针对性的处理,而且这些底层同步方案一样会有bug,一样会延迟。以MySQL为例,MySQL5.1版本的复制是单线程的复制,在网络抖动或者大量数据同步的时候,经常发生延迟较长的问题,短则延迟十几秒,长则可能达到十几分钟。而且即使我们通过监控的手段知道了MySQL同步时延较长,也难以采取什么措施,只能干等。

 

所以只通过底层存储的同步方案来实现异地多活是不可能的,我们不能把鸡蛋都放到一个篮子里面,需要结合多种手段来实现业务数据同步或者读取,例如:重新生成数据、消息队列异步同步数据、多个机房间通过API直接访问数据等。


一句话谈异地多活


综合前面的分析,异地多活设计的理念可以总结为一句话:“采用多种手段,保证绝大部分用户的核心业务异地多活!”


不要被那些号称用一个工具或者方案解决所有问题的说法给骗了,工程领域不存在“银弹”。


=============================================================================================

本文首发云头条,同步CSDN和云栖社区,转发请注明出处。

云头条:阿里李运华:异地多活有哪些你不知道的坑?

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
9天前
|
存储 运维 负载均衡
探索容灾架构演进之路 - 从单点到异地多活
容灾架构的选择在于平衡可用性需求和成本之间的关系。并不存在一种完美的架构,而是应该根据业务发展的阶段逐步演进容灾架构,避免陷入过度设计和资源浪费的困境
171 0
|
5月前
|
容灾 关系型数据库 分布式数据库
|
12月前
|
编解码 弹性计算 人工智能
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章7:《基于倚天的视频云原生业务新范式》(3)
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章7:《基于倚天的视频云原生业务新范式》(3)
118 0
|
12月前
|
人工智能 弹性计算 编解码
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章7:《基于倚天的视频云原生业务新范式》(1)
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章7:《基于倚天的视频云原生业务新范式》(1)
108 0
|
12月前
|
存储 编解码 人工智能
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章7:《基于倚天的视频云原生业务新范式》(2)
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章7:《基于倚天的视频云原生业务新范式》(2)
122 0
|
12月前
|
监控 Cloud Native Dubbo
带你读《云原生架构白皮书2022新版》——Game On Serverless:SAE 助力广州小迈提升微服务研发效能(下)
带你读《云原生架构白皮书2022新版》——Game On Serverless:SAE 助力广州小迈提升微服务研发效能(下)
262 0
|
12月前
|
机器学习/深度学习 存储 人工智能
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章8:《OPPO云边端的协同实践》(下)
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章8:《OPPO云边端的协同实践》(下)
128 0
|
12月前
|
机器学习/深度学习 存储 人工智能
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章8:《OPPO云边端的协同实践》(上)
《云上新势力 CLOUD IMAGINE》——Part 2 演讲/文章合集——文章8:《OPPO云边端的协同实践》(上)
189 0
|
运维 容灾 安全
解决方案架构师郭援非:OceanBase助力金融ECIF“大机下移”分布式
随着“以客户为中心”逐渐成为金融业的战略重心,整合企业各系统分散客户信息的ECIF(Enterprise Customer Information Facility,企业级客户整合系统)应运而生。 ECIF 通过整合企业现有业务系统中的所有客户信息,实时保留客户的最新信息,为各应用系统以联机交易的方式提供实时的、完整的、共享的、一致的客户信息,建立起企业级的客户信息识别系统,在全企业范围内为客户信息的使用和管理提供服务,已成为金融业“以客户为中心”的战略性基础系统。
361 0
解决方案架构师郭援非:OceanBase助力金融ECIF“大机下移”分布式
|
存储 容灾 定位技术
阿里异地多活架构新突破:库存单元化部署技术思路揭秘(1)
阿里异地多活架构新突破:库存单元化部署技术思路揭秘
1064 0