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

在处理海量数据时，分页查询是一个非常常见的需求。然而，当数据量达到百万级甚至千万级时，传统的 LIMIT OFFSET 分页方式会变得越来越慢，尤其是在访问后面的页码时。 第 1 页：很快 第 100 页：有点慢 第 10000 页：非常慢 第 100 万页：几乎无法响应 今天，我们来探讨如何通过**游标分页（Keyset Pagination）**技术，让深分页查询变得飞快。 问题背景 LIMIT OFFSET 的性能问题 -- 查询第 1000000 页，每页 10 条 SELECT id, name, amount, create_time FROM orders ORDER BY create_time DESC, id DESC LIMIT 10 OFFSET 9999990; 执行过程分析： ┌─────────────────────────────────────────────────────────────┐ │ LIMIT OFFSET 执行过程： │ │ │ │ 1. MySQL 需要扫描前 10000000 条记录 │ │ 2. 然后跳过前 999999....

在分布式系统中，定时任务是保障业务稳定运行的重要组成部分。然而，服务宕机、网络抖动、部署升级等情况都可能导致定时任务漏执行，从而引发数据不一致、业务异常等问题。 服务宕机重启后，发现日终任务没执行 凌晨的批处理任务，因为网络抖动漏跑了 升级部署时，正好错过了重要任务 手工补数据麻烦，容易出错 今天，我们来探讨如何构建一个调度任务漏执行补偿机制，实现服务宕机重启后自动补跑错过的定时任务。 问题背景 定时任务漏执行的常见场景 ┌─────────────────────────────────────────────────────────────┐ │ 定时任务漏执行的常见场景： │ │ │ │ 1. 服务宕机：服务突然崩溃，任务正在执行一半就中断 │ │ 2. 网络抖动：网络短暂断开，调度中心无法正常通信 │ │ 3. 部署升级：滚动发布时，部分实例任务被中断 │ │ 4. JVM Full GC：GC 停顿过长，错过任务触发时间 │ │ 5. 时钟回拨：服务器时钟回拨，导致任务触发时间判断错误 │ │ │ │ 后果： │ │ - 数据统计不完整 │ │ - 对账差异 │ │ - ....

在数据库优化中，排序操作是最常见的性能瓶颈之一。当你的 SQL 查询包含 ORDER BY、GROUP BY、DISTINCT 等操作时，如果没有合适的索引，MySQL 可能会产生 Using temporary 和 Using filesort，导致查询性能急剧下降。 问题背景 假设我们有一个电商订单表，需要查询"2024年1月上海地区用户的订单列表，按订单金额降序排列"： SELECT o.order_id, o.user_id, o.amount, o.create_time, u.username, u.phone, s.shop_name FROM orders o JOIN users u ON o.user_id = u.user_id JOIN shops s ON o.shop_id = s.shop_id WHERE o.create_time >= '2024-01-01' AND o.create_time < '2024-02-01' AND u.city = '上海' ORDER BY o.amount DESC LIMIT 100; 执行结果....

在分布式系统中，缓存是提升系统性能的关键组件。然而，一个被忽视的安全隐患正在悄然威胁着你的系统：缓存穿透。 查询一个根本不存在的数据，每次都穿透到数据库 数据库压力剧增，系统濒临崩溃 恶意攻击者利用这个漏洞，瞬间打垮你的服务 今天，我们来深入探讨如何通过布隆过滤器 + 异步预热的组合方案，彻底解决缓存穿透问题。 问题背景 什么是缓存穿透？ ┌─────────────────────────────────────────────────────────────┐ │ 正常请求流程： │ │ │ │ 请求 → Redis缓存（命中） → 返回数据 │ │ 请求 → Redis缓存（未命中） → 查询DB → 写入缓存 → 返回数据 │ │ │ │ 缓存穿透： │ │ │ │ 请求 → Redis缓存（未命中） → 查询DB（无数据） → 不写入缓存 │ │ ↑ 每次都查DB，DB压力倍增！ │ └─────────────────────────────────────────────────────────────┘ 穿透带来的危害 // 假设有这样一个查询接口 public ....

在分布式系统中，接口幂等性是保障数据一致性的基础： 支付回调重复触发了 3 次，钱多扣了 消息消费重复了 5 次，数据重复插入 前端按钮重复点击，订单创建了 2 张 重试机制导致同一请求被执行了多次 传统的幂等校验方案（如数据库唯一索引、分布式锁）在高并发场景下性能堪忧。今天我们来聊一聊如何通过 BloomFilter + Lua 的组合拳，让幂等校验的拦截速度提升 5 倍。 为什么传统幂等校验会成为瓶颈？ 先分析一下传统方案的问题： 传统幂等校验流程： ┌─────────────────────────────────────────────────────────────┐ │ 请求进来 → 查询 Redis/Database 是否存在 → 存在则拦截 │ │ ↓ │ │ 每次请求都要查询 │ │ 性能瓶颈！ │ └─────────────────────────────────────────────────────────────┘ 问题分析： 每次请求都需要查询 QPS = 10000 每次幂等校验 = 1ms 总耗时 = 10000ms = 10秒 实际处理时....

在金融、支付等领域，日终对账是保障数据一致性的关键环节： 系统A说交易成功，系统B说没收到 对账差异堆积如山，财务加班加点处理 资金差异延迟发现，造成资金风险 人工核对效率低，容易出错 传统的对账流程依赖人工处理，效率低下且容易出错。今天我们来聊一聊如何构建一个自动化对账补偿引擎，实现日终数据差异的自动核对和分钟级一致性修复。 为什么需要自动化对账补偿引擎？ 先分析一下传统对账流程的问题： 传统对账流程： ┌─────────────────────────────────────────────────────────────┐ │ 日终定时任务 → 数据抽取 → 差异比对 → 人工审核 → 手工补偿 │ │ │ │ 问题： │ │ 1. 人工介入多，效率低 │ │ 2. 处理不及时，资金风险 │ │ 3. 容易出错，遗漏差异 │ │ 4. 无法追溯，审计困难 │ └─────────────────────────────────────────────────────────────┘ 问题分析： 差异堆积 每天产生 1000+ 条差异 人工处理能力：50 条/小时 积....

在前后端分离架构中，跨域请求是家常便饭。但你是否遇到过这种情况： OPTIONS 请求占比超过 50%，带宽被大量消耗 浏览器频繁发送预检请求，后端服务压力剧增 CDN 缓存失效，每次请求都穿透到后端 今天我们来聊一聊如何在 Spring Cloud Gateway 中治理跨域预检风暴，通过智能缓存策略将 OPTIONS 请求拦截在网关层，让带宽消耗降低 80%。 为什么会出现预检风暴？ 先了解一下 CORS（跨域资源共享）的工作原理： 浏览器请求流程： ┌──────────┐ OPTIONS ┌──────────────┐ 200 OK ┌──────────┐ │ Browser │ ───────────────→ │ Gateway │ ─────────────→ │ Browser │ │ │ ←────────────── │ │ ←────────────── │ │ │ │ 200 + CORS │ │ 实际请求 │ │ │ │ headers │ │ │ │ └──────────┘ └──────────────┘ └──────────┘ ↓ ↓ 预检请....

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

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

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

做多租户系统的同学肯定都踩过这个坑：某个租户的数据莫名其妙出现在了另一个租户的账号里，或者租户 A 配置的规则被租户 B 给用上了。这些问题听起来像是低级 bug，但背后折射出的是多租户架构中数据隔离和权限控制的复杂性。 特别是在规则引擎场景下，租户会有自己的业务规则，比如优惠券规则、会员等级规则、风控规则等。如果规则引擎没有做好租户隔离，后果可能是： 租户 A 领到了租户 B 的优惠券，造成营销损失 租户 A 的风控规则被租户 B 绕过，导致业务风险 财务规则串号，造成账务错误 今天我们就来聊聊多租户规则沙箱隔离的架构设计，彻底杜绝数据串号和规则越权问题。 为什么多租户隔离这么难？ 先来分析一下多租户隔离的难点在哪里。很多团队会说："我们用了数据库租户字段，做了 WHERE tenant_id = xxx 的查询啊，怎么还会串号？" 实际情况远比这复杂： 1. 规则引擎的上下文污染 规则引擎通常会缓存已加载的规则，如果缓存 key 设计不当，可能会出现： 规则 key 只用了 ruleId，没有包含 tenantId 规则执行时的上下文（Context）被多个租户共享 规则变量....

在金融交易、支付、证券等场景下，消息顺序至关重要： 用户下单 → 支付 → 发货 → 确认收货，这个顺序绝不能乱 账户余额变更必须按时间顺序处理，否则会出现透支 证券撮合交易对时序要求精确到毫秒 Kafka 虽然通过分区机制保证了分区内的顺序，但在实际生产中，顺序消费往往会遇到各种问题： 多消费者消费同一个分区，消息乱序 扩容缩容时，分区重分配导致消息处理顺序被打乱 消息重试导致的顺序错乱 批量消费时部分失败导致的顺序问题 今天我们来聊一聊如何在 SpringBoot 中实现 Kafka 严格顺序消费，保证金融级交易链路的稳定性。 为什么顺序消费这么难？ 先分析一下 Kafka 顺序消费的难点： 1. 多消费者消费同一个分区 问题： ┌─────────────────────────────────────────────────────────┐ │ Kafka Partition 0 │ │ [Msg1] → [Msg2] → [Msg3] → [Msg4] → [Msg5] → [Msg6] │ └────────────────────────────────────....

在微服务架构中，API 网关是系统的入口，承担着请求路由、负载均衡、安全认证等重要职责。随着业务流量的不断增长，API 网关面临着越来越大的挑战，其中最常见的问题之一就是大流量下的内存溢出。 想象一下这样的场景：当系统遭受突发流量冲击时，Gateway 接收到大量的请求，每个请求都需要处理和转发。如果 Gateway 采用全量缓冲的方式处理请求体，那么在大流量下，内存使用量会急剧上升，最终导致内存溢出，系统崩溃。 今天我就跟大家分享一套基于 Spring Cloud Gateway 的大流量内存溢出防护方案，通过流式转发替代全量缓冲，让 Gateway 在高并发下依然稳定运行。 为什么会内存溢出？ 先来说说 Gateway 内存溢出的根本原因。在默认情况下，Spring Cloud Gateway 处理请求时会： 全量读取请求体：将整个请求体读取到内存中 创建完整的请求对象：为每个请求创建包含完整请求体的对象 缓冲响应数据：将后端服务的响应也完整缓冲到内存中 内存使用无上限：当请求体较大或并发请求较多时，内存使用量会持续增长 特别是在以下场景中，内存溢出的风险更高： 大文件上传：....

在微服务架构中，网关是系统的入口，承担着请求路由、安全认证、流量控制等重要职责。一旦网关出现性能问题或故障，整个系统都将受到影响。特别是在下游服务响应变慢的情况下，如果网关一直等待响应，就会耗尽线程池资源，导致整个系统不可用。 想象一下这样的场景：某个下游服务突然变慢，平均响应时间从 100ms 增长到 10s。此时如果网关没有合理的超时机制，所有的网关线程都会阻塞在这个慢服务上，新的请求无法被处理，最终导致整个网关不可用。这就是所谓的"慢请求阻塞"问题。 今天我就跟大家分享一套基于 SpringBoot + Sentinel 的网关自适应超时熔断方案，通过智能检测下游服务的响应时间，自动调整超时策略，在保护网关线程池的同时，确保系统的稳定性。 为什么会发生慢请求阻塞？ 先来说说慢请求阻塞的根本原因。在传统的网关设计中，每个请求都会被分配一个线程来处理，这个线程会一直等待下游服务的响应。如果下游服务响应缓慢，线程就会被长时间占用，无法处理其他请求。 特别是在以下场景中，慢请求阻塞的风险更高： 下游服务故障：某个下游服务出现故障，响应时间急剧增加 数据库慢查询：下游服务访问数据库时出现....

相信很多做过实时通信应用的小伙伴都遇到过这样的问题：用户在使用 App 时，切到后台再切回来，WebSocket 连接就断了；或者在地铁、电梯等弱网环境下，连接经常断开，导致消息丢失。这些问题严重影响了用户体验，特别是在需要实时通信的场景下。 在即时通讯、在线游戏、金融交易等场景中，WebSocket 连接的稳定性至关重要。一旦连接断开，不仅会导致消息丢失，还可能影响业务逻辑的正确性。那么，如何在弱网环境下保持 WebSocket 连接的稳定性，实现断线重连和消息补发呢？今天我就跟大家分享一套基于 SpringBoot 的 WebSocket 弱网保活方案。 为什么需要 WebSocket 弱网保活机制？ 先来说说我们面临的挑战。在移动应用中，WebSocket 连接经常会遇到以下问题： App 切后台：App 进入后台后，系统会限制网络连接，导致 WebSocket 连接断开 弱网环境：在地铁、电梯、地下室等信号不好的地方，网络不稳定，连接容易断开 网络切换：用户从 Wi-Fi 切换到 4G/5G，或者从 4G 切换到 5G，可能导致连接断开 心跳超时：网络延迟导致心跳包超时，服务....