金融测试

同城双活（Active-Active in the Same City）是保障系统高可用性和业务连续性的关键架构设计，尤其适用于银行、金融等对业务中断容忍度极低的场景。其核心逻辑如下：

一、基础定义

• 本质：在同一城市相距约30~100公里的两个数据中心（如深圳南山和深圳龙岗），同时在线处理生产流量，任一中心故障时业务自动无缝切换。
• 与"主备"架构的区别：

    A[传统主备] --> B[主中心处理100%流量]
               --> C[备中心闲置或仅同步数据]
  
    D[同城双活] --> E[中心A处理50%流量]
               --> F[中心B处理50%流量]
  

二、银行系统的核心实现原理

1. 流量分发

• 智能DNS+负载均衡：用户请求按策略（如用户ID哈希）分发至双中心。
• 示例：用户A的交易请求路由至中心1，用户B的请求路由至中心2。

2. 数据同步

3. 状态协调

• 全局会话管理：通过Redis跨中心集群共享用户Session，确保登录状态不丢失。
• 分布式事务：采用Seata/TCC模式，保证跨中心转账等操作的数据一致性。

三、金融场景的特殊设计

1. 资金类业务防冲突

• 账户分区：按用户ID范围划分服务域（如尾号0-4在中心1，5-9在中心2）
• 悲观锁升级：大额转账时自动升级为全局锁（ZK/etcd协调）

2. 账务核对兜底

# 日终对账伪代码
def reconcile():
  center1_data = query_db("中心1当日流水")  # 本地优先读取
  center2_data = rpc_call("中心2.get_transactions") 
  if diff_exists(center1_data, center2_data):
     trigger_manual_check()  # 启动人工干预
  else:
     generate_settlement_file()  # 生成清算文件

3. 监管合规要求

• 切换审计：所有机房切换操作留痕并同步至监管平台。
• RTO(恢复时间目标Recovery Time Objective) < 30秒：满足《银行业信息系统灾难恢复规范》5级标准。

📌 核心区别：
2小时RTO：针对全行整体业务恢复（含非核心系统）
30秒RTO：仅针对支付/清算等核心系统的高可用保障

四、测试工程师的关注重点

1. 故障演练测试

2. 数据一致性验证

• 实时比对工具：开发专用工具对比双中心数据库（如比对新开户用户的账户号生成规则）
• 资金核验公式：

  中心1总资产 + 中心2总资产 = 全行总账
  中心1日终流水条数 = 中心2流水条数
  

3. 性能基线监控

• 关键指标：跨中心调用延迟（要求<5ms）、事务冲突率（<0.001%）
• 压测场景：模拟单个中心承载70%流量的突发情况

五、典型面试问题及回答方向

Q：双活架构下如何防止重复支付？
A：

1. 请求幂等：支付接口要求传入全局唯一ID（如：用户ID+时间戳+中心标识）
2. 分布式锁：对账户加锁（中心1用RedLock，跨中心用ZK选主）
3. 异步核对：支付后触发对账Job，补偿不一致订单

Q：遇到跨中心数据冲突怎么解决？
A：

• 优先策略：按时间戳最后写入获胜（需NTP时钟同步）
• 资金敏感操作：触发冲正交易并告警，30秒内冻结账户人工介入
• 设计根源：通过业务分片规避跨中心写同账户

一、CAP理论核心概念

银行系统对数据一致性要求严苛，而双活架构最大的挑战就是跨机房数据同步。银行通常会牺牲部分可用性（如短暂停服）保CP，这和互联网公司的AP优先策略不同。

📌 CAP铁律：分布式系统最多同时满足两项，银行场景优先保障CP，互联网公司倾向AP。

二、银行系统：CP优先的底层逻辑

1. 资金安全是生命线

• 宁可停服，不可错账：当网络分区发生时（如两地数据中心断联），银行选择：

  graph LR
    A[网络分区] --> B{决策}
    B -->|选择C| C[停止部分服务]
    B -->|放弃A| D[返回“系统维护中”提示]
  

• 真实案例：央行支付系统ACS在日切窗口（00：00-01：00）强制停服，确保所有节点账务核对一致

2. 技术实现CP的典型手段

3. 监管合规驱动

• 《商业银行信息系统风险管理指引》要求：

  “资金类业务必须实现实时一致性，允许通过计划内停机达成数据校验”

三、互联网公司：AP优先的本质原因

1. 业务容忍度差异

2. AP架构核心技术

• 最终一致性模型：

  sequenceDiagram
    用户->>应用： 下单请求
    应用->>DB主库： 写订单
    应用-->>用户： “支付成功”
    DB主库->>DB从库： 异步复制（延迟2秒）
    用户->>应用： 立即查订单
    应用->>DB从库： 读未同步数据
    应用-->>用户： “订单不存在”  → 前端显示“处理中”
  

• 柔性事务：Saga模式、TCC补偿事务

四、银行场景的CP实践案例

案例：跨行转账（涉及银行A和银行B）

1. 强一致性保障流程：

   # 伪代码 - 2PC实现
   def transfer():
     try:
        # 阶段1：准备
        bankA.prepare(debit_account, amount)  # A行扣款预占
        bankB.prepare(credit_account, amount) # B行入账预占
        
        # 阶段2：提交
        if bankA.commit() and bankB.commit():  # 双中心确认
            return "转账成功" 
        else:
            rollback()  # 任何失败则全局回滚
     except NetworkPartition:
        freeze_accounts()  # 网络分区时冻结相关账户
        return "系统维护中，请稍后再试"  # 牺牲可用性
   

2. 银行特殊设计：
   • 超时熔断：单笔转账超过500ms强制终止（避免用户重复操作）
   • 日终对账兜底：即使返回失败，夜间通过清算文件核对修正

五、银行系统为何选择CP而不是AP

“银行核心系统优先保障CP源于三个刚性需求：

1. 资金安全零容忍：网络分区时宁可停服（牺牲A），也要确保账户金额100%准确（保C）
2. 监管合规要求：遵照《支付清算系统管理办法》第22条，必须实现跨节点强一致性
3. 故障可控性：计划内停机（如央行大小额支付系统日切）是预设的CP保障手段

反观互联网系统：

• 商品库存允许短暂超卖（最终一致性）
• 优先保障高峰流量可用性（如双十一降级读缓存）
  这种差异本质是风险成本的权衡——银行错账1分钱可能引发监管处罚，而互联网1%订单异常可通过补偿解决。”

💡 技术人理解关键：

• CP≠完全放弃A：银行通过同城双活将停机时间压缩至秒级（如30秒RTO）
• AP≠放弃C：互联网仍要保障最终一致性（如30分钟内订单状态同步）
  选择本质是对“不一致时间窗口”的容忍度差异——银行要求=0，互联网允许>0。