程序员简历（后端开发工程师）范文

Java（主力，5 年）、Spring Boot / Spring Cloud、MyBatis；Go 可读可改（团队部分网关服务）。

MySQL（分库分表、索引与执行计划分析、慢查询治理）、Redis（缓存一致性、分布式锁、热点 key 处理）、Kafka（顺序消费与积压处理）、Elasticsearch。

分布式事务（本地消息表、TCC 各落地过一次）、限流降级（Sentinel）、幂等设计、灰度发布；能独立完成容量评估与压测方案。

Docker、Kubernetes（应用侧）、Jenkins、Arthas 与 JFR 线上诊断；熟悉 Prometheus + Grafana 监控与告警配置。

负责订单中心的核心链路，团队 7 人，我负责下单与状态机两个模块。

主要产出：

• 主导订单表分库分表改造：单表 8.2 亿行拆为 64 库 × 32 表，采用双写 + 数据校验 + 灰度切读的方式，历时 3 个月零故障完成；改造后核心查询 P99 从 1.4s 降到 120ms
• 重构订单状态机：把散落在 14 处的状态判断收敛为一张状态转移表，上线后状态相关的线上问题从月均 6 起降到 0-1 起
• 处理一次 P1 故障（详见项目经历），并推动建立了消息积压的分级告警
• 参与技术方案评审约 40 次，负责新人 2 名的入职带教

负责商品与库存服务，日均请求约 3000 万。

主要产出：

• 库存扣减从数据库行锁改为 Redis 预扣 + 异步落库，超卖问题清零，峰值处理能力从 1200 TPS 提升到 9000 TPS
• 治理慢查询：梳理 Top 50 慢 SQL 并逐条优化，数据库 CPU 峰值使用率从 85% 降到 42%
• 编写内部《库存服务接入规范》，此后接入方联调时间从平均 3 天缩短到 1 天

背景：单表 8.2 亿行，核心查询 P99 已到 1.4s，且每月增长约 4000 万行。

方案与取舍：

• 分片键选「用户 ID」而非「订单 ID」：C 端查询 92% 带用户 ID，按订单 ID 分片会让用户订单列表变成全库扫描；代价是运营侧按订单号查询要走 ES 索引，这部分单独做了同步链路
• 迁移用双写 + 全量校验 + 按用户尾号灰度切读，每个阶段留 3 天观察期；准备了随时可切回的开关
• 历史数据迁移 8.2 亿行，用分批限速的方式在业务低峰执行，未影响线上

结果：核心查询 P99 1.4s→120ms，写入 TPS 上限从 4000 提升到 3.2 万；改造期间零故障、零数据不一致。

现象：某日晚高峰订单状态更新延迟从秒级涨到 20 分钟以上，客服工单激增。

定位：

• 先排除数据库与应用负载（均正常），从 Kafka 消费位点发现某个分区积压 260 万条
• 用 Arthas 抓取消费线程栈，发现卡在一个下游 HTTP 调用上，该调用未设置读超时
• 根因：下游服务当天变更后偶发响应挂起，我方消费线程被逐个占满，而顺序消费导致整个分区停摆

处理与防线：

• 当晚：加读超时 + 熔断，30 分钟内积压消化完毕
• 之后：全量排查出 17 处缺少超时配置的外部调用并统一整改；补上消费积压的分级告警（1 万条预警、10 万条电话告警）；把「外部调用必须设超时」写进代码评审检查项
• 该类故障此后 12 个月未再发生

加权 86.3/100；ACM 校赛二等奖。

基于 Redis 的滑动窗口限流，支持多维度规则热更新；已被 3 个外部项目引入（issue 中可见）。

主要修复消费端的位点提交边界问题，其中 1 个 PR 被列入版本发布说明。

主题集中在分库分表落地与线上问题定位，其中 2 篇被技术社区首页推荐。