旅游App的一体化行程规划并非简单把景点和酒店塞进同一个页面。它需要在用户调整行程的任意时刻，让景点票务库存、酒店房态和行程时间轴保持同步。一个典型的行程数据结构会把每一天拆成多个活动单元，每个单元关联资源类型、资源ID、日期、人数和状态。票务系统以SKU为单位管理库存，酒店系统以房型加日期管理可售数量。当用户把某个景点从第二天移到第三天，系统必须同时处理第二天的库存释放和第三天的库存占用，同时重新计算该天晚上的酒店是否需要更换或保留。
行程规划的核心挑战在于冲突检测。同一城市的不同景点之间可能存在最短游览时长约束，相邻活动之间需要预留交通时间。如果用户在上午安排了博物馆，下午安排了相距三十公里的主题乐园，但没有预留午间交通时间，系统应当给出提示。这个判断不能只靠地理距离，还需要结合实时路况、景点开放时间和用户偏好。为了支持动态调整，行程数据可以用有向无环图来表示，节点代表活动，边代表先后依赖。图的拓扑排序结果就是当天的活动顺序，调整某个节点只会影响局部拓扑，而不会强制全量重算。
一、行程规划引擎的数据模型与冲突检测
行程数据在服务端通常以天为维度存储。每个Day对象包含日期、城市、活动列表和酒店绑定信息。活动对象包含活动类型、资源ID、开始时间、结束时间、人数和状态。资源ID可以是景点编码、演出场次ID或者交通班次。为了便于扩展，活动类型使用枚举值，例如ATTRACTION、HOTEL、TRANSPORT。行程编辑操作被抽象为命令，比如AddActivityCommand、MoveActivityCommand、RemoveActivityCommand。每个命令执行前会经过冲突检测器校验时间重叠、地理距离和资源可用性。
冲突检测器可以拆成三个子规则。时间规则检查同一活动是否与其他活动时间重叠，重叠超过阈值则拒绝。地理规则通过经纬度计算两点直线距离，再乘以道路绕行系数估算实际车程，超过设定时长则提示。资源规则调用票务和酒店服务查询指定日期是否可售。三个规则以管道模式串联，前一个规则失败就直接返回错误，减少无效的远程调用。代码示例展示了一个基于Java的检测器接口。
public class ConflictDetector {
private final List<Rule> rules = List.of(
new TimeOverlapRule(),
new GeoDistanceRule(),
new ResourceAvailabilityRule()
);
public List<String> validate(TripDay day, Activity newActivity) {
List<String> errors = new ArrayList<>();
for (Rule rule : rules) {
String error = rule.check(day, newActivity);
if (error != null) {
errors.add(error);
if (rule.isBlocking()) {
break;
}
}
}
return errors;
}
}
冲突检测器只负责给出错误信息，真正的库存操作由票务和酒店服务独立完成。这是因为行程规划模块不应该直接持有库存数据，否则会产生数据耦合。通过接口调用可以保持领域边界清晰，也方便后续接入不同类型的资源供应商。但行程变更需要保证多个服务之间的最终一致，这一点在后面事务章节展开。
二、景点票务系统的库存锁定与异步确认
景点票务通常有固定的日库存，例如某场演出每天限量一千张。用户在行程中添加景点后，系统需要临时锁定库存，防止支付过程中被其他用户抢走。锁定不能是永久占用，否则取消行程的用户会浪费库存。常见的做法是设置锁定超时，例如十五分钟。超时未支付就自动释放。这个逻辑可以用Redis的字符串加过期时间实现，键格式为ticket:sku:date:session，值为已锁数量，过期时间就是锁定窗口。每次锁定时需要调用INCRBY检查是否超过总库存。
public boolean lockTicket(String sku, String date, String session, int quantity) {
String key = "ticket:" + sku + ":" + date + ":" + session;
long locked = redis.incrBy(key, quantity);
if (locked > totalStock(sku, date, session)) {
redis.decrBy(key, quantity);
return false;
}
redis.expire(key, 15, TimeUnit.MINUTES);
return true;
}
Redis方案的优势是性能高，适合高并发抢票场景。但直接操作Redis需要处理缓存与数据库的库存同步。如果Redis意外宕机，锁定量可能丢失，导致超卖。因此票务服务还需要在数据库中记录每一笔锁定流水，状态包括LOCKED、CONFIRMED、RELEASED。通过定时任务扫描超时未确认的流水并释放Redis中的占用。这样即使缓存丢失，也能根据流水恢复。在分布式环境中，锁定的原子性可以通过Lua脚本实现，把检查库存和累加操作合并成一个步骤。
异步确认是另一个关键点。用户点击提交订单后，票务服务会收到支付确认消息。此时需要把锁定状态从LOCKED改为CONFIRMED，并扣减数据库中的剩余库存。如果支付失败或超时，则释放锁定。这个过程可以使用消息队列解耦，避免订单服务直接同步调用票务接口造成长事务。消息队列需要考虑重复消费，因此锁定流水表需要唯一约束，比如订单号加SKU加日期作为唯一键。
三、酒店预订的动态打包与分布式事务
酒店和景点票务最大的区别是房价会随日期、入住人数和连住天数动态变化。行程调整可能导致酒店日期变化，原来的房型可能没有房，或者价格不同。旅游App需要根据新行程重新查询酒店报价，并生成新的预订方案。动态打包通常以酒店服务提供的报价接口为基础，输入城市、入住日期、离店日期、人数和房型偏好，返回可售房型及价格。行程规划服务拿到报价后，与景点票务锁定结果一起展示给用户。
这里的事务模型更加复杂。一个订单可能同时包含景点门票和酒店房间，用户期望要么全部下单成功，要么全部失败。但票务和酒店是两个独立系统，无法使用单库事务。可以采用Saga模式。订单服务先调用票务锁定，再调用酒店锁定，如果酒店锁定失败，则发送补偿命令释放票务锁定。反过来，酒店锁定成功但支付失败，需要同时释放两边。补偿操作必须幂等，即同一个释放命令重复执行不会重复扣减。用代码表示一个简单的Saga协调过程如下。
def create_order(ticket_req, hotel_req):
ticket_lock = ticket_service.lock(ticket_req)
if not ticket_lock.success:
return {"status": "ticket_unavailable"}
try:
hotel_lock = hotel_service.lock(hotel_req)
if not hotel_lock.success:
ticket_service.release(ticket_lock.lock_id)
return {"status": "hotel_unavailable"}
payment = payment_service.charge(ticket_lock, hotel_lock)
if not payment.success:
hotel_service.release(hotel_lock.lock_id)
ticket_service.release(ticket_lock.lock_id)
return {"status": "payment_failed"}
return {"status": "success", "ticket_lock": ticket_lock, "hotel_lock": hotel_lock}
except Exception as e:
hotel_service.release(hotel_lock.lock_id)
ticket_service.release(ticket_lock.lock_id)
raise e
这段代码展示的是同步协调流程，在生产环境中通常会替换为事件驱动的Saga，以便服务之间不会因为长时间阻塞导致资源占用。例如订单服务发布OrderCreated事件，票务服务监听后锁定并发布TicketLocked事件，酒店服务收到后锁定并发布HotelLocked事件。如果中途失败，补偿事件会按相反顺序触发释放。