设计一个支持宝龙地产多项目并行管理的分布式项目管理系统，需考虑数据一致性、高并发（如开盘时线上选房系统）、容灾备份，请说明系统架构、核心模块及关键技术选型。
宝龙地产管培生难度：困难
答案
1) 【一句话结论】
构建基于微服务架构的分布式项目管理系统，通过分布式数据库哈希分片实现多项目数据水平扩展，结合消息队列异步解耦业务，采用Saga事务处理跨服务数据一致，并采用主从复制和跨机房部署保障容灾，满足高并发选房等场景需求。
2) 【原理/概念讲解】
- 分布式数据库分片（哈希分片+虚拟节点）：按项目ID对房源数据哈希分片，将不同项目数据分散到不同分片节点，避免热门项目数据集中（类比“把热门商品库存分散到不同仓库，避免单一仓库爆仓”）。
- 消息队列幂等性：服务消费消息时，通过检查消息体中的唯一标识（如订单ID）或消费端状态（如订单表加锁），确保重复消费不重复处理（类比“快递单号唯一，避免重复派送”）。
- 缓存双写一致性：数据库更新后，先写入数据库，再通过事务更新Redis缓存，保证数据一致性（类比“写日记先记本子，再同步手机备忘录”）。
- 容灾RTO/RPO：数据库主从同步复制，服务跨机房部署，故障时主从切换，RTO（恢复时间）控制在分钟级，RPO（数据丢失）控制在秒级（类比“银行系统主从备份，故障时秒级切换”）。
3) 【对比与适用场景】
| 分片策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 哈希分片 | 按项目ID+房源ID哈希计算分片 | 数据分散，避免热点 | 热门项目/房源数据 | 需虚拟节点解决哈希碰撞 |
| 范围分片 | 按项目ID范围划分分片 | 数据集中，易扩容 | 新项目数据集中 | 热门项目数据可能集中 |
| 消息队列幂等性方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 状态检查 | 消费端检查订单状态（如已支付） | 简单，依赖数据库 | 库存扣减 | 需保证数据库事务隔离 |
| 唯一标识 | 消费端检查消息体唯一标识（如订单ID） | 独立，不依赖数据库 | 订单创建 | 消息体需包含唯一标识 |
4) 【示例】
用户选房流程（伪代码）：
- 用户请求选房，API网关路由到订单服务（项目ID=1）。
- 订单服务创建订单，写入订单表（TiDB分片1），并发送库存扣减消息（Kafka主题：stock-reduce，消息体：{order_id: 1001, house_id: 101, project_id: 1}）。
- 库存服务消费消息：先查Redis缓存（key: stock:1:101），缓存存在则扣减，否则查数据库（TiDB分片1），扣减后更新Redis（双写事务），发送确认消息（Kafka主题：stock-confirm，消息体：{order_id: 1001, house_id: 101, success: true}）。
- 订单服务消费确认消息：检查订单状态（未支付），更新订单状态为“已锁定”，发送支付指令。
- 支付服务处理支付，成功后订单服务更新状态为“已完成”。
5) 【面试口播版答案】
“面试官您好，我设计的分布式项目管理系统旨在支持宝龙地产多项目并行管理，同时应对高并发选房和容灾需求。系统架构分为前端、API网关、微服务集群（项目服务、库存服务、订单服务等），数据层采用TiDB分布式数据库，按项目ID哈希分片，避免热门项目数据集中。业务层用Saga模式处理分布式事务，比如选房时，订单服务创建订单后，通过Kafka异步通知库存扣减，避免服务阻塞。消息队列确保消息不丢失，且消费端通过订单ID检查状态实现幂等，防止重复扣减。高并发下，Redis缓存热点房源信息，并设置限流熔断，数据库读写分离。容灾方面，数据库主从同步复制，服务集群跨机房部署，故障时主从切换，RTO约5分钟，RPO约1秒。关键技术选型：Spring Cloud、Kafka、TiDB、Redis。这样既能支持多项目并行，又能应对开盘高并发，保证数据一致性和系统稳定。”
6) 【追问清单】
- 问：分片策略如何避免热门房源数据集中？比如热门楼盘数据量巨大？
回答要点：采用哈希分片（按项目ID+房源ID哈希），结合虚拟节点技术，将热门房源数据分散到多个分片节点，避免单节点压力过大。 - 问：库存扣减失败后如何补偿？如何保证幂等？
回答要点：库存服务扣减失败后，回滚库存并重试，订单服务消费库存确认消息时，检查订单状态（如已支付）避免重复处理，确保幂等。 - 问：容灾下多机房数据同步机制？RTO/RPO具体指标？
回答要点：数据库主从同步复制，服务跨机房部署，数据同步延迟控制在毫秒级，故障时主从切换，RTO约5分钟，RPO约1秒。 - 问：高并发下Redis缓存如何处理雪崩？如何保证双写一致性？
回答要点：Redis缓存热点数据并设置TTL，同时数据库更新后双写（先写数据库，再更新缓存），通过事务保证一致性。
7) 【常见坑/雷区】
- 坑1：分片策略选错导致热点，比如用范围分片，热门项目数据集中。
- 坑2：消息队列幂等性处理不当，导致重复扣库存。
- 坑3：容灾方案不具体，只说备份，未说明多机房同步和RTO/RPO。
- 坑4：高并发下忽略缓存和限流，系统性能不足。
- 坑5：分布式事务选错，用2PC处理复杂业务，导致阻塞。