行李追踪系统需要确保每个行李从托运到提取的全程数据一致，请设计一个数据一致性保障方案，处理跨系统数据同步问题。

1) 【一句话结论】采用“事件溯源+消息队列+事务补偿”的混合方案，通过异步消息驱动跨系统数据同步，结合最终一致性模型，确保行李从托运到提取的全程数据一致，核心是“事件驱动+补偿机制”解决跨系统数据同步问题。

2) 【原理/概念讲解】老师口吻，解释跨系统数据一致性的难点。比如，行李追踪涉及值机系统（录入信息）、行李处理系统（分拣、装载）、行李提取系统（出库），每个系统独立，数据同步依赖消息。传统同步（如RPC调用）效率低，且易阻塞。采用事件溯源：每个系统将操作转化为事件（如“行李托运完成”“行李装载至航班”），通过消息队列（如Kafka）发布，其他系统消费事件并更新本地状态。若某系统消费失败，触发补偿事务重试，最终保证数据最终一致。类比：就像快递员（系统）收到包裹（事件），依次传递给分拣（处理系统）、派送（提取系统），若某环节卡住，后续环节通过“补送”完成，最终包裹状态一致。

3) 【对比与适用场景】

方案类型	定义	特性	使用场景	注意点
强一致性	所有系统数据立即同步，任何系统读取都一致	严格，实时同步	需要实时数据一致性，如金融交易	系统耦合度高，故障时恢复复杂
最终一致性	系统数据可能短暂不一致，最终会同步	异步，消息驱动	对实时性要求不高，如物流追踪	需要补偿机制处理失败

4) 【示例】伪代码示例（托运流程）：

• 值机系统：当用户托运行李，生成事件 Event: BagCheckedIn, bagId=123, passengerId=456, flightNo=CA1234，发送到消息队列。
• 行李处理系统：消费事件，更新数据库 bag_status = 'in_transit'，并生成新事件 Event: BagLoaded, bagId=123, flightNo=CA1234。
• 行李提取系统：消费事件，更新数据库 bag_status = 'ready_for_pickup'。
• 补偿：若行李处理系统消费失败，启动补偿事务重发事件；若提取系统消费失败，补偿事务重试消费事件，更新状态。

5) 【面试口播版答案】（约80秒）
“面试官您好，针对行李追踪系统跨系统数据一致性问题，我的方案核心是采用事件溯源+消息队列+事务补偿的混合模型，确保托运到提取的全程数据一致。首先，每个关键操作（如托运、装载、出库）都会生成一个事件，通过消息队列（如Kafka）异步发布，避免系统阻塞。比如值机系统托运后，发送‘行李托运完成’事件，行李处理系统消费后更新状态，再发‘装载完成’事件，提取系统消费后标记可提取。若某个系统消费失败，触发补偿事务重试，最终保证数据最终一致。这样既解决了跨系统同步的效率问题，又通过补偿机制处理故障，确保全程数据一致。”

6) 【追问清单】

• 问：如何处理系统延迟或消息队列积压？答：通过消息队列的持久化存储和消费重试机制，结合批量消费减少延迟，同时设置重试次数和超时时间，避免无限循环。
• 问：如何保证数据最终一致性？答：通过补偿事务，当消费失败时，重发事件并重试，结合时间戳或版本号避免重复处理，最终所有系统状态同步。
• 问：系统故障时（如值机系统宕机），如何恢复？答：值机系统恢复后，重新消费未处理的事件，更新状态，并通知后续系统，通过补偿机制确保数据一致性。

7) 【常见坑/雷区】

• 坑1：只强调分布式事务，忽略异步处理的效率，导致系统性能下降。
• 坑2：忽略补偿机制，系统故障时数据不一致，无法恢复。
• 坑3：未考虑消息队列的可靠性，如未持久化存储，导致事件丢失。
• 坑4：强一致性设计，导致系统耦合度高，扩展性差。
• 坑5：未处理消费失败后的重试策略，可能导致死循环或重复处理。