设计一个校园招聘信息发布系统，需支持多学校、多岗位的发布及学生在线投递简历。请描述系统主要模块、数据流，并说明如何保证数据一致性和实时性。
答案
1) 【一句话结论】
校园招聘信息发布系统采用微服务架构，通过Saga模式处理跨服务数据一致性（如岗位发布与学校岗位数更新），结合消息队列实现学生投递后的实时通知，支持多学校、多岗位的灵活管理及学生在线投递，确保数据一致性与实时性。
2) 【原理/概念讲解】
系统分为前端（学生端、管理员端）与后端微服务，后端服务解耦为：
- 学校服务：管理学校信息（新增/编辑学校，校验管理员权限，采用RBAC模型，确保管理员只能操作所属学校）。
- 岗位服务：管理岗位（发布/修改岗位，关联学校，设置状态，如active/inactive）。
- 简历服务：存储学生简历，投递后更新岗位投递数（apply_count）。
- 通知服务：发送投递成功通知（邮件/短信）。
分布式事务：采用Saga模式处理跨服务操作（如岗位发布→更新学校岗位数），通过事务补偿机制（消息队列的补偿任务）确保数据一致性。类比：订单系统中的订单创建与库存扣减，若库存不足则回滚订单，这里岗位发布与学校岗位数更新若失败则回滚。
消息队列：学生投递简历后，调用Kafka发送通知，实现最终一致性，避免高并发下通知延迟或丢失，提升系统吞吐量。
3) 【对比与适用场景】
| 方案 | 数据一致性 | 实时性 | 适用场景 | 注意点 |
|---|---|---|---|---|
| 数据库本地事务 | 强（操作全做或全不做） | 较低（需等待事务提交） | 单服务内操作（如岗位发布，确保数据完整） | 适用于跨服务操作时需分布式方案 |
| Saga模式（事务补偿） | 最终（通过补偿确保一致性） | 中等（需等待补偿任务执行） | 跨服务操作（如岗位发布与学校岗位数更新） | 需设计幂等性，避免重复补偿 |
| 消息队列（最终一致性） | 最终（可能短暂不一致，最终同步） | 高（异步处理，减少延迟） | 实时通知（如投递提醒，允许短暂延迟） | 需设计确认机制（ACK、重试、死信队列） |
4) 【示例】
-
岗位发布事务（伪代码）：管理员调用岗位服务发布岗位：
POST /api/v1/jobs { "schoolId": "school1", "title": "交通设计实习生", "description": "负责校园交通规划方案设计", "requirements": ["交通工程相关专业", "熟练使用CAD"], "status": "active" }岗位服务执行事务：
BEGIN TRANSACTION; INSERT INTO jobs...; UPDATE school_jobs_count SET count = count + 1 WHERE school_id = school1; COMMIT;（假设school_jobs_count表记录每个学校的岗位总数） -
学生投递简历流程：
- 学生端调用简历服务投递简历：
POST /api/v1/resumes { "studentId": "student101", "jobId": "job1", "resumeContent": "..." } - 简历服务执行事务：
INSERT INTO resumes...; UPDATE jobs SET apply_count = apply_count + 1 WHERE id = job1; COMMIT; - 调用Kafka发送通知消息：
{"jobId": "job1", "studentId": "student101", "status": "success"}
- 学生端调用简历服务投递简历：
-
Saga补偿逻辑（若岗位发布失败）：
消息队列中存储“更新学校岗位数”任务（消息ID为“job1_update_count”），若岗位发布失败，触发补偿任务：UPDATE school_jobs_count SET count = count - 1 WHERE school_id = school1;（幂等性：检查消息ID是否已处理，避免重复补偿）
5) 【面试口播版答案】
面试官您好，我设计的校园招聘信息发布系统采用微服务架构，核心模块包括学校管理、岗位管理、简历投递和通知服务。管理员可通过学校管理模块新增/编辑学校信息，通过岗位管理模块发布岗位（关联学校、设置岗位详情）；学生端可查看所有岗位，在线投递简历。数据一致性方面，采用Saga模式处理跨服务操作（如岗位发布与学校岗位数更新），通过事务补偿机制确保数据一致；实时性上，学生投递简历后调用Kafka发送通知，避免高并发下延迟。系统支持多学校、多岗位的灵活管理，同时保障数据一致性和投递通知的及时性。
6) 【追问清单】
- 问：分布式事务中，若岗位发布成功但更新学校岗位数失败，如何回滚？
答：Saga模式中，若后续步骤失败，触发补偿任务（消息队列的补偿任务），回滚已成功步骤（如减少学校岗位数），确保数据最终一致。 - 问：高并发下岗位查询如何优化？
答：岗位服务采用Redis缓存热门岗位信息（按学校ID+热门标签分片），减少数据库压力；数据库按学校ID分库分表（如school1的岗位存储在db1），水平扩展。 - 问：Saga补偿任务如何保证幂等性？
答：在消息队列中为每个补偿任务添加唯一标识（如消息ID或事务ID），补偿服务检查该标识是否已处理，避免重复执行。
7) 【常见坑/雷区】
- 坑1：分布式事务补偿逻辑缺失，导致数据不一致。避免：设计明确的补偿任务，确保失败步骤能回滚，并实现幂等性。
- 坑2：缓存未设置过期策略，导致缓存雪崩。避免：Redis缓存热门岗位信息时设置过期时间（如5分钟），并采用分片缓存（按学校ID分片），避免单点雪崩。
- 坑3：权限校验未在服务间调用时执行，导致跨学校操作。避免：采用RBAC模型，服务间调用时添加权限校验，检查管理员所属学校与操作对象的学校是否一致。
- 坑4：消息队列未设计死信队列，导致消息丢失。避免：配置死信队列，处理无法消费的消息，避免通知丢失。
- 坑5：Saga事务边界模糊，导致补偿步骤混乱。避免：明确每个Saga的事务边界（如“岗位发布”和“更新学校岗位数”属于同一个Saga，步骤顺序为发布岗位→更新岗位数，补偿顺序相反）。