怎么看支付宝在光纤被挖恢复中的技术表现？
5.27日下午17时许，支付宝被反映故障；18时许，支付宝通过官方微博给出回应，解释是因为电信运营商光纤被挖断。19时许，支付宝服务恢复正常。22时许，支付宝官方微博正式回应复原了整个事件。
围绕整个事件有很多讨论，讨论的中心最主要的有两点：“为什么光纤被挖断，会造成整个机房瘫痪”、“为什么支付宝的业务恢复用了两个小时”。其中，第一个问题，应该是电信运营商的光纤灾备出现问题。
第二个焦点问题“为什么支付宝用了2个小时恢复了业务”，一堆所谓“业内人士”众说纷纭。其实，这应该是中国金融史上，首次完全意义的灾难成功切换案例。在此之前，中国金融行业投入重金建设的灾备系统基本上有这么两类用武之地（一般来说，增建一个灾备数据中心的建设成本是单数据中心成本的1.1-1.2倍）：
1.计划内灾备切换演习，全副武装、如临大敌、不开一枪、全身而退。
2.因系统升级造成的被动灾备切换，例如2013年闹得沸沸扬扬的某行DB2升级造成的系统回滚切换。万幸的是，这是发生在凌晨的系统升级故障，当时没有实时交易发生；某行也准备了各种应急预案，只是恢复的时间超出了计划，网点推迟了一个小时开业而已；而另一家西部的区域银行就没有这么强的科技实力了，同样是DB2升级失败，系统恢复时间用了37小时40分钟（37小时啊，吼吼，坐火车都到莫斯科了）
像昨晚支付宝这种突发情形下的灾备切换还真是头一遭，而且居然成功了。支付宝虽然运气差了点，但技术能力还真不是一般金融机构能拼的。
在支付宝微博答复中，有一个新名词——“异地多活”。在传统了灾备方案中，一般提的都是同城灾备、异地灾备、两地三中心。与传统的灾备技术相比，异地多活的特点是：在不同地点的数据中心都可以同时支持业务，而且每个地点发生的交易都是真实业务流量，而不是常见的一主一备，如果主中心没有问题，备份中心永远都是“备胎”。
这种多活数据中心的好处是：因为所有的数据中心都在支持交易，所以能节约IT成本；另外传统方式中备份系统都不在真实的交易活动状态，所以很难判断它的状态到底怎么样，在出现问题时，都不一定敢切过去。
大规模的“异地多活”，据说目前全球除了阿里能做到，也就Google和Facebook实现了，还是非金融类的业务。中国银行业，只有某国有大行在去年6月份实现了上海同城两个数据中心的双活，是“同城双活”，还没有实现“异地多活”，而且在灾难真正发生时，切换效果如何，还有待验证。
昨天是支付宝“异地双活”第一次真刀实枪的上战场，支付宝因为要满足金融行业的很多要求，特别是对交易一致性、数据完整性等方面的要求，目前还处于小范围试用阶段，没有全体上线，例如昨天杭州机房瘫痪后，有一部分流量跑在支付宝异地机房。因此，在昨天支付宝2小时整体恢复之前，并不是所有交易都停止的，并且基于“异地多活”技术，实现了这部分用户的无感知切换。
对另外没有通过“异地多活”技术切换的交易流量，支付宝选择了最稳妥的做法：首先进行了完整的数据校验，保证所有客户的客户信息、账户信息、资金信息、交易信息都是正确的，一切确认完成后，才重新“开门迎客”。这个过程耗时了一个多小时，不过相比较支付宝数亿客户所对应的校对数据量，这个时间还是可以接受的。
侧面印证切换效果的是：被挖断的光纤修到半夜才恢复，而支付宝的业务在晚间19点多恢复正常。
客观来讲，支付宝的这次表现，是一次说不上完美、但很成功的真实灾难切换，也是中国金融史上第一次在完全突发情形下，成功完成切换的真实案例。整个切换过程中，没有一条客户数据丢失，也体现了金融级的数据高可用要求，虽然切换的时间对用户来说长了点，但“就像是一次跳水，整体完成的质量很高，只是落水时水花没有压好，水花稍微大了点。”
估计经过这次折腾，支付宝全盘推进“异地多活”的速度会加快，可能在今年七八月份实现。真正实现异地多活后，阿里在金融领域所能提供的解决方案，安全性和用户体验将比传统IT的异地灾备技术提升一个很大的量级。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
