29 | 异地多活设计4大技巧
该思维导图由 AI 生成，仅供参考
技巧 1：保证核心业务的异地多活
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
异地多活设计是保证业务高可用的重要手段之一。本文介绍了跨城异地多活架构设计的四大技巧。首先，强调了保证核心业务的异地多活的重要性，指出优先实现核心业务的异地多活架构是关键。其次，强调了保证核心数据最终一致性的重要性，提出了减少数据同步、保证最终一致性等技巧。文章通过具体案例分析，深入浅出地介绍了异地多活设计的复杂性和解决方案，为读者提供了宝贵的技术指导。 在异地多活架构设计中，采用多种手段同步数据是关键。存储系统本身的同步功能虽然强大，但在某些极端情况下可能无法满足业务需求。因此，文章提出了采用多种手段配合存储系统的同步来使用，甚至可以不采用存储系统的同步方案，改用自己的同步方案。同时，文章强调了只保证绝大部分用户的异地多活，指出异地多活无法保证100%的业务可用性，需要忍受一小部分用户或业务上的损失。最后，文章总结了核心思想，即采用多种手段，保证绝大部分用户的核心业务异地多活。 总的来说，本文通过具体案例和技术理论，深入浅出地介绍了异地多活设计的技巧和核心思想，为读者提供了宝贵的实践经验和思考。读者可以从中了解到异地多活设计的复杂性和解决方案，以及在实际应用中需要注意的关键点。
《从 0 开始学架构》，新⼈⾸单¥68
全部留言(46)
- 最新
- 精选
空档滑行oceanbase的强一致分布式数据库可以使业务不需要考虑持久层的跨地域数据同步问题。 但应该付出的代价是单个请求的rt会变大，可用性也有降低，所以对rt要求非常高的业务可能不会选择，其实还是对业务有影响的。 如果代价可以承受，业务端还要解决缓存的一致性问题，流量切到其它可用区的压力是不是承受的住。可能还是需要部分业务降级。 所以分布式数据库不能完全做到业务无感知的异地多活作者回复: 分析正确，异地多活并不是单单持久层考虑就够了
2018-07-0388
炫紫强烈建议老师能够多给一些准备文章所查找的资料链接，毕竟文章属于高度总结概括的，老师只是领进门，吸收知识还是靠自己去看，去领悟作者回复: 如果是异地多活，理论只有CAP，网上有很多实践案例，但都没有提炼通用方法论，专栏的异地多活内容基本都是我自己悟出来的😊 如果是其它章节，文章内容已经包含关键部分，细节你可以拿其中的关键字去搜索
2018-07-0323
冈鑫有几个疑问，请问A和B两个城市机房， 1.假如在A改了密码，在B是不是有可以通过旧密码登陆的可能呢？ 2.以此类推，假如是存款金额，怎么判断B的数据是最新的呢？ 3.银行转账通过申请的方式，需要所有城市节点反馈，才确定扣款吗？ 4.银行转账通过申请的方式，如果其中一个城市宕机了，是不是所有城市都无法扣款呢作者回复: 1. 有，我自己都遇到过QQ密码和淘宝密码不同步的问题，当然是十几年都各自只有一次 2. 没法判断，余额只能做只读备份，不能双活，除非底层存储是基于paxos做的分布式一致性，但理论上paxos的分布式系统也会整体挂掉，因为目前的技术，节点间连接的问题是解决不了的，除非量子通信😄 3. 不会，两个账户所在的节点正常就可以了 4. 不会，只是这个城市的用户没法扣款，其它城市的用户不受影响
2018-08-08417- Geek_92f9aa文章不仅讲方法还有举例子，而且阐明了各种异常情况的多种不同解决方案极其利弊。这不仅要求作者本身要有丰富的实战经验和不断思考总结，还需拥有极好的语言表达和崇高的分享精神(在架构设计方面，我在公司很少人能说清楚，经常遮遮掩掩，可能是不懂，更可能是不好分享，毕竟这个知道的人越少自己就越有优势我觉得)。 感谢华神的倾囊相授，对我来说，天才已经不适合您了。您应该是神，是上帝！ 现在我也在写博客，我要把那些网上搜不到的自己又非常精通的通通分享出来，我要让那些人知道，你知道的不愿分享的知识，在我这里从来就不是个别人专有的秘密。
作者回复: 哈哈，过奖了，架构确实没有太好的资料来讲解，这也是我写专栏的初衷，我希望其他人不用再像我一样投入那么多时间和精力来摸索！养成写博客的习惯挺好，对自己的能力提升很有帮助������
2020-10-3110 - Geek_88604f首先为应对自然灾害保重证高可用，oceanbase集群必须跨城分区，那么如下两个问题就不可避免:一是跨城分区带来的时延问题会导致集群对某次写入达成一致的时间变长出现数据不一致;二是成本问题，为保证跨城分区之间网络的可靠性可能要考虑公网和内网共存，部署成本上升。 再说当发生故障时如果恰好是[n/2+1]个节点所在的分区发生故障，那么整个集群将由于无法达成多数派而停服。 最后一点，paxos协议的使用场景通常是读多写少，写操作会存在瓶颈，集群的规模不会很大。
作者回复: 赞同
2019-09-1810 - 小神david尽管对OceanBase不熟悉，但是根据业余场景的不同和CAP理论，分布式的强一致存储可能会影响可用性以及用户体验，此外任何系统都会有自身的优劣势，还是要看是否可以满足业务需求。另外，维护一套分布式的强一致存储的成本也相对较高。
作者回复: OceanBase的架构是“同城双机房 + 异地单机房”共3个机房5个节点这种架构，异地机房其实不能用来做完整的业务访问，因此OceanBase其实做不了异地多活的底层存储，而是同城双活。 以上信息是我在19年左右了解到的，最新的是不是这样还需要确认。
2020-12-2824 
Geek_fb3db2假如有多个应用 而不是ab2个 那么当前处理不了请求对端 那么是要请求哪端呢 session也是同样例子。因为不知道session是哪个应用生成的 是不是session上要带ip信息 做反向连接用作者回复: 是的，session设计要考虑识别来源
2018-12-264
oqq的账户登陆这一块应该就是做了多机房回源读取。因为他们的业务就是密码错误，会让用户输入验证，我估计应该至少有这两个功能：1、人机校验；2、留充足时间给多地机房数据确认；作者回复: 这个我还真不知道，不过你这样分析也有一定道理
2018-07-124
fomy强一致性的场景必然带来高延迟问题，甚至还会有死锁情况，对于比如余额这种强一致数据还是需要的。 对于注册可能重复的问题，可以通过手机号做hash只能让它在一个节点注册。 当然异地多活不只是数据库的高可用，还可能是缓存数据的高可用。作者回复: 缓存一般不做异地多活高可用，缓存设计本来就是可以丢的，即使缓存做异地多活也很简单，用canal之类的异步复制工具即可，因为缓存对一致性要求不高。
2021-09-2422
微群您好，有两个问题咨询一下 1 当前银行实时转账如此之快，体验还不错，就是因为采用了本地机房处理的方案是吗？ 2 支付宝转账到银行卡的这种方式也很快，意味着支付宝的实时转账的功能也是采用本地机房处理是吧？因为金融的强一致性要求，未采用异地多活方案是吧？作者回复: 你作为终端用户感受到的“快”和系统处理上的“快”，两者不是一个概念。 你觉得快，可能是1分钟以内，这个量级的时间，本地机房和异地机房都可以做到。 支付宝转银行卡，那就至少是1~5分钟级别的，无论本地本地机房和异地机房都没问题。
2021-03-182
