服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

一、引言 限流是高并发系统的核心保障手段。面对突发流量，如何选择合适的限流方案？ 今天我要对比三种主流限流方案：Guava RateLimiter（应用级令牌桶）、Sentinel（分布式滑动窗口）、Nginx limit_req（网关层漏桶）。通过真实压测数据，告诉你哪种方案最适合你的场景。 二、限流算法原理 2.1 三种算法对比 算法核心思想突发处理适用场景 令牌桶固定速率生成令牌，请求消耗令牌允许突发（桶内累积令牌）API 限流、削峰填谷 漏桶请求入队列，固定速率流出平滑输出，拒绝突发网关限流、流量整形 滑动窗口时间窗口内计数，动态调整精确控制，平滑过渡分布式限流、热点参数 2.2 算法图示 令牌桶算法 (Token Bucket) ┌──────────────────────────┐ │ 令牌桶 │ │ ┌──────────────────┐ │ │ │ ● ● ● ● ● ● ● ● │ │ │ │ (令牌) │ │ │ └──────────────────┘ │ │ ↓ 生成速率 = 1000/s │ │ │ │ 请求 → 取令牌 → 通过/拒绝 │ ....

一、引言 你是否厌倦了这样的代码？ public User getUserById(Long id) { try { User user = userRepository.findById(id); if (user == null) { throw new RuntimeException("用户不存在"); } return user; } catch (Exception e) { log.error("查询用户失败", e); throw new RuntimeException("系统错误"); } } 满屏的 try-catch 不仅丑陋，而且分散了业务逻辑的注意力。今天我要分享三种优雅的异常处理方式，让你的代码焕然一新。 二、方案一：@ControllerAdvice + @ExceptionHandler 2.1 全局异常统一处理 @ControllerAdvice public class GlobalExceptionHandler { private static final Logger log = LoggerFactory.getLogger(Globa....

一、引言 "我们还在用 Java 8"——这句话在 2026 年听起来已经有些过时了。 根据 JDK 支持周期，Java 17 的免费支持将在 2026 年底到期。如果你还在使用 Java 8 或 11，现在就是开始规划迁移的最佳时机。 本文将深入分析三个必须迁移的理由，并提供一份详尽的迁移检查清单。 二、理由一：安全合规红线 2.1 JDK 支持周期 JDK 版本发布时间免费支持截止长期支持 (LTS) Java 820142019 (Oracle) / 2030 (OpenJDK)✅ Java 1120182023 (Oracle) / 2026 (OpenJDK)✅ Java 1720212026 (Oracle) / 2029 (OpenJDK)✅ Java 2120232031 (预计)✅ 2.2 为什么现在必须行动 Oracle JDK 用户： Java 8：2019 年已停止免费更新，继续使用存在安全风险 Java 11：2023 年已停止免费更新 Java 17：2026 年底停止免费更新 OpenJDK 用户（Eclipse Temurin、Amaz....

一、引言 并发编程是后端面试的必考题，但很多开发者只是死记硬背答案，遇到深入追问就露馅了。今天我要拆解三个高频并发问题，不仅告诉你答案，更要讲清楚背后的原理。 核心观点：理解并发问题的关键在于从底层原理出发——线程池参数要结合业务场景，锁升级要理解对象头结构，伪共享要明白 CPU 缓存机制。 二、线程池参数：核心线程数到底怎么算？ 2.1 错误认知：CPU 核数 + 1 很多人背的答案是"CPU 核心数 + 1"，但这只适用于特定场景。线程池参数的设置需要结合任务类型来决定。 2.2 任务类型分类 任务类型特点典型场景 CPU 密集型任务主要消耗 CPU 资源，几乎不等待数据计算、排序、加密解密 IO 密集型任务大部分时间在等待 IO 操作数据库查询、网络请求、文件读写 混合型CPU 计算和 IO 操作都有Web 服务处理、API 网关 2.3 计算公式 CPU 密集型任务： 核心线程数 = CPU 核心数 + 1 理由：当一个线程被暂停（如页缺失），额外的一个线程可以利用这段时间继续执行，最大化 CPU 利用率。 IO 密集型任务： 核心线程数 = CPU 核心数 ×....

一、凌晨三点的告警 凌晨 03:15，手机突然震动。 【告警】服务 CPU 使用率达到 99.8% 实例：order-service-01 时间：2026-07-11 03:15:32 持续：已超过 5 分钟 我猛地从床上坐起来，打开笔记本电脑。凌晨三点，应该是定时任务在跑。登录到服务器，看到监控面板上 CPU 红线像心电图一样笔直。 问题已经发生了，现在需要冷静分析。 二、Arthas 排查：定位热线程 登录服务器，启动 Arthas： $ java -jar arthas-boot.jar * [1]: 12345 order-service.jar 选择进程 1，进入 Arthas 控制台。 2.1 dashboard：全局视图 $ dashboard ID NAME STATE %CPU TIME INTERRUPTED DAEMON 1 main RUNNABLE 0.0 0:01 false true 2 GC task thread#0 RUNNABLE 0.0 0:00 false true ... 25 pool-1-thread-1 BLOCKED 0.0 0....

一、引言 Spring Boot 提供了数百个注解，但大多数开发者只使用了其中的 10%。今天我要分享的这 3 个注解，虽然不是最热门的，但用好了能让你的代码更简洁、更优雅、更易维护。 核心观点：好的代码不是写得更多，而是写得更少——用最简洁的方式表达最复杂的逻辑。 二、@ConfigurationProperties：比 @Value 强 10 倍的配置绑定 2.1 问题场景 你是否写过这样的代码？ @RestController public class UserController { @Value("${app.user.default-page-size}") private int defaultPageSize; @Value("${app.user.max-page-size}") private int maxPageSize; @Value("${app.user.cache-enabled}") private boolean cacheEnabled; @Value("${app.user.cache-ttl-minutes}") private int cac....

一、引言 线程池是高并发场景下的核心组件，而拒绝策略则是线程池满载时的"安全阀"。很多开发者对四种拒绝策略的理解停留在理论层面，今天我们用真实数据说话，对比四种策略在相同压力下的表现。 测试条件： 核心线程：4 最大线程：8 队列容量：100 并发请求：200 任务耗时：模拟 100ms IO 操作 二、四种拒绝策略原理剖析 2.1 AbortPolicy（默认策略） 直接抛出 RejectedExecutionException 异常。 public static class AbortPolicy implements RejectedExecutionHandler { public AbortPolicy() {} public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { throw new RejectedExecutionException( "Task " + r.toString() + " rejected from " + e.toString()); } } 特点： 快速失败，吞吐量....

一、引言 大模型正在重塑软件开发方式。作为 Java 后端开发者，你是否想过用最少的代码将 AI 能力集成到自己的系统中？Spring AI 就是为此而生的——它提供了统一的 API 抽象，让你可以用几行代码接入 OpenAI、Anthropic、Google Gemini 等主流大模型。 核心观点：Spring AI 不是另一个 SDK，而是一种范式转变。它将 AI 能力视为 Spring 生态的一等公民，通过熟悉的依赖注入、配置绑定、条件装配等机制，让 AI 集成变得像使用任何其他 Spring 组件一样简单。 二、快速入门：15 行代码接入大模型 2.1 引入依赖 在 pom.xml 中添加 Spring AI OpenAI 启动器： <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-openai-spring-boot-starter</artifactId> <version>1.0.0</ver....

大促期间某热门商品 Key 被 80% 请求集中访问，单 Redis 节点 CPU 100%，拖垮整个集群。排查路径：监控告警 → 流量分析 → Redis slowlog → redis-cli --hotkeys 定位 → 发现 maxmemory-policy 配置错误加剧了问题。最终方案：Caffeine 本地缓存 + Redis 二级架构 + 热 Key 自动探测多副本分散 🚨 00:00 故障爆发 大促零点刚过，监控大屏突然变红。 [00:00:12] ALERT: Redis-Node-03 CPU使用率达99.8% [00:00:15] ALERT: API响应超时率突破50% [00:00:18] ALERT: Redis集群内存使用量快速下降 [00:00:22] ALERT: 订单服务POD重启 客服开始收到用户反馈"页面加载慢"、"下单失败"。运营同学在群里问："怎么回事？刚上线就崩了？" 🩹 00:15 应急止血 值班团队立刻响应： 限流降级：对热门商品接口实施临时限流，QPS从5000降到1000 缓存预热：紧急将热门商品数据加载到本地内存 节....

问题背景 在 Kubernetes 环境中，你是否遇到过这样的场景： Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10s default-scheduler Successfully assigned myapp-xxx to node-xxx Normal Pulling 9s kubelet Pulling image "myapp:latest" Normal Pulled 5s kubelet Successfully pulled image "myapp:latest" in 4.2s Normal Created 5s kubelet Created container myapp Normal Started 5s kubelet Started container myapp Warning Unhealthy 0s kubelet Liveness probe failed: HTTP probe failed with statuscode:....

问题背景 在高并发系统中，缓存是提升性能的关键手段。但你是否遇到过这样的场景： 10:00:00.000 [redis] Key "product:1001" expired 10:00:00.001 [http-1] Cache miss for "product:1001", querying DB... 10:00:00.002 [http-2] Cache miss for "product:1001", querying DB... 10:00:00.003 [http-3] Cache miss for "product:1001", querying DB... ... 10:00:00.100 [DB] Connection pool exhausted! 当一个热点 Key（如秒杀商品）过期的瞬间，大量请求同时穿透到数据库，导致数据库压力骤增，甚至宕机。这就是缓存击穿问题。 缓存击穿 vs 缓存穿透 vs 缓存雪崩 问题类型描述场景 缓存穿透查询不存在的数据，缓存和 DB 都查不到恶意攻击、错误参数 缓存击穿热点 Key 过期，大量请求同时访问秒杀商品、热门....

一、问题背景：日志成为性能瓶颈 在一次压测中，我们发现了一个令人惊讶的现象： 基准测试结果： - 无日志模式：QPS = 15000，平均响应时间 = 25ms - 有日志模式：QPS = 8000，平均响应时间 = 48ms - 日志开销占比：约 48% 的响应时间 进一步分析发现： 同步 IO 阻塞：日志写入磁盘是同步操作，业务线程必须等待写入完成 磁盘 IO 瓶颈：高并发下磁盘写入成为瓶颈 磁盘满风险：日志文件持续增长，磁盘满后应用直接崩溃 GC 压力：大量日志字符串对象导致频繁 GC 这就是典型的日志拖慢业务问题。 二、核心概念：Logback 日志架构 2.1 同步日志的问题 ┌────────────────────────────────────────────────────────────────┐ │ 同步日志执行流程 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 业务线程 │ │ │ │ │ │ log.info("用户下单: orderId=1001"....

问题背景 在微服务架构中，链路追踪是排查问题的关键手段。通过 TraceID，我们可以将分布式系统中各个服务的日志串联起来，还原完整的请求链路。然而，当业务代码中存在异步调用时，你可能会遇到这样的问题： 2024-01-15 10:00:00.001 [http-nio-8080-exec-1] INFO OrderService - [traceId=abc-123] 创建订单成功 2024-01-15 10:00:00.050 [async-thread-1] INFO PaymentService - [traceId=null] 支付处理中 2024-01-15 10:00:00.100 [async-thread-2] INFO NotifyService - [traceId=null] 发送通知 可以看到，主线程中有 TraceID，但在异步线程中丢失了。这导致我们无法将整个链路的日志关联起来，排查问题时只能看到零散的日志片段。 为什么会丢失？ ThreadLocal 局限：MDC 底层使用 ThreadLocal 存储 TraceID，而 ThreadLocal 的....

在社交 App中，用户上传的照片被发现带有 GPS 坐标。一名用户通过下载其他用户的照片、提取 EXIF 信息，精确定位到了对方的家庭住址。事情闹大后，安全团队紧急处理——所有已上传的照片都没做 EXIF 处理，相机拍出来的每一张照片都带着 GPS 经纬度、设备型号、拍摄时间。 用户上传一张照片，本以为分享的是美景，实际上暴露了坐标、手机型号、拍摄参数。今天聊聊怎么在上传环节自动剥离 EXIF 信息，同时处理好照片的旋转问题。 EXIF 里藏着什么 一张 iPhone 拍的照片，EXIF 里可能包含： GPS 经纬度（GPSLatitude / GPSLongitude）—— 精确到米 设备信息（Make / Model）—— "iPhone 15 Pro" 拍摄时间（DateTimeOriginal） 旋转方向（Orientation）—— 手机横拍还是竖拍 前三个是隐私问题。最后一个是显示问题——手机竖着拍的照片，在电脑上可能横着显示，因为 Orientation 标记了旋转角度，但不是所有看图软件都会正确解析。 剥离 EXIF：转码后重新输出 最简单的方法：把图片用 I....

公司用 LibreOffice 做 Office 文件的在线预览——把 Word/Excel/PPT 转成 PDF，前端用 PDF.js 展示。平时用着没问题，但每个月财务批量导出报表的时候，几十个人同时点预览。LibreOffice 进程 fork 了十几个，其中一个转一个 50MB 的 Excel 文件卡了 10 分钟。这个卡住的进程占着 CPU 不干活，后面排队的请求全堵住了。运维 ssh 上去 kill -9 才恢复。 LibreOffice 的 --headless 模式是为单次使用设计的，不是为高并发设计的。今天聊聊怎么用 Docker 容器隔离每个转换任务、超时强杀、再加一个队列缓冲——让文件预览服务从"一卡俱卡"变成"各管各的"。 问题：共享的 LibreOffice 进程没有隔离 最简单的预览方案是在服务器上直接调 LibreOffice： soffice --headless --convert-to pdf input.docx 第一次调会 fork 一个 LibreOffice 后台进程。后续调用如果这个进程还在，就复用。如果这个进程卡死了——比如遇到了一....