归档

从一次支付状态建模说起 早些年写支付结果，我习惯用一个 enum 加一堆 if： enum PayStatus { SUCCESS, FAILED, PENDING, REFUNDED } void handle(PayStatus s) { if (s == SUCCESS) { ...

那个 3000 行的 Service 接手交易核心模块时，OrderService.java 有 3128 行，下了 47 个 @Autowired 的 DAO 和远程 client。任何一处改动我都得屏住呼吸。上周一个改下单幂等的小需求，回归测试就跑了三轮，改动 8 行、提心吊胆一整天。更糟的是，

一次奇怪的吞吐量瓶颈 大促前给订单流水 topic 扩分区，从 12 个加到 48 个，本以为吞吐能线性提升，结果生产端 P99 延迟不降反升，监控上看到 broker 端请求队列开始堆积。翻了半天才意识到：分区数过了拐点就是负担，不是越多越猛。 这事其实之前踩过一次。那回我们是 consumer

背景 上周联调一个订单状态机，本地用 Redis 做幂等缓存。单元测试里我习惯用 Mockito 把 RedisTemplate 整个 mock 掉，结果上线后在缓存过期那块直接炸了。mock 根本没覆盖 TTL 和原子自增的真实语义，自测全绿却带着隐患上了线。 复盘那次事故，根因是我们对"缓存是否

准备升级 Spring Security 6：配置风格全变了 Spring Security 6.0 要在 2022 年 11 月随 Spring Boot 3.0 一起 GA，但我们不想等上线了再手忙脚乱。10 月初我就拉了 6.0 的候选版本做预研，最大的冲击是：WebSecurityConfi

订单系统重构：一个"订单"对象膨胀到了 3000 行 我们老订单系统里有个 Order 类，承载了下单、改地址、退款、发票、物流查询……所有逻辑，文件 3000 多行，改一处怕动全身。重构时我用 DDD 的聚合（Aggregate）思想重新切分，核心问题其实就一个：聚合边界划在哪。划错了，要么事务跨

一段 SQL 在 Java 里换行，我存成了诡异的格式 前几天 Code Review，看到有人拼一条多行 SQL 用了老套路： String sql = "SELECT id, name, price FROM product " + "WHERE category = ? AND

缓存和数据库又双叒不一致了 我们的商品详情页用"先更新 DB，再删缓存"的策略。大多数时候没问题，但运营一次批量改价后，部分用户看到的价格还是旧的，持续了十几分钟。根因是并发下的时序问题：线程 A 更新 DB、还没删缓存时，线程 B 读了旧 DB 值并写回缓存，导致 A 的删除"删了个寂寞"，脏数据

提前迁移 Spring Boot 3.0：踩在 GA 前的准备 Spring Boot 3.0 要在 2022 年 11 月正式 GA，但我司有几个新服务打算直接基于 3.0 起项目，不想上线半年就面临大版本升级。于是我在 9 月就基于3.0 的里程碑/RC 候选版本做了一次迁移验证，把要改的点摸了

面试官问：100 万人抢 1000 件商品怎么设计 前阵子做架构分享，被同事用一道经典题考住："100 万并发抢 1000 件商品，怎么保证不超卖、系统还不挂？"这题看着老，但真要落地，每一层都有坑。我把我们实际做过的秒杀系统的设计要点拆开讲——不是教科书，是踩过坑的版本。 要点一：库存扣减，必须原