设计一个支持多校区、多用户（学生、教师、管理员）的实验设备预约与管理系统，需要考虑哪些核心模块和架构？如何保证数据一致性和系统稳定性？

1) 【一句话结论】：采用微服务架构拆分核心功能模块（用户、设备、预约、通知等），结合分布式数据库（分库分表）和消息队列（异步处理），通过Saga模式保证数据一致性，通过负载均衡、集群部署、监控告警保证系统稳定性。

2) 【原理/概念讲解】：
老师口吻解释核心概念：

• 微服务架构：将系统拆分为多个独立服务（如用户管理、设备管理、预约管理、通知服务），每个服务负责特定业务，独立部署、扩展、维护。类比：把大公司拆成多个子公司，每个子公司专注自身业务，协同完成整体目标。
• 分布式事务：跨服务操作（如预约设备需更新用户记录、设备状态、发送通知）时，保证数据一致性。采用Saga模式（将事务拆分为多个本地事务，失败时调用补偿事务回滚），避免2PC的阻塞问题。
• 数据分片：多校区数据按校区ID分库/分表（如reservations_campus1、reservations_campus2），每个校区数据独立存储，减少跨校区查询延迟。
• 缓存与消息队列：Redis缓存热点数据（如设备列表、用户信息），减少数据库压力；Kafka异步处理通知，避免阻塞主流程。

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

架构类型	定义	特性	使用场景	注意点
单体架构	整个系统为一个应用，模块耦合	代码集中管理，开发简单，扩展性差	小规模系统（功能单一）	难以扩展，部署复杂
微服务架构	系统拆分为多个独立服务	模块化，独立开发/部署/扩展，故障隔离	大规模系统（多校区、多用户）	服务间通信复杂，需统一管理

分布式事务方案	原理	适用场景	优缺点
2PC	主库协调，从库准备/提交	跨服务强一致性，数据量小	阻塞时间长，故障恢复复杂
Saga模式	拆分为本地事务+补偿事务	高并发，异步场景	需补偿逻辑，最终一致性

4) 【示例】：
用户预约设备流程伪代码（用户服务、设备服务、预约服务、通知服务）：

# 用户请求预约设备
user_id = 1001
device_id = 101
start_time = "2024-05-20 14:00"
end_time = "2024-05-20 16:00"

# 1. 检查用户权限（用户服务）
user = user_service.get_user(user_id)
if not (user.is_teacher or user.is_student):  # 仅学生/教师可预约
    return {"code": 403, "msg": "无预约权限"}

# 2. 检查设备可用性（设备服务）
device = device_service.get_device(device_id)
if not device.is_available(start_time, end_time):
    return {"code": 400, "msg": "设备不可用"}

# 3. 创建预约记录（预约服务）
reservation = reservation_service.create_reservation(user_id, device_id, start_time, end_time)
if not reservation:
    return {"code": 500, "msg": "预约失败"}

# 4. 更新设备状态（设备服务）
device_service.update_device_status(device_id, start_time, end_time, "reserved")

# 5. 发送通知（消息队列）
notification_service.send_notification(user_id, "预约成功", f"您已成功预约设备 {device.name}，时间 {start_time} - {end_time}")

数据分片示例（按校区分表）：
查询某校区预约：SELECT * FROM reservations_campus1 WHERE device_id = ? AND start_time BETWEEN ? AND ?

5) 【面试口播版答案】：
（约90秒）
“面试官您好，针对多校区、多用户的实验设备预约系统，核心设计思路是采用微服务架构，将系统拆分为用户管理、设备管理、预约管理、通知服务等独立模块，每个模块独立部署和扩展，比如用户服务负责学生、教师、管理员信息，设备服务管理设备状态，预约服务处理预约逻辑，通知服务通过消息队列异步发送通知。为了保证数据一致性，我们采用Saga模式处理跨服务事务，比如预约时需要更新用户预约记录、设备状态并通知用户，若某步骤失败则调用补偿事务回滚，避免数据不一致。对于多校区数据，采用按校区分库分表（数据分片），每个校区数据存储在独立数据库，减少跨校区查询延迟。系统稳定性方面，通过负载均衡部署服务，使用Redis缓存热点数据（如设备列表、用户信息），结合消息队列（如Kafka）异步处理通知，避免阻塞主流程，同时配置监控和告警系统，实时监控服务状态，确保系统高可用。”

6) 【追问清单】：

• 问题1：如何设计多校区数据分片策略？
  回答要点：按校区ID分库或分表，每个校区数据独立存储，查询时根据校区ID路由到对应数据库，避免跨校区查询性能问题。
• 问题2：缓存如何处理数据一致性问题？
  回答要点：缓存数据设置过期时间（如5分钟），当数据更新时，先删除缓存再更新数据库；或使用布隆过滤器、限流解决缓存穿透/雪崩。
• 问题3：系统如何保证高可用？
  回答要点：服务集群部署（Nginx负载均衡），数据库主从复制（读写分离），消息队列集群（Kafka），监控告警（Prometheus+Grafana）。
• 问题4：权限控制如何实现？
  回答要点：基于角色的访问控制（RBAC），用户服务定义角色（学生、教师、管理员），预约服务根据角色检查权限（如学生仅预约个人设备，教师可预约实验室设备）。
• 问题5：跨校区数据同步如何处理？
  回答要点：使用消息队列（如RabbitMQ）发布校区数据变更事件，其他校区消费事件并更新本地数据；或通过定时任务同步数据。

7) 【常见坑/雷区】：

• 坑1：忽略权限隔离，导致不同角色用户能预约所有设备。
  避免方法：明确角色权限，在预约服务中检查用户角色和设备类型（如学生只能预约个人设备，教师可预约实验室设备）。
• 坑2：选择错误的分布式事务方案，导致系统阻塞或数据不一致。
  避免方法：根据业务场景选择Saga模式（异步处理，适合高并发），避免2PC（阻塞时间长）。
• 坑3：缓存未考虑过期策略，导致数据过期后服务错误。
  避免方法：设置合理的缓存过期时间，或使用写时更新、读时回源机制。
• 坑4：消息队列积压导致通知延迟。
  避免方法：配置消息队列消费者数量，监控队列长度，设置重试机制和死信队列。
• 坑5：架构设计过于复杂，导致维护困难。
  避免方法：保持模块化，每个服务职责单一，避免过度设计，优先满足核心需求。