从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

30 | 异地多活设计4步走

用户补偿
日志记录
同步和访问结合
多通道同步
重复生成
消息队列同步
存储系统同步
可恢复性
可丢失性
实时性
唯一性
数据量
产生大量收入的业务
核心业务
访问量大的业务
以用户管理系统的登录业务为例
异常处理措施
以用户管理系统的登录业务为例
同步方案
以用户管理系统的登录业务为例
数据特征分析维度
以用户管理系统的登录业务为例
分级标准
第4步:异常处理
第3步:数据同步
第2步:数据分类
第1步:业务分级
异地多活设计的4个步骤

该思维导图由 AI 生成,仅供参考

上一期,基于异地多活架构设计复杂度最高的“跨城异地”,我结合自己的经验总结了异地多活设计的 4 个技巧及其核心思想,我认为掌握这些技巧是进入具体设计步骤的前提。
今天,在掌握这 4 大技巧的基础上,我来讲讲跨城异地多活架构设计的 4 个步骤

第 1 步:业务分级

按照一定的标准将业务进行分级,挑选出核心的业务,只为核心业务设计异地多活,降低方案整体复杂度和实现成本。
常见的分级标准有下面几种:
访问量大的业务
以用户管理系统为例,业务包括登录、注册、用户信息管理,其中登录的访问量肯定是最大的。
核心业务
以 QQ 为例,QQ 的主场景是聊天,QQ 空间虽然也是重要业务,但和聊天相比,重要性就会低一些,如果要从聊天和 QQ 空间两个业务里面挑选一个做异地多活,那明显聊天要更重要(当然,此类公司如腾讯,应该是两个都实现了异地多活的)。
产生大量收入的业务
同样以 QQ 为例,聊天可能很难为腾讯带来收益,因为聊天没法插入广告;而 QQ 空间反而可能带来更多收益,因为 QQ 空间可以插入很多广告,因此如果从收入的角度来看,QQ 空间做异地多活的优先级反而高于 QQ 聊天了。
以我们一直在举例的用户管理系统为例,“登录”业务符合“访问量大的业务”和“核心业务”这两条标准,因此我们将登录业务作为核心业务。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

异地多活设计是一项复杂的技术挑战,需要经过精心设计和周密考虑。本文提出了跨城异地多活架构设计的4个关键步骤,为读者提供了实际操作指南。 首先,作者强调了业务分级的重要性,指出应按照访问量、核心业务和收入等标准对业务进行分级,以便降低方案复杂度和成本。其次,文章强调了对核心业务相关数据的分类和分析,包括数据量、唯一性、实时性、可丢失性和可恢复性等特征,以便为后续方案设计提供依据。 接着,文章介绍了不同的数据同步方案,包括存储系统同步、消息队列同步和重复生成等,并针对不同数据特点提出了相应的同步方案设计。最后,文章强调了根据数据特点设计不同的同步方案,以确保异地多活架构的稳定性和可靠性。 在异常处理方面,文章提出了多通道同步、同步和访问结合、日志记录和用户补偿等措施。这些措施旨在应对极端异常情况,最大限度地降低受到影响的范围和程度,并通过人工补偿来弥补用户损失,培养用户的忠诚度。 总的来说,本文通过简洁清晰的步骤和实例,为读者提供了在设计异地多活架构时的关键考虑因素和实际操作指南。这些步骤和措施将有助于读者快速了解异地多活设计的复杂性和关键技术特点,为他们在实际应用中提供指导和参考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(49)

  • 最新
  • 精选
  • xuan
    业务分级我觉得得从如下方面来分析: 1.部门或者公司当期的发力点,如果着重新用户的增长 我觉得顺序应该是ACB,如果着重现有客户满意度,我觉得顺序应该是CBA,如果看重看重收益,那B的优先级最高 2.可通过预期货币价值分析,进行业务分级;大致维度如下:风险发生概率 风险损耗成本 技术改造陈本 技术改造时长(月) 改造后成本节省(月)

    作者回复: 很赞👍

    2018-07-05
    5
    88
  • summer
    业务分级讨论的时候,产品说 A 也很重要,因为影响用户使用;B 也很重要,因为影响公司收入;C 也很重要,因为会导致客户投诉……这种情况下我们该如何处理业务分级? 了解产品挣钱的底层商业逻辑,就可以知道怎么分级了。不是每一单都要赚钱的,在这里亏的,在别处或下次再挣回来。比如微信聊天业务不挣钱,但是影响面大,坏了口碑,大家不来玩了,商家凭什么来投广告。减少影响面,然后跪求被影响用户的原谅

    作者回复: 挺好的思路,根据商业模式的核心来判断

    2018-07-10
    42
  • 孙振超
    涉及到取舍时就需要参考公司的核心目标和愿景了,如果是和核心目标相关的优先级就高,和核心目标无关或关联度不大的优先级就低。 如同最近的滴滴,在以扩规模增利润作为核心目标时必须会优先处理司机端和线路规划相关的业务,而对于增加成本降低利润的用户端和客服系统优先级肯定会比较低;当事故频发引发公司战略转向到安全第一时,原先一直没有得以优化的客服系统、警方查询对接系统优先级将会排到第一位。 在异地多活时排定优先级时也是如此了,牺牲什么保证什么,都是和公司最为关注的内容和目标挂钩的。

    作者回复: 赞同👍

    2018-08-29
    18
  • Geek_92f9aa
    突然想到华神是不是讲少了一点:容灾演练? 像我以前公司每个月要求进行一次容灾演练,演练的方式是运维直接断掉广州或北京的网络,然后看线上服务是否正常运行,出问题的业务责令在在一定时间内改完再重新演练。

    作者回复: 容灾演练算一个SRE的手段,类似于线上测试,可以作为异地多活架构的验证手段

    2020-10-31
    2
    10
  • Enjoystudy
    我们如果通过某种路由策略,比如用户id保证同一个用户的请求都路由到同一个机房就可以解决同步延时的问题

    作者回复: 这个机房挂了怎么办?

    2018-07-12
    6
    7
  • bryan
    如果MQ和数据库同步同时进行,假设是新增数据,MQ先到,数据库后到!那不就主键冲突了!

    作者回复: 备机或者从机的my.cnf 配置 slave_skip_errors=1062,更详细的错误码可以参考:https://dev.mysql.com/doc/mysql-errors/5.7/en/server-error-reference.html

    2021-07-10
    5
  • 成功
    B优先级最高,A第二,C第三。B要考虑跨城多活,A做同城多活,C不同机房就行

    作者回复: 如果是阿里,“用户第一”应该选A,所以不同公司有不同的标准,没有统一答案😄

    2018-07-09
    5
  • 空档滑行
    通常来说toC的应用,影响用户使用的应该是比较靠前的,尤其是产品还处于抢市场的阶段。 to B的应用客户买的是专业性,相对来说用户体验可以往后排,用户能使用和公司收入还是比较重要的。客户相对固定,可以通过客服主动联系客户的方式来做部分挽回

    作者回复: 赞同,根据业务和公司判断

    2018-07-05
    4
  • TH
    之前学到过一个应对这种多因素筛选的方法,不知道对不对:列出所有参与讨论的业务,以及考虑到的影响因素(访问量、影响使用、收益……),每个因素设定一个权值,每个业务针对每个因素进行打分(权值和打分均不允许有重复值),最后计算每个业务的加权和,得出核心业务

    作者回复: 打分最后会变成打架😂参考前面备选方案选择中介绍的内容

    2018-07-05
    4
  • 但莫
    多个场景都重要的情况可以进行层次分析,首先俩俩比较,得到分析矩阵,进行归一化处理,经过计算可以得到每种场景的重要性权重。 当然,俩俩比较的时候判断哪个更重要就看评判人的喜好了,这一步可以通过头脑风暴的到一个平均值。 记得之前的课程中介绍过另一种方法,一时没想起来名字。

    作者回复: 前面在评估备选方案的时候,我给出了"360度评估"和"按优先级选择"的两个技巧

    2018-07-05
    3
收起评论
显示
设置
留言
49
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部