30 | 异地多活设计4步走
该思维导图由 AI 生成,仅供参考
第 1 步:业务分级
- 深入了解
- 翻译
- 解释
- 总结
异地多活设计是一项复杂的技术挑战,需要经过精心设计和周密考虑。本文提出了跨城异地多活架构设计的4个关键步骤,为读者提供了实际操作指南。 首先,作者强调了业务分级的重要性,指出应按照访问量、核心业务和收入等标准对业务进行分级,以便降低方案复杂度和成本。其次,文章强调了对核心业务相关数据的分类和分析,包括数据量、唯一性、实时性、可丢失性和可恢复性等特征,以便为后续方案设计提供依据。 接着,文章介绍了不同的数据同步方案,包括存储系统同步、消息队列同步和重复生成等,并针对不同数据特点提出了相应的同步方案设计。最后,文章强调了根据数据特点设计不同的同步方案,以确保异地多活架构的稳定性和可靠性。 在异常处理方面,文章提出了多通道同步、同步和访问结合、日志记录和用户补偿等措施。这些措施旨在应对极端异常情况,最大限度地降低受到影响的范围和程度,并通过人工补偿来弥补用户损失,培养用户的忠诚度。 总的来说,本文通过简洁清晰的步骤和实例,为读者提供了在设计异地多活架构时的关键考虑因素和实际操作指南。这些步骤和措施将有助于读者快速了解异地多活设计的复杂性和关键技术特点,为他们在实际应用中提供指导和参考。
《从 0 开始学架构》,新⼈⾸单¥68
全部留言(49)
- 最新
- 精选
- xuan业务分级我觉得得从如下方面来分析: 1.部门或者公司当期的发力点,如果着重新用户的增长 我觉得顺序应该是ACB,如果着重现有客户满意度,我觉得顺序应该是CBA,如果看重看重收益,那B的优先级最高 2.可通过预期货币价值分析,进行业务分级;大致维度如下:风险发生概率 风险损耗成本 技术改造陈本 技术改造时长(月) 改造后成本节省(月)
作者回复: 很赞👍
2018-07-05588 - summer业务分级讨论的时候,产品说 A 也很重要,因为影响用户使用;B 也很重要,因为影响公司收入;C 也很重要,因为会导致客户投诉……这种情况下我们该如何处理业务分级? 了解产品挣钱的底层商业逻辑,就可以知道怎么分级了。不是每一单都要赚钱的,在这里亏的,在别处或下次再挣回来。比如微信聊天业务不挣钱,但是影响面大,坏了口碑,大家不来玩了,商家凭什么来投广告。减少影响面,然后跪求被影响用户的原谅
作者回复: 挺好的思路,根据商业模式的核心来判断
2018-07-1042 - 孙振超涉及到取舍时就需要参考公司的核心目标和愿景了,如果是和核心目标相关的优先级就高,和核心目标无关或关联度不大的优先级就低。 如同最近的滴滴,在以扩规模增利润作为核心目标时必须会优先处理司机端和线路规划相关的业务,而对于增加成本降低利润的用户端和客服系统优先级肯定会比较低;当事故频发引发公司战略转向到安全第一时,原先一直没有得以优化的客服系统、警方查询对接系统优先级将会排到第一位。 在异地多活时排定优先级时也是如此了,牺牲什么保证什么,都是和公司最为关注的内容和目标挂钩的。
作者回复: 赞同👍
2018-08-2918 - Geek_92f9aa突然想到华神是不是讲少了一点:容灾演练? 像我以前公司每个月要求进行一次容灾演练,演练的方式是运维直接断掉广州或北京的网络,然后看线上服务是否正常运行,出问题的业务责令在在一定时间内改完再重新演练。
作者回复: 容灾演练算一个SRE的手段,类似于线上测试,可以作为异地多活架构的验证手段
2020-10-31210 - Enjoystudy我们如果通过某种路由策略,比如用户id保证同一个用户的请求都路由到同一个机房就可以解决同步延时的问题
作者回复: 这个机房挂了怎么办?
2018-07-1267 - 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-105 - 成功B优先级最高,A第二,C第三。B要考虑跨城多活,A做同城多活,C不同机房就行
作者回复: 如果是阿里,“用户第一”应该选A,所以不同公司有不同的标准,没有统一答案😄
2018-07-095 - 空档滑行通常来说toC的应用,影响用户使用的应该是比较靠前的,尤其是产品还处于抢市场的阶段。 to B的应用客户买的是专业性,相对来说用户体验可以往后排,用户能使用和公司收入还是比较重要的。客户相对固定,可以通过客服主动联系客户的方式来做部分挽回
作者回复: 赞同,根据业务和公司判断
2018-07-054 - TH之前学到过一个应对这种多因素筛选的方法,不知道对不对:列出所有参与讨论的业务,以及考虑到的影响因素(访问量、影响使用、收益……),每个因素设定一个权值,每个业务针对每个因素进行打分(权值和打分均不允许有重复值),最后计算每个业务的加权和,得出核心业务
作者回复: 打分最后会变成打架😂参考前面备选方案选择中介绍的内容
2018-07-054 - 但莫多个场景都重要的情况可以进行层次分析,首先俩俩比较,得到分析矩阵,进行归一化处理,经过计算可以得到每种场景的重要性权重。 当然,俩俩比较的时候判断哪个更重要就看评判人的喜好了,这一步可以通过头脑风暴的到一个平均值。 记得之前的课程中介绍过另一种方法,一时没想起来名字。
作者回复: 前面在评估备选方案的时候,我给出了"360度评估"和"按优先级选择"的两个技巧
2018-07-053