转载自：https://mp.weixin.qq.com/s/_P1-w-eMS0R2YRWCT71gg

  1. 基础架构概述

    • 架构目标与挑战：架构的核心是解决软件系统复杂性，互联网大体量业务面临高可用、高性能、高扩展、低成本、安全性和多功能等挑战。高可用要减少故障影响并快速恢复；高性能需应对海量请求和高并发；高扩展要适应多变的业务；低成本追求投入产出比最大化；安全性保护数据和隐私；多功能要求架构有前瞻性。
    • 基础架构构成：基础架构包括接入层、逻辑层、数据层。接入层负责用户接入，逻辑层处理业务逻辑，数据层存储和管理数据，数据层是异地多活架构设计的关键切入点。

  2. 异地多活解析

    • 容灾需求演变：业务发展使容灾需求从应对单机器故障（如数据备份、主从搭建），到单机房故障（多机房部署），最终到解决城市单点故障（异地多活）。
    • 异地多活的必要性：城市级灾害影响范围大，需将服务部署在千里之外，如不同城市圈的城市组合，以实现异地多活的容灾目标。

  3. 写时延的关键作用

    • 数据层写操作核心地位：逻辑层无状态可无缝切换，数据层的写操作因涉及数据同步、一致性保障，成为基础架构容灾的关键。
    • 跨城写时延影响及应对策略：跨城写时延显著增加，影响业务可用性。若业务能接受，可采用跨城同步复制；否则，可选择缩短距离同步复制（如 100 - 200 公里城市间，时延 5 - 7ms）或异步复制就近分片。异步复制适用于数据一致性要求不高的业务（如微博、视频），而对一致性要求高的业务（如金融、支付）需特殊处理，如圈定影响数据并拒绝相关操作。

  4. 写量大与隔离的分片策略

    • 写量大拆分片：写请求量大时需分片处理，就近分片可减少耗时。对于膨胀型数据（如电商订单数据），可通过分库分表和存档处理，避免硬件资源浪费。
    • 做隔离拆分片：为降低故障影响，数据层及相关依赖需进行隔离，如 “单元化”“SET 化”“条带化” 等方案，这在同城和异地容灾中均常用。

  5. 其他影响因素

    • 读操作影响：读操作影响主要体现在副本管理、缓存机制和连接管理上。写后立即读归入写操作范畴；适当延迟读可通过就近副本满足。业务对读时延要求更严苛，多数读场景可接受适当延迟。
    • 读量大与连接管理：读多写少业务可扩充副本，副本扩展到一定规模时可采用级联同步减少写点负载。同时，为避免数据库连接过多导致性能下降，可添加代理收拢连接。

  6. 数据复制架构

    • 常见架构模式：常见数据复制架构包括三地五中心（1 主 4 从分布在 3 个城市 5 个 IDC 机房，写请求需写入 3 个实例）、三地三中心（可满足容灾但跨城切换复杂，一般较少采用）、同城三中心（用于不能接受跨城时延的场景，可实现有损跨城容灾）、双主互复制（每个实例有完整数据，规避写冲突，跨城容灾时通过时间位点记录处理，但可能产生重复数据和写冲突）。
    • 未同步名单机制：为解决重复数据问题，可采用未同步名单机制。写操作前记录数据属主，同步后清理，写入前检查，存在于名单中则拒绝请求，配合双主互复制可保障数据一致性。

  7. 数据对路由的影响

    • 跨城全局数据路由：数据不分片，写入点唯一，多副本提供就近读取，适合全链路就近路由，也可在接入层路由分流，但意义不大。
    • 就近分片数据路由：为减少写操作跨城时延，需在接入层将请求路由到数据所在城市（机房），读请求可采用相同策略。
    • 跨城分片数据路由：能接受跨城延时，分片主写点分布在不同城市和机房，路由与就近分片类似，但需引入第三城市做数据容灾。

  8. 架构选型模式

    架构选型需综合考虑跨城写时延、写量支撑、隔离要求等因素，同时成本等因素也可能起决定性作用，应根据业务具体情况分析确定。