Java 后端开发工程师 · 上海 · 5 年经验
shenjiashu@example.com · 138 0000 0000 · github.com/shenjiashu
个人优势
- 5 年 Java 后端经验，负责过电商交易链路里的订单、库存和优惠券服务，经历过三次双 11 大促
- 熟悉高并发下的数据一致性：库存预扣 + 异步确认、本地消息表、TCC 补偿都在生产环境落地过，知道各自的适用边界
- MySQL 调优有实战：慢查询治理、分库分表迁移、在线加索引不锁表，千万级订单表的查询稳定在 50ms 以内
- 熟悉 Redis 和 RocketMQ 的常见坑：缓存击穿、热 key、消息重复与乱序，处理过因此引发的线上事故
- 排查线上问题有方法：Arthas 看调用耗时、jstack 定位线程阻塞、GC 日志调堆参数，Full GC 从每小时数次降到每天不到 1 次
- 写代码重视可测试性，核心服务单测覆盖率保持在 75% 以上，接口改动先补契约测试
- 技术栈：Java 17、Spring Boot、Spring Cloud Alibaba、MyBatis-Plus、MySQL、Redis、RocketMQ、Elasticsearch、Docker、Kubernetes、SkyWalking
工作经历
某跨境电商平台 · 高级 Java 开发工程师
交易中台组 12 人，支撑平台全部下单、支付和售后流程，日均订单约 60 万。我负责库存与优惠券两个服务，同时承担大促期间交易链路的值班负责人。
- 库存超卖治理：旧方案在下单时直接扣减数据库库存，大促峰值出现行锁等待和偶发超卖。改为 Redis 预扣 + 订单确认后异步落库，配合每日对账任务修正差异；大促峰值下单接口 P99 从 1.2 秒降到 280ms，当年大促零超卖
- 优惠券核销一致性：下单失败后优惠券偶尔不回退，每月产生约 200 张客诉。用本地消息表保证「订单取消」和「券回退」最终一致，补偿任务失败超过 3 次转人工处理；此类客诉降到每月个位数
- 订单表分库分表：单表超过 8000 万行，后台查询频繁超时。按用户 ID 分 16 库 64 表，迁移期间双写加数据比对，按商家分批切流，全程未停服；商家后台订单查询 P95 从 3 秒以上降到 400ms
- 大促保障：牵头梳理交易链路的 23 个依赖，给非核心依赖加熔断降级开关，组织两轮全链路压测；双 11 当天峰值 每秒 3200 单，核心接口可用性 99.99%
某本地生活公司 · Java 开发工程师
商户组 6 人，负责商户入驻、门店管理和结算对账。
- 重构商户结算对账流程：原来每天凌晨全量比对需要 4 小时，改为按渠道增量对账并行执行，耗时降到 35 分钟，对账差异当天可见
- 门店搜索从 MySQL 模糊查询迁到 Elasticsearch，支持按距离、品类和评分排序，搜索接口 P95 从 900ms 降到 120ms
- 接手一个没有测试的老结算模块，先补 160 个单测把现有行为固定下来，再拆分重构，上线后零资损
项目经历
交易链路全链路压测平台
Spring Boot / RocketMQ / MySQL 影子表 / SkyWalking
大促前的压测此前靠测试环境估算，和线上差距很大。平台目标是在生产环境用影子流量压测，不污染真实数据。
- 压测流量带标记透传到下游，数据库、缓存、消息分别路由到影子表、影子 key 和影子 topic；上线前用 50 条用例验证隔离，没有出现压测数据进入生产库
- 支持按真实流量比例回放和逐级加压，压测报告自动对比各接口的 RT 与错误率，定位出 4 个此前没发现的慢 SQL 和 1 个连接池瓶颈
- 平台在后续两次大促前各执行 3 轮压测，容量评估误差从过去的 40% 左右缩小到 10% 以内