STAR 法则与项目描述

STAR 法则

STAR 是结构化描述项目/经历的黄金框架：

项目描述模板

❌ 普通描述（避免这样说）

“我负责开发了一个电商系统，使用 Go + MySQL + Redis 实现了用户下单、支付等功能。”

✅ STAR 描述（这样说更有力）

S：公司电商平台在大促期间（双11）QPS 峰值达 5 万，原有 PHP 单体架构响应时间超过 3 秒，频繁触发超时。

T：我负责核心交易链路的重构，目标是将 P99 延迟降低到 200ms 以内，同时保证数据一致性。

A：

1. 将下单服务拆分为独立微服务，使用 Go 重写，引入异步消息队列（Kafka）削峰
2. 使用 Redis 缓存商品库存，通过 Lua 脚本保证扣减的原子性
3. 引入分布式锁防止超卖，使用数据库乐观锁做兜底

R：P99 延迟从 3s 降低到 180ms，大促零超卖事故，系统稳定支撑 5 万 QPS。

高频追问与应对

Q: 你们为什么选择 Go 而不是 Java？

参考回答框架：

1. 性能：Go 的协程模型在高并发场景下内存占用更低
2. 部署：编译为单二进制，容器镜像更小（50MB vs 500MB）
3. 团队：团队有 Go 基础，上手成本低
4. 生态：gRPC 原生支持好，适合微服务场景

Q: 如何保证接口幂等性？

方案一：Token 机制
  客户端生成唯一 token → 服务端 Redis SET NX 判断 → 处理完删除

方案二：数据库唯一索引
  订单号设唯一索引 → 重复请求直接报 Duplicate Key

方案三：状态机
  检查业务状态 → 已处理则直接返回成功

Q: 分布式事务怎么处理？