设计一个支持多泊位、多船舶、多设备的分布式调度系统，用于优化船舶靠离泊、装卸作业的调度。请说明系统架构（如微服务、分布式数据库）、数据一致性（CAP理论应用）、以及如何处理高并发请求（如高峰期船舶进港请求）。
答案
1) 【一句话结论】：针对多泊位、多船舶调度场景，采用微服务架构拆解业务模块（泊位管理、船舶调度、设备调度），关键数据（如船舶位置、设备状态）通过TiDB分布式数据库的CP模式保障强一致性，非关键数据采用最终一致性；结合令牌桶限流、Redis缓存热点数据、Kafka异步处理，应对高并发请求，实现高效协同调度。
2) 【原理/概念讲解】：首先，微服务架构拆分。将调度系统拆分为泊位管理、船舶调度、设备调度、作业计划生成等独立服务，边界依据业务职责（如泊位管理服务负责泊位状态维护与分配，船舶调度服务处理船舶进港请求，设备调度服务管理设备资源）。每个服务独立部署，通过API网关统一入口，提升扩展性（类比港口不同部门分工，如泊位部、船舶部、设备部各司其职，协同完成作业）。其次，分布式数据库选型。因多泊位、多船舶数据分散且需高并发读写（高峰期船舶进港请求频繁），选择TiDB（支持SQL、分布式事务、读写分离）。业务中读多写少，但关键数据（船舶位置、设备状态）需强一致性（如位置错误导致调度冲突），故采用CP模式（强一致性优先，牺牲部分可用性，类比银行转账必须保证金额一致，即使牺牲部分并发）。CAP理论应用：调度业务对数据一致性要求极高，选择CP模式，通过分布式事务（两阶段提交）保障关键数据一致性，若事务失败则触发补偿机制恢复数据（类比银行转账失败后回滚，确保数据正确）。高并发处理：高峰期船舶进港请求多，采用令牌桶算法限流（参数依据压力测试，如通过压测确定系统最大吞吐量为每秒1000请求，设定每秒1000令牌，每令牌处理1个请求，避免系统过载；缓存热点泊位状态到Redis（TTL设为5分钟），减少数据库压力；非实时任务（如作业计划生成）通过Kafka异步处理，解耦服务，降低数据库负载；设备状态实时上报通过消息队列同步，确保调度服务及时获取最新状态（类比港口高峰期用分拣机+缓存提高效率）。
3) 【对比与适用场景】：
| 特性 | 微服务架构 | 单体架构 |
|---|---|---|
| 定义 | 系统拆分为多个独立服务 | 整个系统为一个单体应用 |
| 扩展性 | 按服务独立扩展（如增加船舶调度服务扩展） | 整体扩展，扩展性差 |
| 数据一致性 | 关键数据（如船舶位置）通过TiDB CP模式保障强一致性，非关键数据最终一致性 | 单体数据库（如MySQL）保证强一致性，但扩展性差 |
| 高并发处理 | 限流（令牌桶）、缓存（Redis）、异步（Kafka） | 单体架构高并发时易崩溃，需垂直扩展（成本高） |
| 使用场景 | 复杂业务系统（多泊位、多船舶、多设备调度） | 小型、简单系统（如单泊位小型码头） |
| 注意点 | 服务间通信需考虑延迟与一致性，需设计服务治理（如熔断、降级） | 开发效率高，但维护复杂，扩展性差 |
4) 【示例】：以船舶进港请求为例，处理流程：
- 前端发送请求（JSON）：
{ "shipId": "SH001", "arrivalTime": "2024-05-20T10:00:00Z", "cargoType": "集装箱", "requiredBerth": "B3" } - API网关接收，调用“船舶调度服务”：
# 船舶调度服务处理逻辑 def handle_ship_arrival(ship_data): # 1. 限流检查（令牌桶，每秒1000令牌） if not rate_limiter.check(): return {"code": "429", "msg": "请求过多"} # 2. 缓存检查（Redis缓存泊位状态） berth_status = redis.get(f"berth_{ship_data['requiredBerth']}") if not berth_status: # 3. 分布式数据库查询（TiDB） berth = tibd.query_berth(ship_data['requiredBerth']) if berth.is_occupied: return {"code": "409", "msg": "泊位已被占用"} # 4. 分布式事务更新数据库（TiDB） with tibd.transaction(): tibd.update_berth_status(ship_data['requiredBerth'], "occupied") tibd.insert_ship(ship_data['shipId'], ship_data['arrivalTime']) # 5. 发送消息到作业计划服务（Kafka） kafka_producer.send("作业计划主题", ship_data) # 6. 返回成功响应 return {"code": "200", "msg": "调度成功"}
5) 【面试口播版答案】：各位面试官好，针对中远海运重工的分布式调度系统设计问题，我的核心思路是采用微服务架构拆解业务，结合TiDB分布式数据库保障关键数据强一致性，并通过限流、缓存、异步处理应对高并发。首先，系统将调度业务拆分为泊位管理、船舶调度、设备调度等微服务，每个服务独立负责泊位状态维护、船舶进港请求处理、设备资源分配，通过API网关统一入口，提升扩展性与灵活性（类比港口不同部门分工协作）。数据一致性方面，因调度业务对船舶位置、设备状态一致性要求极高（如冲突会导致调度错误），选择TiDB的CP模式（强一致性优先），通过分布式事务（两阶段提交）保障关键数据一致性，若事务失败则触发补偿机制恢复数据（类比银行转账，必须保证数据不冲突）。高并发处理上，高峰期船舶进港请求多，用令牌桶算法限流（每秒1000令牌），缓存热点泊位状态到Redis（设置5分钟TTL），非实时任务（如作业计划生成）通过Kafka异步处理，设备状态实时上报通过消息队列同步，确保系统能高效响应。这样既能优化调度效率，又能应对多泊位、多船舶的高并发场景。
6) 【追问清单】：
- 问题1：如何保证分布式事务的最终一致性？
回答要点：采用最终一致性+补偿机制，事务提交后通过消息队列通知其他服务，若后续操作失败，触发补偿逻辑（如回滚数据库、重试事务）恢复数据。 - 问题2：微服务拆分的边界条件是什么？
回答要点：依据业务职责划分，如泊位管理服务负责泊位状态维护与分配，船舶调度服务负责船舶进港请求处理与作业分配，设备调度服务负责设备资源分配与状态同步。 - 问题3：系统如何处理设备故障导致的调度冲突？
回答要点：设备状态通过消息队列实时上报，若设备故障，调度服务会触发异常处理（如重新分配任务），并通知运维团队（如告警系统）。 - 问题4：缓存雪崩的应对策略？
回答要点：设置合理的TTL（如5分钟），或使用分布式锁加互斥（如Redis锁），避免缓存穿透（如热点数据缓存未更新导致查询失败）。
7) 【常见坑/雷区】：
- 坑1：忽略数据一致性导致调度冲突（如船舶位置更新不一致，设备调度错误）。
- 坑2：高并发时未做限流，导致系统崩溃（如高峰期船舶进港请求过多，数据库压力过大）。
- 坑3：微服务拆分边界模糊（如泊位管理与服务职责重叠，导致服务间调用混乱）。
- 坑4：CAP理论应用不当（如选AP模式但业务需要强一致性，导致数据不一致）。
- 坑5：缓存未设置TTL，导致缓存雪崩（如热点泊位状态缓存未更新，查询失败）。