在卫龙双11大促期间，线上订单量激增（峰值QPS达10万/秒），财务结算系统需实时处理订单并更新库存，请描述系统如何保障稳定性（如容灾、负载均衡）和数据准确性（如防重复结算、库存扣减一致性）。

卫龙财务类难度：中等

答案

1) 【一句话结论】通过分层架构+多级容灾+事务一致性保障，结合负载均衡与防重复结算机制，实现高并发下的系统稳定与数据准确。

2) 【原理/概念讲解】
首先讲负载均衡：其核心是分发请求到多台服务器，避免单点故障、提升吞吐量。常见策略有轮询（按顺序分配，均匀负载）、随机（随机选择，避免热点）、加权（按服务器性能分配权重，适配资源差异）、健康检查（定期检查服务器状态，故障时剔除）。例如，Nginx+LVS组合可动态调整后端服务器权重，自动剔除故障节点。

接着讲分布式事务：用于多系统（订单、库存、财务）间保证数据一致性。常见模式有：

两阶段提交（强一致性，但高并发下阻塞严重，适合低并发场景）；
Saga模式（最终一致性，通过补偿事务保证，适合高并发多系统交互）；
最终一致性（通过异步消息传递，适合对一致性要求不高的高并发场景）。

再讲防重复结算：需保证同一请求多次处理结果一致（幂等性）。实现方式有：订单号唯一性（数据库唯一索引）、Redis分布式锁（SETNX指令，锁超时后自动释放）、请求参数校验（如订单号+时间戳）。

最后讲库存扣减一致性：需保证库存扣减与订单状态更新的原子性。常见方案有：

分布式锁（如Redis SETNX，保证同一时间仅一个请求扣减库存）；
乐观锁（通过版本号控制，并发时检查版本是否一致，避免超卖）；
悲观锁（直接锁住资源，直到事务提交，适合低并发场景）。

3) 【对比与适用场景】

对比项	定义	特性	使用场景	注意点
负载均衡策略	分发请求到多台服务器	轮询：均匀分配；随机：随机选择；加权：按权重分配；健康检查：自动剔除故障	新建集群、高并发场景	轮询可能导致新服务器负载低；随机可能导致热点；加权需动态调整权重
分布式事务模式	多系统间保证数据一致性	两阶段提交：强一致性，但高并发阻塞；Saga：最终一致性，补偿逻辑复杂；最终一致性：异步消息，低延迟	需强一致性（低并发）；高并发多系统交互；高并发低一致性要求	两阶段提交性能差；Saga补偿逻辑易循环依赖；最终一致性需重试机制

4) 【示例】

负载均衡配置（Nginx）：

upstream order_service {
    server 192.168.1.1:8080 weight=3; # 主服务器
    server 192.168.1.2:8080 weight=2; # 备服务器
    server 192.168.1.3:8080 weight=1; # 新服务器
    health_check;
}
server {
    listen 80;
    server_name order.welong.com;
    location / {
        proxy_pass http://order_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

防重复结算（订单创建接口伪代码）：

def create_order(order_id, amount):
    # 检查订单号是否已存在（幂等性）
    if check_order_exists(order_id):
        return {"code": 200, "msg": "订单已存在"}
    # 获取分布式锁（Redis）
    lock_key = f"order_lock:{order_id}"
    if not redis.setnx(lock_key, 1, ex=10): # 10秒过期
        return {"code": 200, "msg": "请求重复"}
    try:
        # 执行业务逻辑（扣库存、更新状态）
        deduct_inventory(order_id, amount)
        update_order_status(order_id, "created")
        return {"code": 200, "msg": "订单创建成功"}
    except Exception as e:
        redis.delete(lock_key)
        raise e
    finally:
        redis.delete(lock_key)

库存扣减一致性（分布式锁+乐观锁伪代码）：

def deduct_inventory(product_id, quantity):
    # 获取分布式锁（Redis）
    lock_key = f"inventory_lock:{product_id}"
    if not redis.setnx(lock_key, 1, ex=5): # 5秒过期
        return False
    try:
        # 检查库存（乐观锁：通过版本号）
        current_stock = db.get(f"stock:{product_id}")
        if current_stock < quantity:
            redis.delete(lock_key)
            return False
        # 更新库存（悲观锁：事务）
        db.execute("UPDATE inventory SET stock = stock - ? WHERE product_id = ? AND version = ?", (quantity, product_id, current_stock))
        if db.rowcount == 0:
            redis.delete(lock_key)
            return False
        return True
    except Exception as e:
        redis.delete(lock_key)
        raise e
    finally:
        redis.delete(lock_key)

5) 【面试口播版答案】
“面试官您好，针对双11大促的高并发场景，我主要从系统架构、负载均衡、容灾方案、数据准确性保障这几个方面来回答。首先，系统采用分层架构，前端通过Nginx负载均衡分发请求到多台应用服务器，避免单点故障，提升吞吐量。然后，为了容灾，我们部署了主备数据库（比如RDS主从），当主库故障时自动切换到备库，同时应用层也做了多活部署，比如主应用和备应用同时对外提供服务，通过健康检查自动切换。接下来是数据准确性保障，防重复结算方面，我们通过订单号唯一性+Redis分布式锁实现幂等性，确保同一订单号不会重复处理；库存扣减一致性方面，采用分布式锁+乐观锁结合的方式，先锁住库存资源，再检查库存版本，最后更新库存，避免超卖。另外，系统还配置了监控指标（比如QPS、错误率、库存余量），实时监控系统状态，及时处理异常。这样整体上能保障系统在高并发下的稳定性和数据准确性。”

6) 【追问清单】

问题1：如果主备数据库切换时，有部分订单未完成处理，如何处理？
回答要点：通过补偿事务（Saga模式）处理未完成的订单，或记录未完成订单到队列，后续重试。
问题2：防重复结算的Redis锁如果超时，会不会导致重复处理？
回答要点：设置合理锁过期时间（如10秒），结合订单号唯一性，超时后再次检查订单是否存在，避免重复处理。
问题3：库存扣减的分布式锁如果多个请求同时获取锁失败，会不会导致库存扣减失败？
回答要点：锁过期时间设置合理，通过队列异步处理请求，避免请求堆积。
问题4：系统如何监控负载均衡的健康状态？
回答要点：通过健康检查（定期请求服务器返回200），故障节点自动剔除，避免故障请求。
问题5：如果订单系统与库存系统之间的消息延迟，如何保证数据一致性？
回答要点：采用最终一致性，通过消息队列（如Kafka）异步传递，设置重试机制和死信队列处理延迟。

7) 【常见坑/雷区】

坑1：忽略幂等性导致重复结算（如未检查订单号）。
坑2：库存扣减不原子（如只扣减库存不更新订单状态，超卖）。
坑3：容灾切换延迟（主备切换时数据未同步，导致数据不一致）。
坑4：负载均衡策略选择不当（如随机策略导致热点服务器）。
坑5：分布式事务选型错误（如两阶段提交在高并发下性能差）。