MySQL异地双活方案

Posted by BY lingjun on June 10, 2019 本文总阅读量

MySQL异地双活方案

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

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

一句话谈异地多活

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

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

基于MySQL原生复制主主同步方案

基于Galera replication方案