2018-06-30备份系统平常没有流量，如果直接上线可能触发平常测试不到的故障。
再实时的系统也会有数据延时，如果涉及到金融这种系统，仍然是不敢直接切换的。
系统运行过程中会有很多中间数据，缓存数据等。系统不经过预热直接把流量倒过来，大流量会直接把系统拖垮作者回复: 分析全面，赞👍
67
2018-06-30文章提到异地多活的代价时，说到复杂的架构，但通篇没有一个架构图，从文字看，也没完全理解架构的细节，例如异地之间如何同步，一地出现问题，如何切换，例如北京的业务系统出问题了，怎么用广州的业务系统来抗过去。作者回复: 后面还有两篇
11
2018-06-30现在流行云服务，对于企业做异地多活、灾备会不会很省事？作者回复: 不会，云服务一样宕机
9
2018-10-06李老师，像文中提到的不同的异地多活架构产生的不同成本，没有直观印象，您能否系统性的给个具体的分析～作者回复: 支付宝为了底层支持异地多活，自己写了Oceanbase，Oceanbase写了7～8年了还没有完全代替MySQL😄
4
2018-07-02支付宝多活也不是正在意义上的多活吧。我记得之前支付宝故障影响部分用户，感觉更多像是分区提供服务 4
2018-06-30这得看这1分钟对业务的影响，如果影响不大就没必要做，如果影响较大，还是得做异地多活作者回复: 就算是现在异地多活的系统，也做不到实时异地多活的，分钟级的影响都是存在的
4
2018-07-02请教个问题：文章说支付宝类的金融服务一般采用的是同城异区架构.那假如真的发生了类似奥尔良水灾问题，支付宝如何保证业务正常？要解决这问题的话是多地部署（多地间服务状态不同步），存储高可用？作者回复: 支付宝也没法100%保障，不然蓝翔挖掘机就不会导致支付宝故障了
3
2019-09-17首先第一点业务会中断一分钟，这对于微信或支付宝这样的系统来说是不可接受的，特别是像春节这样的关键时刻，万万不可掉链子。
第二点数据不一致，如果在主分区故障前还没有将数据同步到备分区，那么在主分区恢复前数据一直不一致。对于像新闻或微博之类的应用还好说，对于电商或微信等系统就不可接受。
第三点备用分区的可用性，发生故障往往是在业务高峰期，这个时候备份区能否抗住是值得怀疑的。一个从来没有锻炼过的人，突然让他跑马拉松估计扛不住。
最后一点缓存，如果系统中存在缓存，缓存的数据在备分区是没有的，缓存需要预热，一下子切到备出现缓存击穿导致存储扛不住作者回复: 分析到位
2
2018-08-27假设我们做了前面提到的高可用存储架构中的数据分区备份，又通过自动化运维能够保证 1 分钟就能将全部系统正常启动，那是否意味着没有必要做异地多活了？
数据分区备份意味着分区中的数据和当前提供服务的机房数据可能存在这延迟，同时备份系统启动后能否按照期望的sla提供服务是无法保证的。
但不同类型的系统对于数据和可用性的要求也是不同的，对于新闻、网络小说、论坛、政府学校等以阅读资讯为主的系统来说如果可以做到分钟级正常重启，是没有必要做异地多活的；对于电商、银行和钱相关的系统还是需要做异地多活的。展开作者回复: 分析正确
2- 2018-07-01还是要考虑异地多活的。数据备份和存储高可用没法应对大规模停电 地震这种极端灾难。
作者回复: 异地多活也是需要数据备份和存储高可用的
2 
2018-06-30这期讲的有点浅，希望能更深入的谈谈异地多活怎么实现，有没有什么模式。作者回复: 后面还有两章
2- 2018-06-30有个问题，不太清楚。异地多活，即使同城异区，他们都有对用户不同的访问ip吗，当一地出现问题的时候，用户自己尝试访问另一地?如果是自动切换，是什么机制，dns全部解析到另一地的ip?
作者回复: 每个机房都对外提供服务，都有不同出口ip，由DNS等负载均衡设备切换(适应web)，或者端自己切换(适应app)
2 
2019-05-31目的不同吧，即使做了前面提到的高可用存储架构中的数据分区备份，又通过自动化运维能够保证 1 分钟就能将全部系统正常启动，那还是不能解决不可抗力(自然灾害等)带来的不可用，因此，对于需要做异地多活的业务还是有必要做异地多活的。作者回复: 赞同
1
2018-10-22最近看CIPS（人民币跨境支付系统）的相关信息，官网中有这么一条新闻：
“本次CIPS主备中心切换用时67秒，较上一次切换运行用时缩短了19秒，进一步提高了切换效率及系统连续运行能力。此次切换运行充分验证了CIPS二期全面投产后备份中心系统配置的正确性和可用性。后续，CIPS运营机构将进一步提高业务连续性保障能力，完善系统服务功能，提升用户使用体验。”
结合老师讲的最近几章，推断CIPS是主备系统架构，不是异地多活，使用的是数据分区备份，并且官网之前也提到主系统在上海，备份系统在无锡。
但是我感觉有两个奇怪的地方：一个是：主备在上海和无锡，这两个地方觉得不远也不近，看了下地图约150公里吧，感觉既不是“同城异区”，也算不上“跨城异地”。另一个他作为金融系统使用主备架构，而没有使用异地多活架构，是不是有点业余？展开作者回复: 1. 距离这么近确实有问题，例如台风或者地震，很可能两个机房都受影响
2. 金融系统大部分使用主备架构，不算业余但也算不上先进，金融系统对数据一致性要求很高，异地多活很多业务做不了 1
2018-10-17余额数据同城异区对比跨城异地在数据一致性上同样存在时间差，只是时间窗口更小而己，如果两地都支持写的话，存在被双花攻击的可能，风险还是很大，有什么方法避免吗作者回复: 没有，余额和库存一般不做双写，目前Oceanbase通过paxos算法支持多机房写入，但实际性能我不太了解
1
2018-08-29多活不是同时运行的吗作者回复: 多活是主要同时运行并且对外提供服务
1
2018-08-26老师，我对文章中提到的支付宝不采用跨城异地，而采用同城异区的多活存在疑问，从逻辑上来讲同城异区即便网络延迟很小，但总归是有延迟的，也会从某种程度上影响一致性，架构也必须引入方案解决一致性问题，两者不存在一致性上的复杂度差异，而同城和异地的差异是不是应该是在用户体验上来区别？比如，同样是转账业务，一个转账请求需要在多个活动机房都同步后才向用户返回成功，这样的话，同城的优势就在于响应时间很快，而异地可能就会很慢。作者回复: 同城异区也是有延迟的，但是延迟小，故障切换时快，但总是有可能有用户数据不一致，这种数量小就可以容忍，人工修复和事后补偿的代价都可以接受，不存在所有用户都没任何问题的方案。
转账请求一般不做同步，做好备份就可以了，因为对实时性要求不高 1
2018-07-23以前微博做过异地机房 但是因为种种原因 还是回到了同城多机房的架构作者回复: 微博很多业务应该可以做异地多活呀
1
2018-07-11文章中支付宝转账的例子不对。支付宝通过分布式事务保证转账交易的原子性。oceanbase保证异地多个节点中大部分节点写成功。未写成功的节点异步恢复。未恢复前不可发生新的交易。作者回复: 文中的例子是多地都可以同时写，oceanbase底层基于paxos算法，从业务的角度看起来是多地都可以写，但本质上是通过一致性算法避免同时写，paxos同时写会出现冲突，冲突就要重新发起写操作
1
2018-07-02能不能给一个系分的案例呢，全面一点的作者回复: 案例很多，后面两章会讲具体怎么做
1