星河电子作为电子元器件供应商，需要管理上游供应商（如设备厂商）和下游客户。请设计一个简化的供应商关系管理系统（SRM）的核心模块，并说明如何保证数据一致性。

1) 【一句话结论】：核心模块为供应商准入与合同管理、订单与交付协同、绩效评估，通过分布式事务（Saga模式）结合本地事务保证数据一致性，确保供应商全生命周期管理的数据同步与最终一致性。

2) 【原理/概念讲解】：SRM需覆盖供应商全生命周期，核心模块包括：

• 供应商准入与合同管理：包含资质审核（如设备厂商的认证文件）、合同审批（采购合同签订、条款审核）、准入流程（多部门审批后激活供应商账户），与订单模块关联（只有准入的供应商才能接收订单）。
• 订单与交付协同：处理采购订单创建、状态流转（创建、接收、生产、交付）、交付跟踪（物流信息、库存检查），核心业务场景。
• 绩效评估：基于订单数据计算交付准时率、质量合格率、响应速度等指标，驱动供应商优化。
  数据一致性关键：分布式系统中，采用Saga模式（分阶段事务），每个阶段提交本地事务，通过事件触发补偿。例如订单创建后，发布“订单创建”事件，供应商模块更新订单状态并检查库存（本地事务），若库存不足发布失败事件，触发退款补偿；若库存充足，发布交付计划事件，交付模块安排发货。最终确保数据最终一致，类似电商订单系统解耦各环节。

3) 【对比与适用场景】：

策略	定义	特性	使用场景	注意点
集中式事务（ACID）	单事务控制所有操作，保证原子性	强一致性，操作要么全成功要么全失败	交易金额扣款、订单创建（如支付时扣款）	系统复杂，高并发下可能阻塞，影响性能
Saga模式（分阶段事务）	分阶段提交本地事务，通过事件触发补偿	最终一致性，允许短暂不一致，通过补偿恢复	供应商订单处理（下单、生产、交付）	需要补偿逻辑，复杂度增加，需确保补偿不重复执行
分布式锁（并发控制）	防止并发操作冲突，保证原子性	临时阻塞其他请求，确保操作独占	库存检查、订单状态更新（高并发场景）	可能导致请求延迟，需合理设置锁超时

4) 【示例】伪代码（订单创建流程，含并发控制与补偿）：

// 1. 创建订单（本地事务 + 分布式锁）
function createOrder(orderId, supplierId, amount):
    // 获取分布式锁（假设Redis实现）
    if not acquireLock('order:create:' + orderId, 10):
        return "并发冲突，请重试"
    // 创建订单（本地事务）
    insert into orders(orderId, supplierId, amount, status='created')
    // 发布事件
    publish event: OrderCreated(orderId, supplierId, amount)
    releaseLock('order:create:' + orderId)

// 2. 供应商处理订单（检查库存 + 分布式锁）
function handleOrderCreated(event):
    // 获取分布式锁（检查库存）
    if not acquireLock('inventory:check:' + event.orderId, 5):
        return "并发冲突，库存检查失败"
    // 更新订单状态（本地事务）
    update orders set status='received' where orderId=event.orderId
    // 检查库存（本地事务）
    check inventory for supplierId=event.supplierId, amount=event.amount
    if inventory sufficient:
        publish event: DeliveryScheduled(orderId=event.orderId, deliveryTime='2024-05-20')
    else:
        publish event: OrderFailed(orderId=event.orderId, reason='inventory insufficient')
    releaseLock('inventory:check:' + event.orderId)

// 3. 交付模块处理交付计划（本地事务）
function handleDeliveryScheduled(event):
    schedule delivery for event.orderId, event.deliveryTime
    publish event: DeliveryCompleted(orderId=event.orderId)

// 4. 补偿逻辑（订单失败）
function handleOrderFailed(event):
    // 退款（本地事务）
    refund order event.orderId
    // 更新订单状态为失败
    update orders set status='failed' where orderId=event.orderId

（注：分布式锁用Redis的SETNX命令，Kafka持久化消息，补偿重试采用指数退避策略，避免重复失败）

5) 【面试口播版答案】：面试官您好，针对星河电子的SRM设计，核心模块包括供应商准入与合同管理、订单与交付协同、绩效评估。供应商准入流程确保供应商资质合格，合同审批绑定订单与绩效，订单模块处理采购流程，交付模块跟踪物流。数据一致性通过Saga模式实现：订单创建后，系统发布事件，各模块处理本地事务并更新状态，失败时触发补偿（如库存不足则退款），最终保证数据一致。比如订单创建时，发布“订单创建”事件，供应商模块用分布式锁检查库存，避免并发冲突，库存不足则发布失败事件，触发退款。这样既解耦系统，又通过事件和补偿机制保证数据最终一致。

6) 【追问清单】：

• 问题1：如果供应商系统故障，如何处理？
  回答：消息队列（如Kafka）持久化确保事件不丢失，补偿机制自动重试，避免数据丢失。
• 问题2：如何保证绩效评估数据的实时性？
  回答：事件驱动实时计算（如订单完成事件触发绩效更新），或定时任务从订单数据汇总，确保指标及时更新。
• 问题3：多个订单并发处理时，如何避免库存检查冲突？
  回答：通过分布式锁（如Redis）确保库存检查的原子性，避免并发冲突，保证数据一致性。

7) 【常见坑/雷区】：

• 坑1：仅设计订单模块，忽略供应商准入与合同管理，导致供应商资质审核缺失，影响合作质量。
• 坑2：未解释数据一致性机制，如只说“用事务”，未说明分布式场景下的具体策略（如Saga或两阶段提交）。
• 坑3：未考虑并发控制，高并发下库存检查冲突导致数据不一致，影响订单处理效率。