Sprint · Chapter 1 · 简历项目辩护

复习难度：⭐⭐⭐⭐ | 预计时长：3小时 | 重点程度：极高

核心原则

简历上的每个字，都能讲5分钟。
每个设计决策，都能说出"为什么选它，trade-off是什么"。

STAR法则：
  Situation：背景是什么
  Task：我负责什么
  Action：我做了什么具体技术动作
  Result：带来了什么量化结果

项目1：企业审批平台

必须讲清楚的技术决策

① 为什么需要规则引擎？

背景：接入20+业务系统，每个系统审批逻辑不同（金额门槛、部门层级、节假日特殊规则） 方案：规则引擎（条件+动作），运营人员可配置，不用改代码 Trade-off：引入复杂度，学习成本；收益：新增审批规则无需发版

② 抢签场景的并发问题如何解决？

方案：Redis Redsync 分布式锁，保证同一时间只有一个人能签 为什么用 Redis 而不是 DB 锁：性能，DB 锁在5000并发下会成为瓶颈 竞态处理：锁过期 + 状态校验，锁住时状态为 PENDING，抢到锁的人才更新

③ 为什么引入 Kafka 而不是直接HTTP回调？

背景：20+业务系统订阅审批结果，HTTP强依赖 方案：Kafka 解耦，审批完成后发消息，业务系统异步接收 Trade-off：引入MQ运维成本；收益：业务系统解耦，审批服务不依赖下游

④ 如何实现全局时效 + 部分时效 + 自定义时效？

三层时效： 全局：整个流程超时时间 部分：单个审批节点超时 自定义：特殊情况下动态调整超时 技术：定时任务扫描 + Redis 缓存时效配置 + 事件驱动触发催办

量化结果要能背出来

- 接入20+业务系统，服务5000+员工
- 累计处理审批单57万+
- 版本迭代20+，0次生产事故
- AI提效：Claude Code分析复杂分支逻辑，测试用例生成效率提升60%

项目2：IAM 统一身份权限系统

必须讲清楚的技术决策

① 为什么要双轨 RBAC（功能型+数据型）？

背景：不同业务线需要差异化数据权限（只看本部门/本公司/全公司） 方案：功能角色（能做啥）+ 数据角色（能看谁的数据）分开绑定 解决：多租户差异化 + 人员与机器账号分离

② 深度分页从4-7s优化到<100ms，怎么做的？

问题根因：OFFSET 100000 时，MySQL 要先扫描前10万行再丢弃 方案：游标分页（Search After / 上一页最后ID）+ 覆盖索引 Trade-off：只能跳页，不能跳到任意页；收益：用户体验可接受

③ 批量查询内存从250MB降到10MB

问题根因：一次查出所有数据加载到内存 方案：分批处理（500/批）+ 游标遍历 Trade-off：代码复杂度增加；收益：内存稳定，不会OOM

④ 为什么选 gRPC-Gateway 而不是 REST？

背景：内部服务间需要高性能RPC，外部需要HTTP接口 方案：gRPC-Gateway 同时暴露 HTTP 和 gRPC 两种接口 Trade-off：调试不如 REST 方便；收益：内部高性能+外部可访问

项目3：魔兽争霸活动系统

百万级零差错的秘密

技术实现：
  1. 幂等表：每个用户每个活动只有一条记录（UNIQUE KEY）
  2. 事务保证：活动参与 + 记录创建在同一个DB事务
  3. 异步补偿：Kafka消费失败 → 定时任务扫描未完成记录 → 重试
  4. 日终对账：统计"应发/实发/差异"，差异告警

这个经验可以直接迁移到任何"奖励/积分/货币"发放场景。

项目4：直播平台账号绑定

高并发优化

背景：活动PV 500w+，UV 117w+，一周内150w+账户绑定
优化点：
  1. Redis 缓存活动配置（避免每次查DB）
  2. 页面响应速度提升50%（缓存热点数据）
  3. 限流：活动接口接入层限流，防止刷接口

必问的通用问题

Q：你在这个项目里遇到的最大技术挑战是什么？

准备一个具体的例子： - 审批平台的规则引擎设计与实现 - IAM深度分页优化 - 分布式锁的选型和踩坑

Q：你怎么保证代码质量？

Q：有没有推动过技术改进？