夏商集团ERP系统需整合采购、库存、销售、财务模块，请设计架构，说明模块间数据交互和一致性保障。

1) 【一句话结论】：采用基于事件驱动的集中式数据集成架构，通过统一数据模型和消息队列实现采购、库存、销售、财务模块间的数据交互，并利用分布式事务或最终一致性机制保障数据一致性。

2) 【原理/概念讲解】：老师口吻，解释ERP模块集成需解决数据共享与一致性。核心是数据集成模式（如事件溯源：模块操作生成事件，其他模块消费事件更新状态）和数据一致性保障（事务一致性：如库存扣减与订单创建在同一个事务中；最终一致性：允许短暂不一致，通过重试/补偿恢复）。
类比：像公司各部门（采购、库存、财务）用同一个“共享文件柜”，采购提交订单后，实时发送“库存扣减”“财务应付”消息到对应部门，库存部门更新库存，财务部门记录应付，确保文件内容同步。

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

模式	定义	特性	使用场景	注意点
事件驱动（实时）	模块操作生成事件，通过消息队列实时传递	低延迟，实时更新，依赖消息队列可靠性	库存实时扣减、财务实时记账	需处理消息丢失/重复消费
定时同步（ETL）	定期（如每小时）从源模块抽取数据，转换后加载到目标模块	延迟较高，适合非实时业务	库存历史数据同步、财务报表生成	需处理数据冲突（如库存扣减后订单未确认，ETL可能覆盖最新数据）

4) 【示例】：伪代码示例（采购模块创建订单，库存/财务模块消费消息）。

// 采购模块：创建采购订单
function createPurchaseOrder(orderId, productId, quantity, supplierId) {
    insert into purchase_orders (id, product_id, quantity, supplier_id) values (orderId, productId, quantity, supplierId);
    send_message("inventory:decrease", {order_id: orderId, product_id: productId, quantity: quantity});
    send_message("finance:payable", {order_id: orderId, amount: calculateAmount(productId, quantity)});
}

// 库存模块：处理库存扣减消息
function handleInventoryDecrease(message) {
    const stock = getStock(message.product_id);
    if (stock < message.quantity) throw new Error("库存不足");
    updateStock(message.product_id, stock - message.quantity);
    logOperation("inventory_decrease", message);
}

// 财务模块：处理应付消息
function handleFinancePayable(message) {
    const payable = getPayable(message.order_id);
    if (payable) return; // 幂等处理
    insert into payables (order_id, amount, status) values (message.order_id, message.amount, "pending");
    sendNotification("supplier", "应付订单", message.amount);
}

5) 【面试口播版答案】：夏商集团ERP系统整合采购、库存、销售、财务模块，核心采用事件驱动的集中式数据集成架构。通过统一数据模型（JSON格式事件）和消息队列（如Kafka）实现模块间数据交互：采购模块创建订单后，实时发送“库存扣减”“财务应付”事件到库存、财务模块；库存模块扣减库存并记录日志，财务模块记录应付账款。数据一致性通过分布式事务（如两阶段提交）或最终一致性保障：核心业务（库存扣减）用分布式事务确保原子性，非核心业务（财务记录）用最终一致性，通过重试/补偿机制处理短暂不一致。这种架构既保证数据实时同步（如库存实时更新），又兼顾系统性能与容错性，适合企业级ERP的高并发需求。

6) 【追问清单】：

• 问：数据一致性的具体实现方式？比如库存扣减和订单创建是否用两阶段提交？
  回答要点：核心业务（库存扣减）采用分布式事务（两阶段提交）确保原子性；非核心业务（财务记录）用最终一致性，通过补偿事务处理短暂不一致。
• 问：模块间数据冲突如何处理？比如库存扣减后订单被取消，如何回滚？
  回答要点：通过消息队列幂等性（处理前检查是否已处理）和补偿机制（库存增加、财务退款），确保冲突时正确回滚。
• 问：架构的扩展性如何？未来增加生产模块，如何集成？
  回答要点：采用模块化设计，通过标准接口（API、消息队列）扩展，新增模块只需实现消息消费逻辑，不影响现有模块，支持水平扩展。
• 问：性能考虑？高并发订单时，消息队列是否会成为瓶颈？
  回答要点：采用消息队列批量处理、消费端并行，以及Redis缓存减少数据库访问，确保高并发下的性能。

7) 【常见坑/雷区】：

• 坑1：忽略数据模型统一，导致模块间数据格式不一致。
  雷区：只说“用API集成”而不提数据模型标准化，导致数据转换错误。
• 坑2：只强调实时同步，忽略最终一致性，导致高并发下数据不一致。
  雷区：认为所有模块必须实时同步，而实际业务允许短暂不一致，增加系统复杂度。
• 坑3：架构过度复杂，引入过多技术（如分布式事务、消息队列），导致维护成本高。
  雷区：用两阶段提交处理所有业务，而简单业务用最终一致性更高效。
• 坑4：未区分业务场景（如库存实时扣减 vs 定时更新），统一采用实时同步。
  雷区：库存模块压力过大，影响性能。
• 坑5：容错机制不足，消息丢失/重复消费导致数据错误。
  雷区：未提及消息重试策略、幂等处理，导致系统不稳定。