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

一、引言 "我的应用明明启动成功了，为什么 K8s 一直把流量打过来又切走？" 相信很多同学在 K8s 部署 Spring Boot 应用时都遇到过这个问题。根本原因在于：健康检查配置不当。 想象一下这个场景： 应用启动需要 30 秒初始化数据库连接池、加载缓存 K8s 在启动后 5 秒就开始探测 readiness 由于初始化未完成，readiness 探针失败 K8s 认为 Pod 未就绪，将其从 Service 中移除 30 秒后应用初始化完成，但此时流量已经被分发到其他实例 这就是典型的探针配置与应用启动时间不匹配问题。 二、Spring Boot Actuator 健康检查体系 2.1 三个核心端点 Spring Boot Actuator 自带三个健康检查端点： # /actuator/health - 综合健康检查 # /actuator/health/liveness - 存活探针：应用本身是否正常运行 # /actuator/health/readiness - 就绪探针：是否准备好接收流量 关键区别： 端点作用失败后果检查内容 /actuator/h....

一、引言 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....

一、问题背景：分布式锁失效的隐患 在分布式系统中，分布式锁是保证数据一致性的重要手段。最常见的实现方式是基于 Redis 的分布式锁，通常设置一个过期时间来防止死锁。 然而，在实际生产环境中，我们遇到了这样的问题： 2024-01-15 10:30:15 ERROR - 订单处理异常：库存扣减成功，但订单状态更新失败 2024-01-15 10:30:15 WARN - 分布式锁已过期释放，其他线程获取了锁 2024-01-15 10:30:16 INFO - 另一个线程开始处理同一订单... 问题分析： 锁的过期时间设置为 30 秒 订单处理任务实际执行了 45 秒 锁在第 30 秒自动过期释放 其他线程获取锁并开始处理 前一个线程继续执行，导致数据不一致 这就是典型的分布式锁续约问题：长任务执行中途锁失效，引发并发安全问题。 二、核心概念：分布式锁与 WatchDog 机制 2.1 分布式锁的基本原理 ┌────────────────────────────────────────────────────────────────┐ │ Redis 分布式锁工作流程 │ ├....

一、问题背景：线上故障的惊魂时刻 某日下午，线上系统突然出现大量接口超时，错误日志显示： Could not get JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms. 更诡异的是：数据库服务器正常，网络连接正常，应用日志中却没有任何 SQL 执行超时。 这正是数据库连接池"假死"现象的典型特征。 二、核心概念：HikariCP 连接池机制 2.1 连接池工作原理 ┌────────────────────────────────────────────────────────────────┐ │ HikariCP 连接池架构 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 应用线程 │ │ │ │ │ ▼ │ │ ┌───....

一、问题背景：电商列表接口的性能瓶颈 某电商平台的商品列表接口响应时间突然从 100ms 飙升至 3 秒，用户体验急剧下降。排查发现： 慢查询日志：商品列表查询耗时超过 2.8 秒 EXPLAIN 分析：Extra 列显示 Using where; Using filesort 执行计划：虽然命中了索引，但存在大量回表操作 根因分析： 原始 SQL： SELECT id, name, price, category, status, created_at FROM products WHERE category = 'electronics' AND status = 1 ORDER BY created_at DESC LIMIT 10; 这条看似简单的查询存在两个严重问题： 回表查询：索引只包含 category 和 status，查询其他字段需要回到主键索引查找 文件排序：ORDER BY created_at 无法利用索引，导致额外的排序开销 二、核心概念：理解覆盖索引与回表 2.1 索引结构与回表机制 InnoDB 索引结构示意: ┌───────────────....

一、问题背景：Canal 同步的"黑洞效应" 你是否遇到过这样的场景： 使用 Canal 监听 MySQL binlog 同步数据到 Elasticsearch 系统运行一段时间后，发现 ES 中的数据与 MySQL 不一致 某些时间段的数据完全丢失，却找不到任何错误日志 这就是典型的binlog 位点跳跃问题。Canal 在解析 binlog 时，可能因为网络抖动、服务重启、位点记录失败等原因，跳过部分 binlog 事件，导致数据同步丢失。 真实案例：某电商平台使用 Canal 同步商品数据到 ES，在一次服务重启后发现最近2小时的商品库存更新丢失，导致用户看到的库存与实际库存不一致，造成了严重的业务损失。 二、核心概念：Canal 位点管理机制 2.1 Canal 位点存储方式 存储方式描述优点缺点适用场景 MetaStore内存存储性能高重启丢失测试环境 ZookeeperZK 存储可靠依赖 ZK生产环境 MySQL数据库存储可靠依赖 DB生产环境 File文件存储简单单节点小规模 2.2 位点跳跃的常见原因 ┌────────────────────────....

公司用本地消息表做分布式事务的最终一致性。订单库 INSERT 了订单，消息表 INSERT 了一条"待发送"记录。偶尔消息表 INSERT 失败报唯一键冲突——两个不同的服务实例生成了同样的消息 ID。订单已经入库了，消息没有入库，订单的状态就永远卡在"待发送"。对账的时候才发现有几十笔订单"消息未下发"。 问题出在 ID 生成方式上。他们用的是数据库自增 ID——但在分布式环境下，两个实例各写各的订单库，各自生成了相同的自增 ID（比如都是从 1 开始），然后在消息表里产生了冲突。 今天聊聊怎么用雪花算法生成全局唯一 ID，配合唯一索引做防重，让消息表的 INSERT 不再因为 ID 冲突而失败。 数据库自增 ID 为什么不行 本地消息表的标准做法是： 1. 订单库 INSERT 订单（ID=1001） 2. 消息表 INSERT 消息（msg_id=1001, 关联订单 1001） 3. 定时任务轮询消息表，发送消息 4. 发送成功 → UPDATE 消息状态 = SENT 但如果你有两个服务实例，各自的订单库都有自增 ID=1001。两条订单对应同一个 msg_id=10....

公司 K8s 每次发版都有几个 502。查了监控，规律很明显——总是在旧 Pod 被 kill 的那几秒。原来是 K8s 滚动更新的时候，先发 SIGTERM 给旧 Pod，然后立刻把流量切到新 Pod。但旧 Pod 上还有正在处理的请求——SIGTERM 一来，进程直接退，请求半途而废。前端就 502 了。 Spring Boot 2.3 以后支持优雅停机，但光配 server.shutdown=graceful 还不够。K8s 的流量切换和 Pod 停机之间有时间差——你得让 Pod 在被 kill 之前有足够时间把正在处理的请求跑完。 问题拆解：K8s 发版一分钟内发生了什么 K8s 滚动更新流程： T+0s 新 Pod 创建，等待就绪 T+5s 新 Pod Ready → 加入 Service Endpoint T+5s K8s 发 SIGTERM 给旧 Pod T+5s 旧 Pod 上的请求还在跑 → 但 Service 已经不分配新请求了 T+5s 旧 Pod 收到 SIGTERM → Spring 开始优雅停机 ├─ 不再接受新请求 ├─ 等待正在处理的请求完成（30....

做缓存系统的同学肯定都遇到过这个问题：某个热点 key 突然过期了，结果瞬间大量请求直接打到数据库上，导致数据库被打爆，服务雪崩。 我之前就遇到过这样一个案例：电商系统的商品详情页，某个人气商品正在秒杀，结果缓存刚好过期了。瞬间几万并发请求全部穿透到数据库，数据库 CPU 直接飙升到 100%，整个系统瘫痪了十几分钟。 这就是经典的"缓存击穿"问题，也叫"惊群效应"。今天我们就来聊聊如何防护这种问题。 缓存击穿的常见场景 1. 热点数据过期 热点数据特点： - 访问频率极高（每秒数万次） - 数据量大（商品信息、用户信息等） - 时效性要求高（需要定期更新） 问题： 当热点数据过期瞬间，所有请求同时发现缓存失效 所有请求同时去查询数据库 数据库无法承受瞬间压力，直接崩溃 2. 缓存击穿 vs 缓存穿透 vs 缓存雪崩 缓存三连击对比： ┌─────────────┬────────────────────────────────┬─────────────────────┐ │ 类型 │ 描述 │ 区别 │ ├─────────────┼───────────────────────....

做监控系统的同学肯定都遇到过这个问题：Prometheus 内存占用越来越高，监控面板加载越来越慢，最后甚至 OOM 崩溃。排查后发现，罪魁祸首居然是某个接口的 Label 值太多，导致指标基数爆炸。 我之前就遇到过这样一个案例：某个接口返回了用户 ID 作为 Label，结果线上有几百万活跃用户，这个 Label 的取值就有几百万种。单个指标瞬间膨胀到几百万个 time series，Prometheus 的内存和 CPU 直接被打爆。 今天我们就来聊聊 Prometheus 指标基数爆炸的问题，以及如何通过聚合采样方案来解决。 什么是指标基数爆炸？ 1. Prometheus 指标模型回顾 Prometheus 的指标由以下几个部分组成： 指标名称 + Label组合 = 唯一的time series 例如： api_request_total{method="GET", status="200", path="/users"} = 12345 api_request_total{method="POST", status="200", path="/orders"} = 6789....

在支付、转账等金融场景中，热点账户（如平台账户、商户账户）是最常见的性能瓶颈： 并发转账到同一账户，大量事务等待全局锁 Seata AT 模式的全局锁竞争激烈，性能断崖式下降 简单增加并发，反而导致吞吐量下降 全局锁超时导致事务回滚，用户体验极差 今天我们来聊一聊如何在 SpringBoot + Seata 中优化热点账户的锁冲突问题，通过乐观锁 + 本地队列的组合方案，让并发转账性能提升 10 倍。 为什么热点账户会成为瓶颈？ 先分析一下 Seata AT 模式的锁机制： 传统转账流程： ┌─────────────────────────────────────────────────────────────┐ │ 用户A → 转入平台账户(热点) → Seata 全局锁 │ │ 用户B → 转入平台账户(热点) → 等待锁释放 │ │ 用户C → 转入平台账户(热点) → 等待锁释放 │ │ │ │ 问题：所有转账都要竞争同一个全局锁，串行执行！ │ └─────────────────────────────────────────────────────────────┘....

在高并发场景下，消息发送的性能直接影响系统的整体吞吐量。传统单条消息发送模式存在以下问题： 每次发送都需要网络往返，RT（响应时间）高 broker 压力增大， TPS 上不去 服务器资源利用率低 RocketMQ 的批量发送和异步处理机制可以有效解决这些问题。本文将详细介绍如何在 SpringBoot 中实现 RocketMQ 异步批量发送优化，让生产端吞吐提升 5 倍，RT 降低 80%。 为什么需要批量发送？ 先看一下单条发送和批量发送的对比： 单条发送模式： ┌─────────────────────────────────────────────────────────────┐ │ Msg1 ──→ Broker ──→ ACK │ │ ↓ │ │ Msg2 ──→ Broker ──→ ACK │ │ ↓ │ │ Msg3 ──→ Broker ──→ ACK │ │ │ │ 3次网络往返，3次broker处理，RT = N × RTT │ └─────────────────────────────────────────────────────────────┘....

做过 IM 聊天、在线游戏、实时推送这类应用的都知道，WebSocket 连接稳定性是个大难题： 用户坐地铁过隧道，信号时断时续 App 切到后台，系统会杀掉 WebSocket 连接 公司网络需要认证，一断开就再也连不上 用户 Dormant 模式网络切换，IP 都变了 更头疼的是消息丢失问题： 用户发了一条消息，服务器还没收到就断线了 服务器推送的消息，客户端还没收到就断线了 重连后不知道哪些消息漏收了，只能全部同步 今天我们来聊聊 WebSocket 弱网环境下的保活机制，确保 App 在各种网络环境下都能保持连接，消息不丢失。 为什么 WebSocket 在弱网环境下这么脆弱？ 先来分析一下 WebSocket 连接断线的常见场景： 1. App 切后台 前台运行：WebSocket 保持连接 ←→ 服务器正常通信 ↓ 切到后台：系统可能 kill WebSocket 连接 ↓ 切回前台：需要重新建立连接，但之前的消息已经丢了 2. 网络切换 WiFi 连接：WebSocket 通过 IP1 建立连接 ↓ 切换到 4G：IP 变成 IP2，原有连接直接失效 ↓ 重连成....