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

朋友前段时间接了个支付对接的项目，联调的时候一切正常，上线跑了两天也没事。直到有一天财务对账，发现有几笔订单被扣了两次款。排查了半天，日志里同一笔订单收到了两条完全一样的请求，时间间隔不到一秒。他当时就懵了 —— 代码里明明做了幂等，怎么还能重复扣款？ 这不是什么高深的 0day 漏洞，甚至连"攻击"都算不上。就是一个中间人把你发出去的请求原封不动复制了一份，重新扔给了服务器。但后果你能想象：重复扣款、重复下单、重复发券，随便哪个都能让业务方提着刀来找你。 这个问题学名叫重放攻击（Replay Attack），解决起来其实思路很清晰。今天就用大白话聊聊，怎么用三道防线把这种请求挡在外面。 先说说重放攻击到底是怎么回事 举个例子。你在 App 上下一笔订单，客户端会发一个 HTTP 请求到服务器： POST /api/order/create Body: {"productId": 123, "amount": 99.00, "userId": 456} 这个请求跑在 HTTPS 下面，内容是加密的，中间人看不到你买了啥。但他不需要看到内容 —— 他把整个加密的数据包原封不动抓下来....

前两天群里有人发了个截图，他们公司一个后台管理系统被人拖了库。查了半天，问题出在一段 MyBatis 的动态排序代码上。那哥们特别委屈："我没拼字符串啊，我用的是 MyBatis，框架不是自带防注入吗？" 我一看代码，${orderBy} 赫然在目。他以为 MyBatis 是银弹，实际上 $ 和 # 差了一个安全分水岭。 今天聊的这个话题，但凡写过 Java Web 项目的人都会遇到。但很多人对 SQL 注入的认知停留在"用了 MyBatis 就安全了"，这个想法比注入本身还危险。 一句话搞懂：# 和 $ 到底差在哪 先别急着看方案，把这个最基础的概念弄明白。 MyBatis 里写 SQL，有两种方式塞参数： -- 方式一：#{} SELECT * FROM user WHERE name = #{name} -- 方式二：${} SELECT * FROM user WHERE name = '${name}' 区别在哪？#{} 走预编译，${} 是字符串拼接。 用 #{} 的时候，MyBatis 会把 SQL 发给数据库之前，先把参数位置用 ? 占位，参数值单独传给数据库。数....

做过全链路追踪的同学肯定都遇到过这个问题：主线程设置了 TraceID，异步任务或线程池中新线程里却拿不到这个值，导致日志里 TraceID 断掉了，排查问题时要在一堆没有上下文关联的日志里大海捞针。 我之前就遇到过这样一个案例：一个接口处理耗时 5 秒，排查后发现代码里用了 @Async 注解异步执行数据库操作，但子线程的日志里 TraceID 是空的，问了半天才发现是线程池上下文丢失的问题。 今天我们就来聊聊为什么异步场景下上下文会丢失，以及如何用 InheritableThreadLocal 或 TransmittableThreadLocal 来完美解决这个问题。 线程上下文丢失的真相 1. 为什么异步会丢上下文 问题场景： 主线程： ┌─────────────────────────────────────────────┐ │ Thread-1 │ │ TraceID: abc123 │ │ UserID: 100 │ │ RequestID: req-001 │ └─────────────────────────────────────────────┘ │ │ 提交....

凌晨 2 点，运维群炸了：结算任务超时，数据库连接池打满，CPU 飙到 95%。查了半天发现 —— 上一轮的账单还没算完，下一轮又启动了，数据重复处理、死锁、OOM，一波带走。 这不是段子。只要你的系统有定时任务，这个坑迟早会踩进去。 今天这篇文章，从根因到方案，从单机到分布式，把定时任务重叠执行这件事讲透。 一、问题到底出在哪？ 先看一个最简单的场景。 // 每 5 分钟执行一次数据同步 @Scheduled(cron = "0 */5 * * * ?") public void syncData() { // 从上游拉数据、清洗、入库 pullData(); // 耗时：不固定，2~8 分钟 cleanData(); saveToDB(); } 调度周期是 5 分钟，但 pullData() 本身就要 2~8 分钟。问题来了： 8:05 第一轮启动，预计 8:13 结束 8:10 第二轮启动，此时第一轮还没跑完 两轮并行执行，同时操作同一批数据 后果你懂的：数据重复、死锁、连接池耗尽、OOM，一条龙服务。 根因一句话：调度频率 > 任务执行耗时，且没有任何防护机制。 ....

做分页功能的同学肯定都遇到过这个问题：项目初期数据量小，分页查询秒级响应，产品经理说加上分页功能吧，很简单。结果上线后数据量上来，第 100 页就开始慢了，到第 10000 页直接超时。 我之前就遇到过这样一个案例：一个订单查询系统，用户反馈查第 1000 页以后的数据要 30 秒+，根本没法用。排查后发现，后端用的就是最常见的 LIMIT 10000, 20。 今天我们就来聊聊深分页的性能问题，以及如何用 Search After 和游标机制让第 100 万页也能毫秒响应。 深分页的性能问题根源 1. 传统分页的致命缺陷 很多开发者用的分页方式是这样的： -- MySQL SELECT * FROM orders ORDER BY create_time DESC LIMIT 10000, 20; -- Elasticsearch GET /orders/_search { "from": 10000, "size": 20, "sort": [{ "create_time": "desc" }] } 这种方式在小数据量时没问题，但数据量上来后就是灾难： 问题场景：1000万数据，....

做过分布式任务调度的同学肯定都遇到过这个问题：分片任务执行时，分片 0 先完成了，分片 1 还在跑，如果直接进入下一步可能会导致数据不完整。我之前就遇到过这样一个案例：一个数据汇总任务，分片 0 处理华东区数据，分片 1 处理华南区数据，分片 0 完成后就开始汇总，结果分片 1 还在处理，导致汇总数据只有华东区，漏掉了华南区。 今天我们就来聊聊 XXL-JOB 分片广播场景下的乱序处理问题，以及如何用全局屏障机制确保数据完整性。 分片广播的乱序问题 1. 什么是分片广播 XXL-JOB 分片广播原理： 执行器集群： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 执行器 0 │ │ 执行器 1 │ │ 执行器 2 │ │ (分片0) │ │ (分片1) │ │ (分片2) │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ ▼ ▼ ▼ 处理数据A 处理数据B 处理数据C │ │ │ ▼ ▼ ▼ 完成 进行中 等待中 调度器一次广播，所有分片同时执行！ 2. 乱序问题的典型场....

做过数据库优化的同学肯定都遇到过这个问题：明明在字段上建了索引，查询却还是全表扫描。排查后发现，原来是 SQL 语句中用字符串类型去查询数字类型字段，触发了 MySQL 的隐式类型转换，导致索引失效。 我之前就遇到过这样一个案例：一个订单查询接口，明明 order_id 字段上建了索引，但查询时却用了 order_id = '12345' 这样的字符串条件。结果查询从毫秒级变成了秒级，线上出现大量超时。 今天我们就来聊聊 MySQL 隐式类型转换的陷阱，以及如何用 MyBatis 类型处理器来强制校正。 隐式类型转换的本质 1. 什么是隐式类型转换 隐式类型转换场景： 表结构： CREATE TABLE orders ( id INT PRIMARY KEY, order_id BIGINT INDEX, -- 数字类型，有索引 user_id INT ); 查询语句： -- 字符串查询数字字段 SELECT * FROM orders WHERE order_id = '12345'; -- 数字查询字符串字段 SELECT * FROM orders WHERE user_name....

做过 Redis 开发的同学肯定都遇到过 BigKey 问题：某个 Key 的 Value 太大，导致读取时阻塞主线程，整个 Redis 服务响应变慢甚至超时。我之前就遇到过这样一个案例：一个用户的购物车数据用单个 Hash 存储，随着时间推移数据越来越多，最终这个 Key 的 Value 达到了 15MB，每次读取都会导致 Redis 阻塞 500ms+，严重影响了系统性能。 今天我们就来聊聊 Redis BigKey 的危害，以及如何用 Hash 槽化迁移的方式实现零停机拆分。 BigKey 的危害 1. 什么是 BigKey BigKey 定义： - String 类型：Value 大小超过 1MB - Hash/List/Set/ZSet：元素数量超过 1000 个 常见场景： - 用户购物车：一个 Hash 存储所有商品 - 排行榜：一个 ZSet 存储所有用户分数 - 消息队列：一个 List 存储大量消息 - 配置中心：一个 String 存储超大配置 2. BigKey 的性能问题 性能影响分析： 1. 读取阻塞 - GET bigkey → 一次性读取 10MB+ ....

做过分布式事务开发的同学肯定都遇到过这个问题：TCC 模式下的空回滚和悬挂问题。简单来说就是：Try 方法还没执行，Cancel 方法就来了；或者 Try 执行失败，但 Cancel 还是被调用了。这些异常场景处理不好，会导致数据不一致。 我之前就遇到过这样一个案例：用户下单时库存扣减服务超时，TC（事务协调器）认为 Try 失败，触发 Cancel 回滚。但由于网络抖动，库存服务实际已经扣减成功了，只是响应超时。结果 Cancel 方法又执行了一次"回滚"，把已经扣减的库存又加回去了，导致库存数据错误。 今天我们就来聊聊 TCC 空回滚与悬挂的处理方案，让你的分布式事务更加健壮。 TCC 模式基础回顾 1. TCC 三阶段流程 TCC（Try-Confirm-Cancel）模式： 阶段一：Try（预留资源） - 锁定相关资源 - 检查业务可行性 - 如果不可行，直接失败，不进入后续阶段 阶段二：Confirm（确认执行） - 真正执行业务操作 - 确认使用预留的资源 - 失败会不断重试，直到成功 阶段三：Cancel（取消回滚） - 释放预留的资源 - 回滚业务操作 - 失败也会不断....

做过支付系统的同学肯定都遇到过这个问题：订单系统显示已支付，但支付系统却说没收到钱；或者订单已经取消，但支付系统已经把款扣了。这些状态不一致的问题，如果不及时处理，轻则用户体验受损，重则资金损失。 我之前就遇到过这样一个案例：凌晨三点，客服打电话说有个用户投诉付款成功了但订单显示失败。排查后发现是支付系统回调通知在网络抖动时丢了，导致订单系统没能及时更新状态。用户半夜付款，早上才发现问题，错过了重要活动。 今天我们就来聊聊如何实现对账差异的自动修复，让订单和支付状态始终保持一致。 对账差异的常见场景 1. 订单与支付状态不一致 典型场景： 1. 订单已创建，支付未成功 - 订单状态：CREATE - 支付状态：INIT 2. 订单已支付，状态未更新 - 订单状态：CREATE（未更新） - 支付状态：SUCCESS 3. 订单已取消，退款未处理 - 订单状态：CANCELLED - 退款状态：INIT 4. 重复扣款，订单只有一个 - 订单状态：SUCCESS - 支付记录：2条 2. 差异产生的原因 差异来源： 1. 网络抖动 - 支付回调通知丢失 - 订单状态更新失败 2. 系统....

做过网关开发的同学肯定都遇到过这个问题：恶意用户或者异常客户端建立 TCP 连接后，什么请求都不发送，就静静保持着连接不走。这样会导致什么后果呢？ 我之前就遇到过这样一个案例：线上网关突然出现大量连接超时，排查后发现是有人在用脚本模拟"占坑"攻击——同时发起几千个连接，但每个连接都只发送一个请求后就再也不发数据了。这些空闲连接占用着 Netty 的 Worker 线程和内存资源，导致正常请求无法处理。 今天我们就来聊聊 Spring Cloud Gateway 的恶意长连接防护方案，让你的网关不再被"僵尸连接"拖垮。 恶意长连接的危害 1. 线程资源耗尽 Spring Cloud Gateway 基于 Netty 实现，Netty 的工作模型是这样的： Netty 线程模型： Boss 线程（1个） → 接受连接 → 分配给 Worker 线程池 Worker 线程池（N个） → 处理读写事件 → 如果有耗时操作会阻塞线程 问题场景：恶意长连接占用 Worker 线程 - 1000 个空闲连接 - 每个占用一个 Worker 线程 - 正常请求排队等待可用线程 - 响应超时 2. 内....

做过网关开发的同学肯定都遇到过这个问题：后端服务返回一个较大的 JSON 响应，但经过 Spring Cloud Gateway 转发后，响应体被截断了。前端收到不完整的 JSON 数据后，解析失败导致页面异常。特别是在返回大量数据的场景，比如数据导出、批量查询等，这个问题尤为突出。 我之前就遇到过这样一个案例：一个数据报表接口返回了大约 500KB 的 JSON 数据，但经过 Gateway 转发后，前端只收到了约 64KB 的数据。排查后发现，Gateway 默认的响应缓冲区大小限制就是 64KB，超过这个大小的响应会被自动截断。 今天我们就来聊聊 Spring Cloud Gateway 响应体截断的原因和解决方案，让您的网关能够正确处理大响应数据。 响应体截断的根本原因 1. 默认缓冲区大小限制 Spring Cloud Gateway 使用 Netty 作为底层网络框架，Netty 默认的响应缓冲区大小是 64KB： 场景模拟： - 后端返回：500KB JSON 数据 - Gateway 缓冲区：64KB - 实际转发：64KB（后面的 436KB 被丢弃） 结果：前端收到....

做过微服务灰度发布的同学肯定都遇到过这个问题：在网关层设置了灰度标记 Header，但经过 Feign 调用后，这个 Header 就神秘消失了。导致后端服务无法正确识别灰度流量，灰度发布变成了全量发布，引发线上事故。 我之前就遇到过这样一个案例：业务同学做灰度发布，在网关层设置了 X-Gray-Group: v2 的 Header，但经过几次 Feign 调用后，这个标记就丢失了。结果新版本的代码被所有用户访问到，导致部分用户看到了未完成的功能，影响了业务体验。 今天我们就来聊聊全链路灰度标透传的解决方案，让您的灰度标记在整个调用链路上畅通无阻。 灰度标丢失的根本原因 1. HTTP 请求头不会自动传递 这是最核心的问题： 调用链： 网关 → Service A → Service B → Service C 问题场景： 1. 用户请求到达网关，设置了 X-Gray-Group: v2 2. 网关调用 Service A，Header 传递成功 3. Service A 调用 Service B，Header 丢失！ 4. Service B 调用 Service C，没有灰度标记 ....

做过实时消息推送的同学肯定都遇到过这个问题：当有大量用户在线时，频繁的小消息广播会导致带宽急剧上升，甚至引发广播风暴。特别是在直播弹幕、实时通知、多人协作等场景，这个问题尤为突出。 我之前就遇到过这样一个案例：一个直播平台在搞活动时，同时在线人数突破了 10 万。运营人员发了一条弹幕抽奖消息，结果瞬间产生了 10 万条 WebSocket 消息推送，导致服务器带宽直接跑满，部分用户出现消息延迟甚至断线重连。 今天我们就来聊聊 WebSocket 广播风暴的抑制方案，让您的系统轻松应对万人在线的消息推送场景。 广播风暴的根本原因 1. 小消息频繁发送 这是最常见的情况： 场景：10 万在线用户 + 每秒 10 条小消息 每条消息大小：100 bytes 每秒发送量：10 万 × 10 = 100 万条 每秒带宽消耗：100 万 × 100 bytes = 100MB/s ≈ 800Mbps 如果每条消息有 50 字节的协议开销： 实际带宽消耗：100 万 × 150 bytes = 150MB/s ≈ 1.2Gbps 2. TCP 小包问题 TCP 小包的问题： ┌──────────....

做过分布式事务开发的朋友肯定都遇到过这个问题：使用 RocketMQ 的事务消息时，由于网络抖动、服务宕机、消费者超时等原因，部分 Half Message（半消息）无法被正确处理，导致在 Broker 上不断堆积。这不仅占用磁盘空间，严重时还会触发磁盘告警，影响整个消息队列的稳定性。 我之前就遇到过这样一个案例：某天凌晨，监控告警显示 RocketMQ Broker 的磁盘使用率突然飙升至 85%，马上就要触达 90% 的告警阈值。排查后发现，是某个服务的数据库在凌晨进行大批量数据迁移时，部分事务消息的本地事务执行失败，但由于网络重试机制的问题，相关的 Half Message 没有被正确回滚，大批量堆积在了 Broker 上。 今天我们就来聊聊 RocketMQ 事务消息 Half Message 的自动清理方案，让您的系统远离磁盘告警的困扰。 Half Message 的产生与堆积原因 1. 事务消息的执行流程 首先，让我们回顾一下 RocketMQ 事务消息的完整流程： ┌─────────────────────────────────────────────────────....