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

一、问题背景：JWT 的 CSRF 隐患 你是否认为使用 JWT 就天然安全？实际上，JWT 在某些场景下依然存在 CSRF 风险！ 当 JWT 存储在 Cookie 中（尤其是 HttpOnly=false 的情况），攻击者可以通过以下方式发起 CSRF 攻击： 用户登录你的网站，服务器返回 JWT 并存放在 Cookie 中 攻击者诱导用户访问恶意网站 恶意网站发起对目标网站的请求（如转账、修改密码） 浏览器自动携带 Cookie 中的 JWT，请求成功执行 真实案例：某电商平台的支付接口使用 JWT 认证，但未做 CSRF 防护。攻击者通过构造恶意页面，诱导用户点击后成功发起支付请求，造成用户资金损失。 二、核心概念：CSRF 与 JWT 的博弈 2.1 CSRF 攻击原理 ┌──────────────────────────────────────────────────────────────────┐ │ CSRF 攻击流程 │ ├──────────────────────────────────────────────────────────────────┤ ....

一、问题背景：权限缓存的"脏数据"困境 你是否遇到过这样的场景： 管理员在后台修改了某个用户的角色权限 用户重新登录后发现权限没有变化 只有重启服务或等待缓存过期，权限才会生效 这就是典型的权限缓存一致性问题。为了提高系统性能，我们通常会将用户权限信息缓存到本地，但当管理员修改权限后，其他节点的缓存并不会自动更新，导致用户获取到过期的权限数据。 真实案例：某电商平台在大促期间，管理员紧急调整了部分运营人员的权限，但由于缓存未及时刷新，导致权限变更延迟生效，影响了订单处理效率。 二、核心概念：缓存一致性模型 2.1 缓存更新策略对比 策略描述优点缺点适用场景 Cache-Aside先更新数据库，再删除缓存简单存在竞态条件读多写少 Write-Through同时更新缓存和数据库一致性好写入性能低一致性要求高 Write-Behind先写缓存，异步写数据库写入性能高数据可能丢失允许最终一致性 Event-Based事件驱动更新缓存解耦性好实现复杂分布式系统 2.2 事件总线架构 ┌───────────────────────────────────────────────....

一、问题背景：线程池耗尽的"死亡螺旋" 你是否遇到过这样的场景：系统使用 @Async 异步执行任务，在流量高峰期突然出现大量请求超时，最终导致整个服务不可用？ 这很可能是 Future.get() 阻塞导致的线程池雪崩。当异步任务的处理速度跟不上请求速度时，任务会在队列中堆积，而调用线程在 Future.get() 处阻塞等待，最终导致调用线程也被耗尽。 // 危险的异步调用方式 @Async public CompletableFuture<String> doAsyncTask() { // 执行耗时操作... } // 调用方 public void process() { CompletableFuture<String> future = asyncService.doAsyncTask(); String result = future.get(); // 阻塞等待，可能导致线程耗尽 } 真实案例：某支付系统在双十一期间，异步对账任务因数据库慢查询导致处理延迟，调用线程在 Future.get() 处阻塞，最终导致 Tomcat 线程池被占满，新....

一、问题背景：日志数据的"熵增困境" 你是否遇到过这样的场景：系统运行一段时间后，任务执行日志表的数据量达到数十亿条，导致： 查询变慢：简单的日志查询需要数秒甚至数分钟 存储成本飙升：SSD 存储费用持续增长 备份困难：全量备份耗时过长 DDL 操作阻塞：添加索引或修改表结构需要长时间锁表 这就是典型的历史数据膨胀问题。任务执行日志通常具有"写多读少"的特点，超过90%的日志数据写入后很少被访问，但却占用着宝贵的存储资源和查询性能。 二、核心概念：冷热数据分离原理 2.1 数据生命周期模型 ┌──────────────────────────────────────────────────────────────────┐ │ 数据生命周期 │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ 热数据 ──► 温数据 ──► 冷数据 ──► 归档数据 ──► 删除 │ │ (7天) (30天) (90天) (365天) │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ │ ....

公司的后台管理有一个搜索功能，搜订单备注里的关键词。刚开始数据量小，MySQL 的 LIKE '%keyword%' 还能跑。后来订单涨到几百万条，一个模糊搜索要跑 8 秒。更倒霉的是，这个搜索请求直接打在主库上——索引走不了，全表扫描，CPU 飙到 90%，其他正常业务也跟着慢。 LIKE '%xxx%' 是数据库的噩梦。前导通配符导致索引完全失效，只能全表扫描。MySQL 虽然也有 FULLTEXT 索引，但中文分词烂、不支持复杂排序、而且仍然在主库上消耗资源。 今天聊聊怎么用 Canal 把 MySQL 的数据实时同步到 Elasticsearch，把搜索的活从主库彻底拆出来。 架构：主库只管写，搜索交给 ES MySQL（主库） Elasticsearch │ │ │ INSERT/UPDATE/DELETE │ ├──── Canal 监听 binlog ──────────→├─ 增量同步 │ │ │ 业务读写 │ 全文搜索 │ （走主库） │ （走 ES） Canal 伪装成 MySQL 的 Slave，订阅 binlog 的变更事件。任何 INSERT、UPDAT....

一、问题背景：定时任务的"多米诺骨牌效应" 你是否遇到过这样的场景：线上运行着多个定时任务，其中一个任务因为外部服务超时、数据库慢查询或死循环而卡住，导致整个调度器线程池被占满，其他所有定时任务都无法按时执行？ 这就是典型的线程池饥饿问题。Spring 的 @Scheduled 默认使用单线程调度器，所有任务共用一个线程。一旦某个任务阻塞，后续任务都会排队等待，形成"多米诺骨牌效应"。 // 默认的单线程调度器 - 危险！ @Configuration @EnableScheduling public class SchedulerConfig { // 所有 @Scheduled 任务共用这个单线程 } 真实案例：某电商平台在大促期间，库存同步任务因数据库慢查询卡住，导致订单统计、报表生成等关键任务全部延迟，最终影响了实时数据展示。 二、核心概念：线程池隔离原理 线程池隔离的核心思想是：将不同类型、不同重要程度的定时任务分配到独立的线程池中执行，避免相互影响。 隔离策略对比 策略描述适用场景 按业务类型隔离不同业务域使用独立线程池订单、库存、用户等不同业务模块 按重要性隔....

朋友公司的 Redis 集群监控上 used_memory 才 4GB，但 used_memory_rss 已经到了 8GB——是 used 的两倍。运维加了内存，过两个月又一样。最离谱的是有一次 used_memory 只有 2GB，Redis 却报了 OOM。排查发现内存碎片率 3.5，8GB 的物理内存被碎片占了一半多。 这就是 Redis 的内存碎片问题。used_memory 是你存进去的有用数据，used_memory_rss 是 Redis 实际向操作系统申请的内存。两者之间的差，就是碎片。 今天聊聊怎么用 Redis 自带的内存碎片整理和对象复用，把碎片率降到 1.1 以下。 碎片怎么来的 Redis 的内存分配是 jemalloc 管理的。当你反复写入和删除不同大小的 Key，就会出现这样的场景： 内存布局（简化）： |AAAA| 空闲 |BB| 空闲 |CCCC| 空闲 |DD| 空闲 |... 删掉的 Key 留下的空隙不够大，放不下新的 Key。新 Key 只能往后申请新内存。结果就是 used 没涨多少，rss 一直涨。 碎片率计算公式： mem_fra....

朋友公司大促期间，数据库连接池突然打满。所有需要数据库的请求都排队等连接，connection-timeout 设了 30 秒——等了 30 秒拿到连接的人还得用，30 秒拿不到的人直接报错。问题是那些等了 28 秒终于拿到连接的人，数据库早已经被前面的人压垮了，拿到连接也没用。400 个请求同时排队，300 个超时报错，100 个拿到连接但数据库响应时间从 5ms 飚到 500ms。 这不是数据库的问题，是连接池在突发流量面前没有自保能力。今天聊聊怎么用动态扩容和排队熔断，让连接池在洪峰到来时不崩溃。 问题：连接池是漏斗，不是水坝 连接池的设计初衷是"复用连接，避免频繁建连"。但它有一个致命假设：总有空闲连接可用。 突发流量一来，连接瞬间打满，后续请求只能排队。排队的请求占着 Tomcat 线程，Tomcat 线程也满了——连锁反应。 请求 → 连接池 → 没空连接 → 排队等 ↓ 排队占着 Tomcat 线程 ↓ Tomcat 线程池也满了 ↓ 新请求直接被拒 ↓ 整个服务不可用 连接池从"漏斗"变成了"堵点"。 方案一：动态扩容，峰值时多借几个连接 HikariCP 的 ....

公司的支付系统出了个大事故。一笔订单因为网络抖动，支付回调超时了，系统重试了扣款。结果扣了两笔——用户投诉，财务对账发现了差异，运营逐笔人工退款。查日志发现，不是网络不通，是"半通"——第一次扣款请求发出去了，银联处理成功了，但响应在回来的路上丢了。系统认为扣款失败，又发了一次。 这种"网络半通"是分布式系统里最危险的情况——操作已经执行了，但调用方不知道。不加重试怕丢，加多了怕重。今天聊聊怎么用业务流水号加状态机，让重试在"安全"的边界内进行。 问题的本质：操作不是天然幂等的 HTTP 的 POST 不是幂等的，数据库的 INSERT 不是幂等的，银行的扣款接口更不是幂等的。如果不做任何处理，同一个扣款请求发两次，钱就会扣两笔。 分布式系统里有太多场景需要重试——网络抖动、超时、服务暂时不可用。重试本身是合理的，问题在于你拿什么来判断"这次重试的请求，上一次有没有已经成功过了"。 答案就是业务流水号。不是数据库自增 ID，不是 UUID，而是一个由业务方生成、全链路唯一、可用来判断"这条请求我见没见过"的标识。 业务流水号：请求的唯一身份证 业务流水号的核心原则：由发起方生成，....

朋友公司的订单系统连了两个库——订单库和库存库。一笔订单创建需要在订单库 INSERT、在库存库 UPDATE，同一个事务里跨两库操作。高峰期出现了死锁：事务 A 锁了订单表的行等库存表的锁，事务 B 锁了库存表的行等订单表的锁。两个事务互相等待，40 秒后被 MySQL 的 innodb_lock_wait_timeout 强杀。问题是强杀后抛出的异常只说了"锁等待超时"，没说是谁锁了谁——运维排查不到哪个事务导致了死锁。 单库死锁 MySQL 自己能检测和回滚，跨库死锁 MySQL 管不了——因为在它看来就是两个独立的事务各等各的。今天聊聊怎么在应用层做跨库死锁检测，并配合智能重试自动恢复。 跨库死锁是怎么发生的 单库死锁 MySQL 的 InnoDB 引擎自己就能处理：检测到环 → 选一个代价最小的回滚。但跨两个库的时候，场景是这样的： 事务 A: 事务 B: BEGIN BEGIN UPDATE orders SET ... UPDATE inventory SET ... WHERE id=1001 WHERE sku='XYZ' （锁住订单库的行） （锁住库存库的行） ....

公司用 Nacos 做配置中心，Gateway 路由也放 Nacos 里动态刷新。运维改了一条路由规则，配置一刷新，Gateway 就开始间歇性 502——大概持续了 2 到 3 秒。排查发现是路由表在热更新的时候，旧的被清空了、新的还没加载完，中间有一个空窗期。请求进来找不到路由，全部 502。 热更新本来是为了不重启，结果还是搞出了服务中断。问题不在热更新本身，而在更新的姿势不对——路由表是"先清空再加载"而不是"先准备好再切换"。今天聊聊怎么用双缓冲让路由切换做到真正的零宕机。 问题出在哪里：单路由表的空窗期 Spring Cloud Gateway 的 RouteDefinitionRouteLocator 在接收到 Nacos 配置变更时，默认行为是： 收到新配置 │ ├─ 清空旧路由表 ├─ 逐条解析新路由 ├─ 校验路由合法性 └─ 加载完成 从"清空"到"加载完成"之间，路由表是空的。这段时间进来的请求，全部 502。加载几十条路由可能只要 100ms，但如果路由规则复杂、或者有外部依赖校验，这个窗口可能拉到秒级。 双缓冲：新路由加载完再切过去 双缓冲的思路很朴素....

公司用本地消息表做分布式事务的最终一致性。每笔订单创建后往消息表里插一条"待发送"记录，后台定时任务轮询发送。业务量上来以后，消息表单表积压了几千万条数据，每次 INSERT 都要等几十毫秒，DB 连接池打满，主库 CPU 飙到 80%。订单创建都跟着变慢了。 本地消息表本来是为了解耦，结果自己成了瓶颈。今天聊聊怎么把消息表的高频写入从主库的业务路径上剥离，用异步批量落盘加分表来扛住海量消息。 问题到底出在哪 本地消息表最朴素的实现是业务代码里直接 INSERT： @Transactional public void createOrder(Order order) { orderMapper.insert(order); // 订单入库 messageMapper.insert(new Message( // 消息入库 —— 跟订单在同一个事务 order.getId(), "ORDER_CREATED", "PENDING" )); } 这种写法，消息的 INSERT 跟业务 SQL 在同一个事务里。单看一条没问题，但当每秒几千个订单同时创建，消息表的 INSERT 就变成了主....

公司微服务上了 Spring Cloud Gateway，一切正常直到有一天运维发现某个下游服务挂了，Gateway 还是把流量往那台死掉的实例上发，前端一阵 502。查了注册中心，Nacos 上那台实例的状态还是 UP。原来是服务进程虽然活着，但业务线程池被耗尽了，所有请求都在排队超时。Nacos 的心跳包是单独的线程处理的，业务线程池死了不影���心跳，所以注册中心一直认为它是健康的。 这就是"假在线"——健康检查过了不代表服务能用。今天聊聊怎么在 Gateway 层做主动业务探测，把假在线的节点从路由表里动态踢出去。 注册中心健康检查的盲区 Nacos、Eureka 这些注册中心判断服务是否健康，靠的是心跳。客户端定期发一个心跳包给注册中心，注册中心收到了就认为服务活着。 但心跳包只能证明网络没断、进程没死。以下场景心跳都是正常的： 业务线程池打满，所有请求都在排队超时 数据库连接池耗尽，每次数据库查询都失败 依赖的下游全挂了，返回的全是 500 死锁，只有心跳线程还在工作 这些情况下，注册中心说服务是 UP，Gateway 就把流量发过去，结果全是 502 或 500。 ....

公司线上出了个支付异常，三四个微服务都有日志，但各打各的，谁也不知道哪条日志和哪条日志是同一个请求。运维在 ELK 里翻了一个小时，靠着时间戳和 userId 硬猜，最后猜错了版本，回滚到错误的代码上又出了一波事故。要是每条日志头上都有一个贯穿全链路的请求 ID，一秒就能搜出这个请求的完整轨迹。 X-Request-ID 不是什么新技术，但落地起来细节不少。谁生成、怎么传、下游怎么接、日志怎么打，任何一个环节断了，链路就断了。今天把这些细节串起来。 谁负责生成 Request ID 生成责任只有一个：第一个接收到请求的网关。 客户端不生成，因为你不能信任客户端传上来的值——重复、太短、甚至包含注入字符。 如果客户端已经传了 X-Request-ID（比如从另一个系统透传过来的），网关应当尊重它，直接转发。但如果客户端没传，网关必须生成一个。 请求到达 Gateway │ ├─ 检查 Header: X-Request-ID │ ├─ 有值 → 直接用（跨系统透传） │ └─ 没值 → 生成新 ID │ └─ 写入 Header → 转发到下游微服务 ID 格式建议用 UUID 去横....

公司的在线客服系统用的是 WebSocket。每次发版滚动更新，旧 Pod 一停，挂在上面的几千个 WebSocket 连接全断。前端虽然做了自动重连，但重连期间用户发了一条消息，没收到回复，以为客服不理他，直接给了差评。更糟糕的是，客服正在输入的内容也丢了——WebSocket 断了，会话状态没了。 WebSocket 跟 HTTP 不一样。HTTP 是无状态的，请求断了重试一次就好。WebSocket 是长连接，一旦断了，连接上的状态全丢。发版又是必然事件——你不能为了 WebSocket 永远不发版。 今天聊聊怎么让 WebSocket 在服务发版时平滑过渡，不让用户感知到断线。 WebSocket 发版的三个痛点 滚动更新时，K8s 或者运维平台会给旧 Pod 发 SIGTERM 信号，然后等一段时间（默认 30 秒）后 SIGKILL。WebSocket 没有 HTTP 那样的负载均衡重试机制，Pod 一死连接直接断。 三个痛点： 连接断开——旧 Pod 停了，上面的 WebSocket 连接瞬间全断。用户端要么看到连接断开提示，要么消息发不出去。 状态丢失——客服正在输入....