1. 聚能聊>
  2. 话题详情

异地多活设计有哪些常见的难点和技巧?

业务的可用性对用户的体验至关重要,如果业务经常动不动就不可用,再好的业务都会没人用,异地多活正是保障业务即使在各种极端异常情况下都可用的利器,例如机房断电、地震、城市水灾、蓝翔挖掘机挖断光纤等。

异地多活虽然听起来很美好,但在设计上却有很多的挑战,很多人都会觉得“异地多活”的方案设计很难,业务、网络、数据、事务等各种问题混杂在一起,很多问题看似是无法解决的。比如说:“网络断了怎么保证数据一致性”、“怎么保证异地事务一致性”、“业务怎么无缝的在多个地点切换”。。。。。。等等。

你的业务是否也有类似的异地多活的需求和困惑?如何才能设计优秀的异地多活方案?有哪些技巧 ?来吧,咱们一起聊聊 :)
2016_10_10_203657

参与话题

奖品区域 活动规则 已 结束

  • 奖品一

    淘公仔 x 4

  • 奖品二

    虾米VIP季卡 x 1

  • 奖品三

    聆听专属T恤衫 x 3

83个回答

1

周庭旺 已获得淘公仔 复制链接去分享

秒杀商品存在对库存做多机房分布的情况,也就是会按照商品id分布在不同机房进行秒杀。在发生某一个机房不可用时,这时不可用机房的数据可能还没完全同步到其他机房,这时怎么可以让其他机房来安全接替(不会出现数据冲突)垮掉机房的业务呢?

华仔爱技术 回复

前面的讨论也涉及这个议题,这里再贴一下:

“库存”和“余额”是异地多活设计的两大难点,因为这两个数据需要做到实时强一致性。

不管是支付宝还是银行,对于单个用户的余额的异地多活是实现不了的,也就是说单个用户的余额是没法做异地多活的,这就是支付宝敌不过蓝翔挖掘机的原因。
可以通过将用户分布在多地,实现系统层面用户异地多活,即:某个数据中心有故障只影响部分用户,其它数据中心的用户是可以继续使用业务的。

库存类似,如果某个商品的库存不限制购买数量,那就没有办法做异地多活;
如果某个商品限制只能购买一定数量,则可以通过取巧的方式来实现,即:将库存分布到异地多活的多个中心去,每个数据中心先读取本地的库存,不够的话再从其它数据中心分一些过来。
例如:iphone7限制每人一台,现在有1000台,广州仓库分500,北京仓库分300,上海仓库分200,如果上海的卖完了,就看广州和北京是否还有库存。如果你经常在京东买东西就会发现,京东有一个从其它地方调货的功能,只是物流配送时间长一些而已。

华仔爱技术 回复

另外,秒杀活动一般都是临时或者突发的,更加主动应急和故障处理,不一定要做异地多活。

欧阳@dl 回复

@"单个用户的余额是没法做异地多活的,这就是支付宝敌不过蓝翔挖掘机的原因。"
若是这样,支付宝吹的异地多活(数据同步、分钟级IDC切换)有何高深莫测之术?

评论
0

1164827188210306 已获得虾米VIP季卡 复制链接去分享

我们是做证券交易的,我们的方案是先异地部署多个交易中心,有各自独立的数据库,然后将用户划分到不同的交易中心,并将用户请求路由到对应的交易中心,这样就实现了交易中心异地多活。交易中心本身支持异地异步数据复制。
这样在某地区机房瘫痪时,受影响的交易中心只有未来得及复制的数据部分会有影响(丢失),剩下交由业务层去判断和处理故障。
这种方式不能够完全处理好故障,只能尽量减少故障影响到的用户,主要是因为是交易系统,我们还要兼顾性能,我们也头疼找不到一个比较完美的方案。

华仔爱技术 回复

这是比较标准的做法,异地多活在目前的技术水平下是找不到完美的解决方案的,因为有几个固有的因素:
1)网络的传播速度:这是受限于物理规律,光速在真空中的传播速度也只有每秒30万公里,在光纤总传播只有20万公里每小时,加上中间各种设备的处理,实际上延时还是挺大的
2)墨菲定律:再怎么小概率的事情,最终都一定会发生

只要能保证绝大部分用户核心业务异地多活就是好方案!

gkm102924 回复

如果交易数据丢失怎么办?有没有可能通过就近数据互备的方式来实现交易数据不丢失?

华仔爱技术 回复

交易数据通常的做法是多重手段保护:
1)本机交易日志:每个生成交易相关的系统,首先在本地(可以是硬盘,也可以是单纯的存储系统)写一个交易日志
2)本地数据库:本地交易数据存储
3)远端备份

通过这三种手段,基本上可以保证几乎不丢数据,但极端情况下一两个用户还是有可能的,这个影响范围不大,可以忍受。

评论
1

初码 已获得聆听专属T恤衫 复制链接去分享

我的理解,余额等强一致性的场景,异地多活不现实,支付宝和银行都应该是一个核心主库吧,主要是在数据库上做文章。
库存等展示型场景的异地多活,主要靠缓存和同步机制,也没必要做100%一致,如果再用一些云服务,比如大内网,再比如微软的SQL Azure等,又比如CDN的使用等等,这时候多做一些Web节点就可以
其实云服务真的挺好,解决了很多架构设计上的的技术投入产出效率低下问题

华仔爱技术 回复

云服务让好多架构师都要失业了 :(

聚小编 回复

好专业~

流浪小马 回复

还在学习

评论
1

wanl 已获得淘公仔 复制链接去分享

我这边做的教育系统异地多活。按照地域分配访问到不同机房。每个机房的部署架构一致,多机房数据库互为主从,保证最终一致性,允许数据同步延迟,因为用户不会从一个地域瞬间移动到另一个的地域,他看到的始终是实时的数据。同步数据存在id冲突的问题,通过id生成器配置每个机房的id范围解决。异地多活解决的容灾,就近访问问题。有些事务要求强一致性要特殊考虑

华仔爱技术 回复

赞,异地多活不存在通用的方案,还是需要结合业务具体情况来分析和实现

medusar 回复

这种是如何把用户的分到不同的数据中心呢?我们之前是按照用户的网络运营商,但是这样就有可能手机信号和wifi使用的不是同一个运营商,从而导致用户的请求可能会很容易落到其它数据中心。

评论
0

痞子不俗 已获得聆听专属T恤衫 复制链接去分享

个人见解:数据,网路和应用都达到双活和多活才算真正意义上的有效的架构。现实中很难很难,宣传的很美,实际好多坑!分布式双活数据中心的建设是一个复杂的系统工程,它不仅仅要求网络系统双活,更是涉及到服务器系统、数据库系统和存储系统,甚至和客户的具体应用也是息息相关。上层应用通过大二层网络对外提供服务的通道对底层数据进行有效读写,还要实现可靠的负载均衡,真的太难了!数据中心间的网络延迟不能高于几毫秒,否则强一致性很难实现。根据业务要求划分有效的故障域是个不错的选择,数据的一致性可以分阶段分区域进行。

痞子不俗 回复

下面两点毫秒以内很重要:
数据读写延迟,网络可达延迟!
数据读写延迟,网络可达延迟!
数据读写延迟,网络可达延迟!
重要的事情说三遍!

华仔爱技术 回复

异地多活本质上是无法实现强一致性的,这是物理条件限制的,即:光速的传播速度真空中每秒30万公里,光纤中每秒大约20万公里,加上中间各种网络设备的处理和时延,实际上远远没有那么快。
广州到北京的光纤,正常情况下50ms延时已经是很好的网络了,不可能达到几毫秒的延时。

痞子不俗 回复

不好意思,为啥现在才看到所写的内容?刚发布时都有,然后就消失了!难道这是遇到数据同步一致性问题?后面的两个评论麻烦删除了,我误解了!不好意思

华仔爱技术 回复

也许就是数据同步问题 :)

评论
1

1924229858864781 已获得聆听专属T恤衫 复制链接去分享

我的理解,余额等强一致性的场景,异地多活不现实,支付宝和银行都应该是一个核心主库吧,主要是在数据库上做文章。
库存等展示型场景的异地多活,主要靠缓存和同步机制,也没必要做100%一致,如果再用一些云服务,比如大内网,再比如微软的SQL Azure等,又比如CDN的使用等等,这时候多做一些Web节点就可以
其实云服务真的挺好,解决了很多架构设计上的的技术投入产出效率低下问题

华仔爱技术 回复

打赏时手误了,这个答案是拷贝的,不过还是鼓励一下,希望后面有自己的真知灼见!

评论
1

易宝支付 复制链接去分享

对于第三方支付公司而言,如果异地多活能自定义规则来实现自动报警,在任何时候能实现无感知的自动切换,保证交易不受影响……那就是完美了!保证支付宝光缆事件不再发生

易宝支付 回复

很想实现这种方式

华仔爱技术 回复

第三方支付分两类:一类是和支付宝一样保存有用户数据的支付系统;一类是不保存数据只是负责向支付宝这类系统发起请求的支付网关。

支付系统无感知自动切换是做不到的,人工都没法切换,只能修复故障。
支付网关是可以做到自动报警和自动切换的。

idealities 回复

有没有运维的机器人可以做到这种?提供好故障诊断和备选方案,来做自动的切换。就像人体的某处皮肤破损,大脑是不需要关心怎么修复的,而是会自动处理。

华仔爱技术 回复

目前的技术水平离人体的恢复功能还差十万八千光年 :)

故障诊断本身就是一个很复杂的过程,而且切换也是有代价的,所以绝大部分业务都不能简单的做成自动化。
目前来看,门户网站、资讯站这类不涉及用户UGC或者用户核心数据变更的系统才能这么做,稍微复杂的支付宝、微信、QQ、滴滴这些都不能这样做。

idealities 回复

这个我当然知道,只是幻想一下而已。

评论
0

1277076156971513 已获得淘公仔 复制链接去分享

对于一些秒杀商品,存在对库存做多机房分布的情况,也就是会按照商品id分布在不同机房进行秒杀。在发生某一个机房不可用时,这时不可用机房的数据可能还没完全同步到其他机房,这时怎么可以让其他机房来安全接替(不会出现数据冲突)垮掉机房的业务呢?

华仔爱技术 回复

如果是根据商品id将秒杀商品分布在不同的机房,当某个机房不可用时,这个机房的商品不可秒杀,其它机房也无法接管,因为库存是实时强一致性的。

秒杀活动是临时和突发的,并且持续时间不长,一般注重故障应急,而不是做异地多活。

如果一定要做异地多活,有变通的方案,但比较复杂,这里给一个假想的案例,供参考,业务场景:假设有两个业务中心北京和上海,现在要做iphone7秒杀,总共1000台。异地多活方案可以这样做:
1)将商品的库存按照比例分配,例如:北京600台,上海400台
2)系统有一个用户路由层,北方用户路由到北京中心,南方用户路由到上海中心
3)正常情况,各自读取本地库存秒杀即可
4)当其中一个中心无库存时,路由层将用户路由到另外一个中心。例如北京中心没库存了,路由层将北方用户也路由到上海中心
5)如果上海中心无法访问,此时路由层将南方用户也路由到北京中心,但是由于上海的库存数据不明,此时南方用户和北方用户其实都是在抢北京中心的库存。
这个方案本质上还是没有解决库存异地多活的问题,但是可以让单个商品某种程度上支持异地多活秒杀,上面这个例子就是iphone7本来是1000台秒杀,上海中心挂掉的情况下,就变成了600台iphone7秒杀了,不过至少在用户看来,还是在秒杀。

评论
0

龙吟风 已获得淘公仔 复制链接去分享

我们是做交易网站的,商品的库存这部分感觉做异地多活好像很难做,是否有什么方案来实现此类强一致性业务的异地多活方案?

华仔爱技术 回复

“库存”和“余额”是异地多活设计的两大难点,因为这两个数据需要做到实时强一致性。

不管是支付宝还是银行,对于单个用户的余额的异地多活是实现不了的,也就是说单个用户的余额是没法做异地多活的,这就是支付宝敌不过蓝翔挖掘机的原因。
可以通过将用户分布在多地,实现系统层面用户异地多活,即:某个数据中心有故障只影响部分用户,其它数据中心的用户是可以继续使用业务的。

库存类似,如果某个商品的库存不限制购买数量,那就没有办法做异地多活;
如果某个商品限制只能购买一定数量,则可以通过取巧的方式来实现,即:将库存分布到异地多活的多个中心去,每个数据中心先读取本地的库存,不够的话再从其它数据中心分一些过来。
例如:iphone7限制每人一台,现在有1000台,广州仓库分500,北京仓库分300,上海仓库分200,如果上海的卖完了,就看广州和北京是否还有库存。如果你经常在京东买东西就会发现,京东有一个从其它地方调货的功能,只是物流配送时间长一些而已。

评论
0

ciar 复制链接去分享

支付宝有没有异地多活?杭州地区的光纤一挖断,整个周边地区都无法使用了。这种情况也不是第一次了。

华仔爱技术 回复

我不是支付宝的,从几次故障的影响来看,可以推测这个结论:
针对单用户,支付宝无法做到异地多活,因为余额是强一致性的数据,且涉及到钱;
针对所有用户来说,支付宝应该有很多数据中心,单个数据中心故障只会影响一部分用户,不会导致所有用户都无法使用支付宝。

乡下仔86 回复

这种情况对于某个SET做同城多园区的方式,然后在同城多园区之间保证数据一致性,是不是可以避免呢?

华仔爱技术 回复

可以避免部分情况,例如挖掘机只是挖断了某个园区相关的网线;但一般情况下,挖掘机挖断的都是骨干网,这种情况下同城多园区一样受到影响

评论
1

大利猫 复制链接去分享

据说某大公司数据都备份到卫星上去了^_^

聚小编 回复

这么牛~

idealities 回复

以后就是多行星多活了,然而延迟太高。

natwareadm 回复

行星也没用。参考三体。

评论
1

idealities 复制链接去分享

难点在于我们的业务还没有达到这个需求。

楚松666 回复

别闹~O(∩_∩)O哈!

idealities 回复

你会打鼓啊,来当鼓手吗

华仔爱技术 回复

那就不要跟风,异地多活成本还是挺高的,不管是设计、实现、部署、维护,都是挺花钱或者时间或者人力的 :)

评论
1

gamesdoa 复制链接去分享

如果要做异地多活,我个人认为应该首先实现应用的本地闭环,在此基础上做远程数据备份,针对强一致性的需求,需要远程备份之后才算事务成功,这样才能实现强一致性需求下的异地多活。当然在非强一致性的情况下可以本地处理之后,由另外线程跑备份数据。针对差异时间内另外机房读取数据可以使用二次请求处理。

华仔爱技术 回复

“需要远程备份之后才算事务成功”,这个设计会有严重的问题:
1)性能问题:为了保证一致性,本地的写入性能在网络或者远端有故障的情况下会很低
2)可靠性问题:远端故障的时候,本地也无法完成事务,这个和单点故障没有区别

评论
1

1322176414175511 复制链接去分享

异地多活方案面临一个无法彻底解决的矛盾:业务上要求数据的快速同步,物理上正好做不到数据快速同步,因此所有数据都实时同步,实际上是一个无法达到的目标。

华仔爱技术 回复

你是看了我的文章么 :)

评论
1

evanchn 复制链接去分享

异地多活,最大的难点在于数据层

华仔爱技术 回复

是的,运算可以重做,只要数据和算法一致,无论运算多少次结果都一样,但数据没法重做,只能通过复制的方式来应对故障失效的风险,但复制又受制于远距离的网络传输速度,不可能做到实时。

评论
1

f50528603 复制链接去分享

多种网络通信,如传统蜘蛛网络,加上还在实验的卫星 量子通信
多地异地同步多种方式结合
前几天才出现的,集装箱核电站的应用

华仔爱技术 回复

未来还比较遥远 :)

f50528603 回复

几个月前的,居然有人回答了~呵呵~

评论
1

liwit 复制链接去分享

网络断了怎么保证数据一致性?业务怎么无缝的在多个地点切换?以及切换的实效

华仔爱技术 回复

网络断了要保证数据一致性,只能不允许新写入任何数据,这样所有业务中心的写入功能都失效了。
业务无缝切换没有统一的方案,需要结合业务来做,而且有的强一致性业务无法做到无缝切换,例如支付宝。

评论
1

fytx 复制链接去分享

异地降低成本提高复用率的未来在哪里?

华仔爱技术 回复

异地多活本质上不是为了降低成本,而是提升可靠性,所以考虑降低成本的异地多活是走错了方向。

评论
1

1903251745277812 复制链接去分享

我做淘宝客,添加库存时多活有延迟

华仔爱技术 回复

库存延迟是无法避免的

评论
1

spdia 复制链接去分享

还是应该在cap中的c上做文章,采用最终一致性方案来解决问题。可以采取不同地区分中心的方式,在中心间网络出现故障时,每个分中心能够独立运行,网络恢复时相互同步数据。在数据设计层面,对于唯一id的生成,需要支持分布式方案,避免脑裂。在应用层面,服务应该可以有限降级,不同重要程度服务分别对待,有些服务可以在应急时失效。

华仔爱技术 回复

异地多活不但要解决分中心之间的网络故障和数据同步问题,还需要考虑某个分中心接管另外一个分中心的业务。
只考虑数据同步,是备份中心,不是多活中心。

评论
5