- 博客(32)
- 收藏
- 关注
RSS订阅原创 一次 MySQL 主从延迟引发的订单状态不一致故障复盘
订单明明已经支付成功了，为什么用户端还是显示待付款？2026年3月底，我们电商平台的客服系统突然涌入大量投诉，集中在“支付成功但订单状态未更新”。起初我们以为是前端缓存问题，但排查后发现：支付回调已正常写入数据库，订单状态字段也确实被更新为“已支付”，可用户在APP刷新后仍看到旧状态。更诡异的是，这种现象只出现在部分用户身上，且集中在高峰时段。我们立刻拉起了紧急故障群，开启了线上故障复盘流程。
2026-04-07 10:01:19
50
原创 一次电商订单履约压测复盘：从线程池满到异步解耦的性能破局
在 2026 年初的某次大促备战过程中，我们团队负责的订单履约系统面临一次严峻的性能挑战。业务方要求在 30 秒内完成 10 万笔订单的自动履约处理，包括库存校验、物流调度、状态更新等多个环节。压测初期，系统在 5 万 QPS 下直接出现线程池满、任务拒绝、响应延迟飙升的现象。本文将复盘这次性能压测的全过程，从业务目标出发，对比多种技术方案，最终落地一套基于消息队列异步解耦的优化架构，并分析其中的风险边界。
2026-04-06 16:00:40
337
原创 一次企业知识库同步系统改造复盘：从全量拉取到增量消息的演进与多级缓存一致性保障
2026 年 4 月 6 日凌晨 3:17，我们收到一条告警：知识库同步服务 CPU 飙升至 98%，同步任务积压超过 12 万条，下游 AI 助手响应延迟突破 8 秒。这不是第一次了——过去三个月，每逢周一早高峰或知识库批量更新后，这套系统总会“准时”崩溃。这不是性能问题，而是架构设计对业务增长缺乏前瞻性。今天，我们复盘这次系统改造的全过程：从业务压力倒推技术设计，从全量拉取到增量消息，再到多级缓存一致性保障，最终实现 99.95% 的同步成功率与毫秒级延迟。
2026-04-06 10:01:08
252
原创 一次电商秒杀系统架构评审：从本地锁到分布式锁的演进与取舍
2026年4月5日，某电商平台在备战618大促前夕，技术团队召开了一场关于秒杀系统架构升级的评审会。当前系统在高并发场景下频繁出现超卖问题，QPS峰值突破8000时，库存扣减错误率高达3.7%。业务方明确要求：在30天内完成架构改造，保证库存强一致性，同时将系统吞吐量提升至15000 QPS以上，且不允许引入新的中间件依赖（如ZooKeeper）。团队最初提出两套方案：方案A采用本地锁 + 数据库乐观锁，方案B采用Redis分布式锁 + Lua脚本原子扣减。
2026-04-05 16:00:47
335
原创 一次 ConcurrentHashMap 并发扩容源码走读：从错误使用到理解分段锁与 CAS 的协作机制
上周团队在优化一个高并发配置中心时，针对缓存选型爆发了一场激烈争论。一方主张：“直接用 ConcurrentHashMap，线程安全，性能好，JDK 自带，不用白不用。另一方反驳：“你们真的了解它的扩容机制吗？在高并发写入场景下，多个线程同时触发扩容，会不会导致 CPU 飙升甚至死循环？起初大家都认为这是“标准写法”，直到压测时发现：在 32 核机器上，随着线程数增加到 64，CPU 使用率从 30% 飙升至 95%，且吞吐量不升反降。日志中未见 OOM，但 GC 频率正常，线程堆栈显示大量线程卡在。
2026-04-05 10:01:03
333
原创 一次 Redis 热点 Key 引发的线上雪崩复盘：从缓存击穿到多级缓存架构的演进
2026 年 4 月 4 日凌晨 2:17，我们会员积分系统的核心接口响应时间从平均 80ms 飙升至 1.2s，QPS 下降 60%，告警短信像雪花一样涌进运维群。起初以为是数据库问题，但慢 SQL 监控毫无异常。直到有人喊了一句：“Redis 集群 CPU 打满了！”我们才意识到，这是一场由热点 Key 引发的缓存雪崩。
2026-04-04 16:00:17
322
原创 一次 Spring 循环依赖源码走读：从三级缓存误用到 Bean 生命周期深度解析
在团队最近一次架构评审会上，关于 Spring 循环依赖的处理方式爆发了一场激烈争论。“直接用 @Lazy 不就行了？” 小李拍着桌子说，“我上个月在订单服务里就这么干的，上线一点问题没有。“@Lazy 只是绕开问题，不是解决问题。” 架构师老张摇头，“如果两个核心 Bean 互相依赖，延迟加载会导致首次请求超时，用户体验直接崩掉。“那用 setter 注入？” 小王插话，“我看官方文档说构造器注入不支持循环依赖。
2026-04-04 10:01:49
370
原创 一次支付清结算系统线程池故障复盘：从任务积压到异步解耦的架构演进
凌晨三点，支付清结算系统的告警群突然炸响。「结算任务积压超过 50 万条，平均延迟 12 分钟，部分商户提现失败！值班群里迅速拉起应急响应。初步排查发现，核心结算处理线程池的队列已满，活跃线程数卡在，而实际并发任务数远超预期。更糟的是，由于任务阻塞时间过长，上游支付网关开始超时重试，进一步加剧了系统负载。这不是第一次出现类似问题。过去半年，每逢大促或节假日高峰，结算系统总会因线程池配置不合理导致任务积压。团队曾尝试调大和队列容量，但收效甚微，反而引发了更严重的内存压力和 GC 停顿。
2026-04-03 16:01:14
327
原创 一次 Spring 事务传播机制源码走读：从误用 @Transactional 到理解嵌套事务的边界
@Transactional 不是套个注解就万事大吉的！会议室里，小李指着白板上的一段代码，语气激动：“我们这个订单服务里，外层方法加了 @Transactional，内层又调了一个带 REQUIRES_NEW 的子方法，结果事务没回滚，数据不一致了！老王皱眉：“你是不是没看 Spring 的事务传播机制？REQUIRES_NEW 会挂起当前事务，新建一个，但如果你外层没正确处理异常，内层提交后外层回滚，那不就脏数据了？“我查了文档，说 REQUIRES_NEW 会独立提交啊……”
2026-04-03 10:02:05
178
原创 一次 Spring Boot 自动装配机制源码走读：从误用 @Component 到理解 Bean 生命周期
在团队最近的一次技术评审会上，关于是否应该在配置类中滥用@Component注解引发了激烈争论。一方认为“只要加了@Component，Spring 就能自动管理，省事又高效”；另一方则坚持“配置类就该用，否则可能引发 Bean 创建顺序错乱”。这场争论最终促使我们深入 Spring Boot 的自动装配源码，重新审视注解背后的设计逻辑与实际影响。本文将通过一次真实的配置误用案例，逐步拆解 Spring 的自动装配机制，从@Component与的差异出发，深入。
2026-04-02 16:00:46
464
原创 一次即时通讯消息推送压测复盘：从线程池满到异步化改造的性能破局
2026年4月2日，我们团队在准备一场大规模即时通讯系统的压力测试。目标是在50万在线用户、峰值每秒10万条消息的场景下，保证99.9%的消息延迟不超过500ms。压测初期，系统表现良好，但随着并发量逼近8万，监控大盘开始报警：线程池满、消息堆积、推送延迟飙升至5秒以上。我们迅速介入排查，发现核心瓶颈出现在消息推送模块的线程池配置上。以下是我们从现象到根因再到最终落地的完整复盘过程。
2026-04-02 10:01:29
373
原创 一次企业知识库同步架构走读：从全量拉取到增量消息的演进之路
在 2026 年初，我们团队接手了一个企业知识库同步系统的重构任务。该系统原本采用定时全量拉取方式，从多个业务系统（如 CRM、ERP、工单系统）同步文档到中央知识库。随着文档量级突破千万，全量同步耗时从最初的 30 分钟飙升至近 8 小时，严重影响了知识更新的实时性。在一次架构评审会上，团队对改造方案产生了激烈分歧。“直接用 Kafka 推消息不就行了？”后端负责人小李拍着桌子说，“每个系统发变更事件，知识库消费就行，简单粗暴！“但你怎么保证消息不丢？万一 Kafka 挂了，文档就永远同步不了。
2026-04-01 16:01:09
358
原创 一次会员积分系统改造复盘：从本地缓存到多级缓存的架构演进
2026 年 3 月底，我们团队收到一条来自业务侧的紧急反馈：会员积分查询接口在每日签到高峰时段（09:00–09:30）响应时间从平均 50ms 飙升至 800ms，部分用户甚至遭遇超时。更棘手的是，随着会员体系接入更多权益（如积分兑换、等级升级、活动抵扣），积分数据的读取频率呈指数级增长，原有的本地缓存架构已明显力不从心。这不是一个简单的性能问题，而是一次典型的“业务压力倒推技术重构”的案例。本文将从。
2026-04-01 10:00:42
553
原创 一次高并发推送压测复盘：从线程池阻塞到异步解耦的性能破局
综上，该方案在吞吐量、延迟、稳定性之间取得了良好平衡，适用于高并发、弱一致性要求的推送场景，但不适用于强顺序或强一致性业务。：服务重启时本地队列数据丢失，需结合 RocketMQ 的重试机制或引入持久化队列（如本地文件、Redis）。初始压测数据显示，在并发量达到每秒8000条时，系统出现明显瓶颈，平均延迟飙升至4.2秒，错误率高达12%。：异步化后无法保证消息顺序，若业务强依赖顺序（如聊天消息），需引入分区键或顺序队列。降级可能影响用户体验。落地建议：设置合理容量，配合监控告警，必要时引入持久化机制。
2026-03-31 16:00:41
524
原创 一次支付清结算系统架构评审：从强一致到最终一致的取舍之路
在金融系统中，一致性模型的选择必须权衡性能、复杂度与业务容忍度。强一致虽“正确”，但不一定“合适”。通过将同步阻塞转为异步解耦，并辅以对账兜底，我们实现了高可用与资金安全的平衡。未来将进一步探索Saga模式在长流程清结算中的应用，提升端到端可观测性。
2026-03-30 16:00:28
344
原创 一次线程池配置争议：从同步阻塞到异步解耦的架构演进
然而，架构师老王当场提出质疑：“这本质上是用线程池模拟消息队列，但缺乏持久化、重试机制和流量控制能力。前端调用接口后，直接提交任务到该线程池，等待执行完成返回结果。小李认为：“本地线程池足够轻量，无需引入 MQ，减少系统复杂度。小李试图通过调大线程池参数“临时救火”，但老王指出：“这不是参数问题，是架构选型错误。更严重的是，由于同步任务是同步调用，前端请求被阻塞，导致网关层连接耗尽，最终触发熔断机制，整个知识库服务不可用。初期方案会上，后端负责人小李提出了一个看似“稳妥”的设计：在主服务中直接使用。
2026-03-30 10:01:12
359
原创 一次企业知识库同步故障复盘：从全量拉取到增量推送的架构演进
凌晨三点，企业知识库的同步服务突然崩溃，监控大屏上积压消息数从 0 飙升至 12 万条。用户反馈知识库内容长时间未更新，客服工单激增。我们紧急上线临时扩容方案，但问题反复出现，直到第四天凌晨才彻底恢复。事后复盘发现，问题的根源不是性能瓶颈，而是我们对“同步”这一动作的理解存在严重偏差。我们最初的设计是：每天凌晨 2 点，知识库服务主动向内容源系统发起全量拉取请求，拉取所有文档的变更记录，然后逐条写入本地数据库。
2026-03-29 16:00:32
540
原创 一次电商大促压测复盘：从线程池满到异步解耦的性能破局
业务方要求在 5 月 1 日零点开启秒杀活动时，订单创建链路 P99 延迟控制在 200ms 以内，系统整体吞吐量需支撑每秒 1.2 万笔订单创建。我们尝试将 Tomcat 线程池从默认 200 扩到 500，数据库连接池从 50 扩到 150，并开启 MySQL 读写分离。：线程池和连接池只是“缓冲”，并未解决“同步阻塞”的本质。订单创建是 CPU + IO 密集型混合操作，线程池满了之后请求排队，反而加剧延迟。边界条件：分库分表后跨库查询复杂，需引入搜索引擎或数据同步方案。
2026-03-29 10:00:40
448
原创 一次订单履约系统压测复盘：从线程池阻塞到异步化改造的性能跃迁
压测初期结果显示：在每秒8000笔订单的峰值流量下，系统平均响应时间飙升至1.2秒，TP99高达3.5秒，线程池频繁满负荷，大量请求被拒绝。本次压测复盘表明，性能优化不能仅靠“堆资源”，更需从架构层面识别瓶颈，通过异步化、解耦、削峰等策略实现质的飞跃。上线后，系统在双11预热压测中表现稳定，TP99始终低于200ms，无消息丢失，异步链路平均处理延迟为45秒，符合业务预期。落地建议：选择高可靠MQ（如RocketMQ、Kafka），实现本地消息表或事务消息兜底，消费者加幂等校验，配合监控告警。
2026-03-28 16:02:19
445
原创 一次会员积分系统架构评审：从本地缓存到多级缓存的取舍之路
初期方案采用“本地缓存 + MySQL 主从”架构，上线后第 3 天即出现严重问题：积分查询平均响应时间飙升至 1.2 秒，数据库 CPU 持续 90% 以上，且出现多起积分余额不一致的客诉。此时，架构组紧急召开评审会，重新评估方案。此外，团队误以为“加锁能解决一致性问题”，在积分变更时对本地缓存加 synchronized，结果导致写性能骤降，TPS 从 1200 降至 400，反而加剧了系统瓶颈。原理：在更新数据库后，先删除缓存，再通过延迟消息二次删除，解决并发场景下“读旧写新”导致的脏读问题。
2026-03-28 10:00:30
338
原创 一次 MQ 消息积压故障复盘：从线程池配置陷阱到削峰填谷的架构演进
凌晨 2:17，监控大屏突然变红。订单履约系统的消息消费延迟从平时的 50ms 飙升至 12 秒，下游物流系统开始超时重试，客服工单激增。我们紧急拉了个故障群，第一反应是：“是不是 Redis 挂了？”但很快发现，Redis 正常，数据库负载平稳，MQ 生产端发送速率也稳定。真正的问题藏在我们自己写的消费逻辑里——一个看似无害的线程池配置，成了压垮系统的最后一根稻草。
2026-03-27 16:02:16
692
原创 一次 Redis 热点 Key 故障复盘：缓存雪崩如何击穿订单履约系统
凌晨 2:17，订单履约系统的告警突然炸响。监控大屏上，MySQL 的 QPS 从平时的 800 飙升至 12000，CPU 使用率突破 95%，大量订单状态更新请求超时。与此同时，Redis 集群的某个分片内存使用率在 30 秒内从 45% 暴涨到 98%，紧接着触发了 OOM 强制淘汰策略，缓存命中率从 99.6% 骤降至 18%。我们以为是缓存击穿，结果排查后发现，这是一场典型的“热点 Key + 缓存雪崩”复合型灾难。
2026-03-27 10:00:42
304
原创 一次支付清结算系统故障复盘：为什么加锁反而引发了更高频的死锁？
一致性不等于强锁。在支付清结算这类对准确性要求极高的场景中，我们更应关注事务边界、锁顺序与最终一致性的平衡。加锁是手段而非目的，真正的目标是构建一个既安全又高效的系统。下一次当你想加锁时，不妨先问一句：“锁的顺序是否全局一致？事务里有没有IO？
2026-03-26 16:00:54
687
原创 一次订单履约系统改造复盘：从全量同步到增量消息的架构演进
本次改造不仅是技术升级，更是思维模式的转变：从“被动响应”到“主动感知”。当系统能“听见”数据的变化，才能真正支撑业务的敏捷迭代。具体来说，就是将订单状态的变更通过消息队列（MQ）实时推送给履约系统，而不是定期去数据库“捞”一遍。实际上，全量扫描的时间复杂度是 O(n)，随着数据量线性增长，无论怎么加资源，最终都会触及物理极限。| 用“推”代替“拉”，实现低延迟、高解耦 | 认为 MQ 只是“更快的消息传递” |若当前状态 ≥ 消息中的状态（如已出库，消息是已支付），则直接 ACK，避免重复操作。
2026-03-26 10:00:39
828
原创 一次电商秒杀压测复盘：从 800ms 到 120ms 的链路优化实战
2026 年 3 月，我们团队负责支撑某电商平台「会员日秒杀」活动的技术保障。活动前一周，压测团队反馈核心下单接口平均响应时间高达 800ms，95 分位甚至突破 1.5s，远超出 200ms 的 SLA 要求。更棘手的是，在模拟 5000 QPS 的流量冲击下，MySQL 主库 CPU 飙升至 90%，Redis 缓存命中率骤降至 65%，多个服务出现线程池打满告警。
2026-03-25 16:00:52
571
原创 互联网大厂高阶Java面试现场：从Spring AI到分布式事务的极限拷问
2026年3月24日，杭州某互联网大厂会议室。空调恒温23℃，白板笔迹未干，面试官李工推了推眼镜，目光平静却带着审视。对面坐着坤哥，30岁出头，穿着一件略显宽松的格子衬衫，眼神里透着一股“我准备很久了”的笃定。“坤哥，先简单自我介绍一下吧。”李工语气平和，手指轻轻敲了敲桌面。“好的，李工。我叫坤，五年Java后端经验，目前在一家中厂负责订单系统架构。熟悉Spring生态、分布式事务、高并发设计，最近也在研究AI工程化落地，比如用Spring AI做知识库助手。李工点点头，翻开笔记本：“那我们从基础开始。
2026-03-24 16:00:49
324
原创 互联网大厂高阶 Java 面试现场：从 Spring AI 到分布式事务的深度拷问
面试官（资深架构师）：“坤哥，欢迎参加本次高阶 Java 面试。我们直接进入正题。首先，你在简历里提到了 Spring AI 在企业级私有知识库助手中的应用，能聊聊你是怎么落地的吗？坤哥：“好的，我们项目是一个基于 RAG（检索增强生成）架构的私有知识库助手，核心链路是用户提问 → 向量数据库检索 → LLM 生成答案。我们用 Spring AI 封装了 OpenAI 和本地模型的调用，通过@Document注解做文档切分，再用对接 Milvus 实现相似度搜索。面试官点头：“听起来流程清晰。
2026-03-24 10:37:52
400
原创 一场高阶Java面试的现场实录：并发原理到分布式设计
张工（收笔）：今天问题到这里，整体感觉你基础扎实，业务经验丰富，但部分底层陷阱需要再打磨。坤哥张工（微微一笑，站起）：“那你先回去等通知吧。坤哥心里明白，这句话意味着真正的挑战才刚刚开始。
2026-03-23 10:44:22
318
原创 互联网大厂高阶 Java 面试现场：多线程、分布式与性能的实战较量
源码重点：state 状态，FIFO 队列人性化管理阻塞/唤醒，CAS 保证并发安全。业务建议：可自定义同步器，避免过度锁竞争，提升可扩展性。风险提示：错误使用可能导致死锁，关注线程阻塞粒度。
2026-03-22 13:18:28
346
原创 Java面试八股文问答集——大厂必备含金量20题
Java内存模型定义了线程间如何通过内存交互，保证并发下的可见性和有序性。重载：同一类中方法名相同，参数不同。重写：子类对父类方法进行重新实现，方法签名相同。自动回收无用对象的内存，常见垃圾收集器有Serial、Parallel、G1等。在运行时动态获取类的信息，调用方法、访问字段。解决软件设计中常见问题的方案，常见的有单例、工厂、观察者、策略模式等。通过容器管理对象的依赖关系，降低耦合度。对象不再被使用，但由于仍有引用导致GC无法回收。
2026-03-17 22:01:29
208
原创 Spring Boot 3.x 集成 AI 智能体实战
本文介绍如何使用 Spring Boot 3.x 构建 AI 智能体应用，涵盖核心概念和详细实战步骤，帮助开发者快速上手智能体开发。
2026-03-17 21:54:16
44
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人