从0开始学架构
李运华
资深技术专家
立即订阅
38717 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

29 | 异地多活设计4大技巧

李运华 2018-07-03
专栏上一期我介绍了三种不同类型的异地多活架构,复习一下每个架构的关键点:
同城异区
关键在于搭建高速网络将两个机房连接起来,达到近似一个本地机房的效果。架构设计上可以将两个机房当作本地机房来设计,无须额外考虑。
跨城异地
关键在于数据不一致的情况下,业务不受影响或者影响很小,这从逻辑的角度上来说其实是矛盾的,架构设计的主要目的就是为了解决这个矛盾。
跨国异地
主要是面向不同地区用户提供业
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(25)

  • 空档滑行
    oceanbase的强一致分布式数据库可以使业务不需要考虑持久层的跨地域数据同步问题。
    但应该付出的代价是单个请求的rt会变大,可用性也有降低,所以对rt要求非常高的业务可能不会选择,其实还是对业务有影响的。
    如果代价可以承受,业务端还要解决缓存的一致性问题,流量切到其它可用区的压力是不是承受的住。可能还是需要部分业务降级。
    所以分布式数据库不能完全做到业务无感知的异地多活

    作者回复: 分析正确,异地多活并不是单单持久层考虑就够了

    2018-07-03
    21
  • 炫紫
    强烈建议老师能够多给一些准备文章所查找的资料链接,毕竟文章属于高度总结概括的,老师只是领进门,吸收知识还是靠自己去看,去领悟

    作者回复: 如果是异地多活,理论只有CAP,网上有很多实践案例,但都没有提炼通用方法论,专栏的异地多活内容基本都是我自己悟出来的😊

    如果是其它章节,文章内容已经包含关键部分,细节你可以拿其中的关键字去搜索

    2018-07-03
    6
  • yungoo
    oceanbase采用了两阶段提交来实现跨区多机分布式事务。当协调器出现故障时,其通过查询所有参与者的状态来恢复分布式事务。当某个分区故障或网络中断时,事务会长时间挂起,直到故障修复,这段时间内部分其实是不可用的。虽然其声称强一致性和高可用,当发生故障和网络中断,依然会导致服务不可用。
    2018-07-03
    5
  • Geek_fb3db2
    假如有多个应用 而不是ab2个 那么当前处理不了请求对端 那么是要请求哪端呢
    session也是同样例子。因为不知道session是哪个应用生成的 是不是session上要带ip信息 做反向连接用

    作者回复: 是的,session设计要考虑识别来源

    2018-12-26
    3
  • 冈鑫
    有几个疑问,请问A和B两个城市机房,
    1.假如在A改了密码,在B是不是有可以通过旧密码登陆的可能呢?
    2.以此类推,假如是存款金额,怎么判断B的数据是最新的呢?
    3.银行转账通过申请的方式,需要所有城市节点反馈,才确定扣款吗?
    4.银行转账通过申请的方式,如果其中一个城市宕机了,是不是所有城市都无法扣款呢

    作者回复: 1. 有,我自己都遇到过QQ密码和淘宝密码不同步的问题,当然是十几年都各自只有一次
    2. 没法判断,余额只能做只读备份,不能双活,除非底层存储是基于paxos做的分布式一致性,但理论上paxos的分布式系统也会整体挂掉,因为目前的技术,节点间连接的问题是解决不了的,除非量子通信😄
    3. 不会,两个账户所在的节点正常就可以了
    4. 不会,只是这个城市的用户没法扣款,其它城市的用户不受影响

    2018-08-08
    3
  • o
    qq的账户登陆这一块应该就是做了多机房回源读取。因为他们的业务就是密码错误,会让用户输入验证,我估计应该至少有这两个功能:1、人机校验;2、留充足时间给多地机房数据确认;

    作者回复: 这个我还真不知道,不过你这样分析也有一定道理

    2018-07-12
    3
  • Tokumi
    你好,华哥。请问能否在后续也指导下日志系统的知识,微服务框架下的日志选型?谢谢了。

    作者回复: 我的专栏目的在于教会读者架构分析和设计方法论,而不是具体某个系统如何实现,你可以参考架构设计选择,架构设计流程等知识自己实践一下

    2018-07-04
    2
  • 小土
    在注册里,如果A中心宕机,消息队列因为处理时延未到B中心,二次读取因为A中心未恢复也失败,这种情况有什么好的处理建议?

    作者回复: 没法处理😄只能让部分用户受损

    2018-07-03
    2
  • 王维
    想请教一下华仔,在真正的应用场景中,使用消息队列异步推送的可靠性高不高?NServiceBus消息队列在真正项目中的运用还可以吗?
    2018-07-03
    2
  • 紫clz
    使用了这么多同步方式看上去是依不同情况做的不同处理,但是在一个服务里用这么多不同的方案会加大后续的维护成本吧,人员理解都要花一些时间,出问题了排查方式还不一样

    作者回复: 首先要解决业务问题

    2019-02-13
    1
  • 武文文武
    您好,问一下文中说不能以后一个手机号注册为准,这个原因是什么呢?注册是可以有时间记录,在做高可用切换时以最后一次注册时间为准不是蛮好的解决方案吗?还请赐教

    作者回复: 因为用户注册后可能执行很多操作

    2018-12-01
    1
  • yungoo
    oceanbase采用了两阶段提交来实现跨区多机分布式事务。当协调器出现故障时,其通过查询所有参与者的状态来恢复分布式事务。当某个分区故障或网络中断时,事务会长时间挂起,直到故障修复,这段时间内部分其实是不可用的。虽然其声称强一致性和高可用,当发生故障和网络中断,依然会导致服务不可用。
    2018-07-03
    1
  • Geek_88604f
    首先为应对自然灾害保重证高可用,oceanbase集群必须跨城分区,那么如下两个问题就不可避免:一是跨城分区带来的时延问题会导致集群对某次写入达成一致的时间变长出现数据不一致;二是成本问题,为保证跨城分区之间网络的可靠性可能要考虑公网和内网共存,部署成本上升。
            再说当发生故障时如果恰好是[n/2+1]个节点所在的分区发生故障,那么整个集群将由于无法达成多数派而停服。
            最后一点,paxos协议的使用场景通常是读多写少,写操作会存在瓶颈,集群的规模不会很大。

    作者回复: 赞同

    2019-09-18
  • godtrue
    课后思考及问题
    1:听完的第一感觉是系统理论上100%高可用是不可能的,不管是双机架构还是高可用集群架构甚至是最牛逼的异地多活架构都无法保证100%高可用,因为进程间通信协作是需要网络通信的,而网络通信的环境是复杂多变的不能100%安全可靠,另外,数据延迟是无法避免的,那数据实时一致性是无法做到的。世间没有完美之事,当然,这并不表示这样的人生不值得过活,这恰恰是我们奋斗的目标和动力。我们接受不能100%高可用,但是我们要保证核心业务高可用,并且大部分业务高可用,其实实际情况也是如此的,系统不可用的是小概率事件。
    抓住主要矛盾的主要方面,基本就能做的立于不败之地。

    2:如果底层存储采用 OceanBase 这种分布式强一致性的数据存储系统,是否就可以做到和业务无关的异地多活?
    OceanBase没用过,不过根据软件编程没有银弹以及天下没有免费的午餐来推断,应该做不到和业务无关的异地多活。异地多活有一定的业务适用范围,也不仅仅只是解决分布式数据存储的问题。
    如果是金融业务,要求低延时,还包括一些计算业务,也许就不太适合啦!情愿牺牲一下系统的可用性牺牲一下用户的使用体验,也要保证业务的逻辑一致性。
    2019-08-31
  • (╯‵□′)╯︵┻━┻
    有个想法:对应异地多活不可能100%实现的是,人的感官也不是完全连续的,这首先帮我们排除了毫秒级异地多活的需求。
    其次,秒级的连续性可以用交互界面搭建,如课程所讲。
    如果场景允许,更长时间的连续性可以显示声明事务阶段,例如文中的的转账申请。这利用到了设计理念中的示能概念,就是利用人对申请是个流程的自发认识。

    总之,我的看法是架构不应该向功能回归,而是要向业务目的回归。

    作者回复: 前面说的挺好,最后一句没看懂呢

    2019-08-10
  • Longerian
    通过消息队列同步数据,与数据库同步数据,两者逻辑上如何配合?
    是前者作为后者的补充协调方案,还是在发现数据库同步有问题的时候,主动走消息队列通道?
    还有消息队列同步理论上是不是也会碰到网络抖动、延迟等等问题

    作者回复: 你分析的都对,具体实践要结合业务进行取舍

    2019-05-13
  • 森林
    这里的归纳完善后逻辑应该是:根据经济能力、所需时间及业务要求有先后地选择异地多活的业务及业务多活的形式。

    作者回复: 赞👍

    2018-09-18
  • 无聊夫斯基
    为啥会出现用户在A中心登录,又在B中心登录的情况?不是会选择最近的中心吗,只有A中心故障才会去选择B中心登录?

    作者回复: 你坐高铁,或者处在两省交界,或者一会用无线,一会用4G,甚至路由出bug……很多情况的😀

    2018-09-06
  • 孙振超
    虽然经历过将系统从同城双机房部署升级为三城五机房部署的整个改造过程,事后总结也只是知道需要怎么做,但为什么这么做就不清楚了。个人认为这篇文章最难能可贵之处是在不长的篇幅里讲清楚了可以落地的行动指南,按照这个指南必然不会出现大的疏漏。

    至于ob,了解不多,也未真实使用过,但“没有银弹”这句话是一直有效的,从使用过ob的同学了解到还是有些坑。当然从理论上说,ob作为分布式强一致性数据库,是能够简化异地多活设计的(成本也是比较高的,高可用通常需要5副本),其事务隔离级别通常是读未提交级别,为保证性能会采取异步回滚,而异步回滚失败会导致数据再次写入失败。

    作者回复: ob也在进化和完善

    2018-08-27
  • 文竹
    强一致性并不是实时一致性,有些业务能承受强一致性带来的延迟,有些则不能。更何况Oceanbase只是用于存储层,考虑异地多活也要考虑计算层,缓存层。
    2018-08-24
收起评论
25
返回
顶部