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

  • 时间:
  • 浏览:2

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

多种网络通信,如传统蜘蛛网络,打上去还在实验的卫星 量子通信

多地异地同步多种依据结合

前几天才出現的,集装箱核电站的应用

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

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

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

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

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

机会要做异地多活,我当事人认为应该首先实现应用的本地闭环,在此基础上做远程数据备份,针对强一致性的需求,都要远程备份已经 才算事务成功,原先不用 实现强一致性需求下的异地多活。当然在非强一致性的情况下都不用 本所处里已经 ,由另外线程池池跑备份数据。针对差异时间内另外机房读取数据都不用 使用二次请求处里。

1322176414175511 复制链接去分享

1903251745277812 复制链接去分享

我的理解,余额等强一致性的场景,异地多活不现实,支付宝和银行都应该是另两个核心主库吧,主已经 在数据库上做文章。

库存等展示型场景的异地多活,主要靠缓存和同步机制,也没必要做400%一致,机会再用因此 云服务,比如大内网,再比如微软的SQL Azure等,又比如CDN的使用等等,这已经 多做因此 Web节点就都不用

确实云服务真的挺好,处里了全都有收集上的的技术投入产出数率单位低下那些的问题报告

evanchn 复制链接去分享

我的理解,余额等强一致性的场景,异地多活不现实,支付宝和银行都应该是另两个核心主库吧,主已经 在数据库上做文章。

库存等展示型场景的异地多活,主要靠缓存和同步机制,也没必要做400%一致,机会再用因此 云服务,比如大内网,再比如微软的SQL Azure等,又比如CDN的使用等等,这已经 多做因此 Web节点就都不用

确实云服务真的挺好,处里了全都有收集上的的技术投入产出数率单位低下那些的问题报告

异地多活确实听起来很美好,但在设计上却有全都有的挑战,全都有人都不 确实“异地多活”的方案设计没人 ,业务、网络、数据、事务等各种那些的问题报告 混杂在一同,全都有那些的问题报告 看似是无法处里的。比如说:“网络断了怎么能保证数据一致性”、“怎么能保证异地事务一致性”、“业务怎么能无缝的在多个地点切换”。。。。。。等等。

idealities 复制链接去分享

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

淘公仔 x 4

gamesdoa 复制链接去分享

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

fytx 复制链接去分享

spdia 复制链接去分享

我们都是做证券交易的,我们都的方案是先异地部署多个交易中心,有每该人独立的数据库,已经 将用户划分到不同的交易中心,并将用户请求路由到对应的交易中心,原先就实现了交易中心异地多活。交易中心两种支持异地异步数据复制。

原先在某地区机房瘫痪时,受影响的交易中心不到未来得及复制的数据要素会有影响(丢失),剩下交由业务层去判断和处里故障。

你这种依据不到够删改处里好故障,不到尽量减少故障影响到的用户,主已经 机会是交易系统,我们都都要兼顾性能,我们都也头疼没人另两个比较完美的方案。

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

对于因此 秒杀商品,所处对库存做多机房分布的情况,也已经 会按照商品id分布在不同机房进行秒杀。在所处某另两个机房不可用时,这时不可用机房的数据机会还没删改同步到因此 机房,这时怎么能都不用 让因此 机房来安全接替(不用出現数据冲突)垮掉机房的业务呢?

大利猫 复制链接去分享

难点在于我们都的业务还没人 达到你这种需求。

易宝支付 复制链接去分享

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

我做淘宝客,打上去库存时多活有延迟

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

f4005284003 复制链接去分享

秒杀商品所处对库存做多机房分布的情况,也已经 会按照商品id分布在不同机房进行秒杀。在所处某另两个机房不可用时,这时不可用机房的数据机会还没删改同步到因此 机房,这时怎么能都不用 让因此 机房来安全接替(不用出現数据冲突)垮掉机房的业务呢?

ciar 复制链接去分享

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

你的业务是是否是都不 类式的异地多活的需求和困惑?怎么能不能不用 设计优秀的异地多活方案?有那些技巧 ?来吧,咱们一同聊聊 :)

我们都是做交易网站的,商品的库存这要素感觉做异地多活好像没人 做,是是是否是那些方案来实现此类强一致性业务的异地多活方案?

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

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

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

聆听专属T恤衫 x 3

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

虾米VIP季卡 x 1

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

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

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

liwit 复制链接去分享