登录| 注册| 付款方式| 代理加盟 | 帮助中心 | 控制面板| 备案登录| 工单 统一服务热线: 0574-86686859

关于我们

Impossible Mission1 - “实时异地多活”

 作者:云工坊  文章来源:云工坊  点击数:1658  更新时间:2016-12-07

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

 

通过网络将数据从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直接访问数据等。


一句话谈异地多活


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


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


0574-86686859  
返回顶部