设计一个高并发的项目管理系统，需支持数百个项目同时在线管理，保证数据一致性与系统可用性，请说明数据库选型、分布式架构设计及容灾方案。
答案
1) 【一句话结论】采用TiDB作为核心数据库，结合微服务拆分、多级缓存（Redis+Memcached）、Saga分布式事务，以及多数据中心主从多活容灾方案，构建高并发项目管理系统，有效保障数百项目同时在线时的数据一致性与系统可用性。
2) 【原理/概念讲解】高并发下，数据库选型需平衡一致性（ACID）与扩展性。传统关系型数据库（如MySQL）强一致但扩展性差，NoSQL（如Cassandra）扩展性好但一致性弱。TiDB作为混合架构，兼容MySQL生态且支持分布式事务，适合混合场景。分布式架构中，微服务拆分（如项目管理、资源调度）通过消息队列（MQ）异步通信，降低服务间耦合。缓存分三级：Redis（热点数据+分布式锁）、Memcached（预取缓存），减少数据库压力。分布式锁用于避免并发冲突（如项目状态修改），Saga模式解决跨服务事务，将事务拆分为步骤，失败时补偿回滚。容灾采用多数据中心主从多活，实时数据同步，故障时秒级切换。
3) 【对比与适用场景】
| 对比项 | MySQL（传统关系型） | MongoDB（文档型） | Cassandra（分布式NoSQL） | TiDB（混合架构） |
|---|---|---|---|---|
| 定义 | 结构化数据，ACID事务 | 文档存储，灵活Schema | 分布式NoSQL，高可扩展 | 兼容MySQL生态，分布式事务 |
| 特性 | 强一致性，事务支持 | 灵活Schema，写入延迟低 | 高可扩展，写入密集 | 兼容MySQL，分布式事务 |
| 使用场景 | 事务敏感的结构化数据 | 非结构化内容管理 | 日志、实时数据流 | 混合场景（事务+扩展） |
| 注意点 | 分库分表复杂度高 | 写入延迟较高 | 数据一致性级别（最终一致） | 学习成本高 |
4) 【示例】
- 分库分表策略（项目ID哈希分库，时间分表）：
分库：项目ID取模（如项目ID % 8），分配到不同数据库实例（DB1, DB2...），避免单库压力。
分表：按时间分表，如按月，表名格式为projects_202405，新数据写入对应月份表，查询时按月份合并。 - 缓存雪崩预加载伪代码：
def preload_hot_data(): hot_items = ["project_list", "status_codes"] for item in hot_items: data = db.query(f"SELECT * FROM {item}") memcached.set(item, data, ex=3600) # 设置1小时过期 - Saga模式示例（项目创建流程）：
步骤1：MySQL插入项目记录（INSERT INTO projects (id, name) VALUES (UUID(), '新项目')）；
步骤2：发送MQ消息（“项目创建成功”，包含项目ID）；
步骤3：Redis更新状态（SET project_status:#{id} "active"）；
若步骤2失败，通过MQ补偿消息触发：
步骤4：补偿步骤1（DELETE FROM projects WHERE id = #{id}）；
补偿步骤3（DEL project_status:#{id}）。
幂等性处理：补偿时检查项目记录是否存在（SELECT EXISTS (SELECT 1 FROM projects WHERE id = #{id})），避免重复删除。
5) 【面试口播版答案】
面试官您好，针对高并发项目管理系统，我设计的方案核心是“TiDB+微服务+多级缓存+Saga事务+多活容灾”。首先，数据库选型用TiDB，它兼容MySQL生态且支持分布式事务，能处理数百项目的高并发读写。系统拆分为项目管理、资源调度等微服务，服务间通过Kafka异步通信，降低耦合。缓存分两层，Redis用于热点数据（如项目列表）和分布式锁，Memcached用于预取缓存（低峰期预加载热点数据，避免雪崩）。分布式锁采用Redis加锁+10秒续期，避免超时竞争。事务用Saga模式，将项目创建拆为插入数据库、发MQ、更新状态三步，失败时补偿回滚，确保幂等。容灾采用多数据中心主从多活，数据实时同步（延迟<1秒），故障时秒级切换，同时做定时备份和灾备中心。这样既能保证数据一致性，又能提升系统可用性。
6) 【追问清单】
- 问题1：数据库分库分表策略？
回答要点：按项目ID哈希分库（如项目ID % 库数量），按时间分表（如按月），避免单库压力，支持高并发扩展。 - 问题2：缓存雪崩的预加载具体如何实现？
回答要点：系统启动时或低峰期（如凌晨），批量加载热点数据（如项目列表、常用状态）到Memcached，设置较长的过期时间（如1小时），减少突发请求的缓存失效。 - 问题3：多活容灾中数据同步延迟如何控制？
回答要点：通过TiDB的多活集群配置，设置同步延迟阈值（如<1秒），监控数据同步状态，确保故障切换时数据一致性。 - 问题4：Saga模式中补偿步骤的幂等性如何保证？
回答要点：补偿时先检查业务状态（如项目记录是否存在），再执行回滚操作，避免重复补偿。例如，补偿删除项目时，先查询项目是否存在，若不存在则跳过。 - 问题5：微服务间通信如何保证消息可靠性？
回答要点：使用消息队列的确认机制（如Kafka的ack=1），确保消息至少被消费一次，失败时重试或补偿。
7) 【常见坑/雷区】
- 坑1：只推荐关系型数据库，忽略分库分表和缓存预加载等工程细节，导致方案不落地。
- 坑2：分布式锁未考虑续期机制，导致锁超时后竞争，影响并发性能。
- 坑3：容灾方案只说备份，未提多活部署的实时性，无法应对秒级故障切换。
- 坑4：Saga模式未说明幂等性，可能导致重复补偿，数据不一致。
- 坑5：架构拆分过粗，导致服务间耦合度高，无法支持高并发。