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

一、连接池获取超时的痛点 上周，一位做支付系统的朋友吐槽：他们的系统在高峰期经常出现接口超时的问题，日志里大量报错 "Connection is not available, request timed out after 30000ms"。 "我们已经把连接池最大数调到了 50，"他说，"但还是不够用，一到高峰期就出问题。" 我查看了他们的系统，发现问题确实很严重： 系统在高峰期 TPS 约 2000 数据库连接池最大 50 个 平均接口耗时 150ms 理论上 50 个连接每秒能处理约 333 个请求，但实际高峰需要 2000 TPS 每次接口需要访问数据库 3-5 次 更关键的是，他们根本不知道连接都去哪了，是哪些SQL慢查询占用了连接，还是存在连接泄漏？ 二、传统排查方案的局限性 1. 手动查看日志 通过日志查看哪些接口慢、哪些SQL执行时间长。 这种方案的问题： 滞后性：问题已经发生，只能事后分析 信息不全：只知道某个接口慢，不知道当时系统整体状态 无法定位根因：看到的是表象，不是根因 耗时耗力：需要大量时间分析日志 2. 手动dump线程 通过 jstack 或 A....

一、分页查询的痛点 上周，一位做数据分析的朋友向我抱怨：他们的系统在处理大量数据时，分页查询变得越来越慢。"我们有一张包含 1000 万条记录的用户表，"他说，"当翻到第 100 页时，响应时间超过了 5 秒，用户体验极差。" 我帮他检查了一下代码，发现他们使用的是传统的 LIMIT OFFSET 分页方式： SELECT * FROM user ORDER BY id DESC LIMIT 10 OFFSET 1000000; 这种查询方式在数据量较大时，会有严重的性能问题。因为 MySQL 需要先跳过 OFFSET 指定的行数，然后再返回 LIMIT 指定的行数。当 OFFSET 达到 100 万时，MySQL 需要扫描 1000010 行数据，然后只返回 10 行，效率非常低。 二、传统分页方案的局限性 为了实现分页查询，我们通常会使用以下方案： 1. LIMIT OFFSET 分页 SELECT * FROM table ORDER BY id DESC LIMIT 10 OFFSET 1000000; 这种方案的问题： 性能差：随着 OFFSET 的增大，查询时间线性增....

一、自增主键耗尽的痛点 上个月，一位做电商的朋友遇到了一个棘手的问题：他们的订单表突然无法插入新数据，报错 "Duplicate entry '2147483647' for key 'PRIMARY'"。 "我们的订单表用的是 INT 类型的自增主键，"朋友无奈地说，"现在已经达到了 INT 的最大值 2147483647，无法再插入新订单了。" 我帮他检查了一下数据库，发现问题确实如此： 订单表的主键是 id INT AUTO_INCREMENT 当前最大 ID 已经接近 2147483647 系统每天新增约 10 万条订单 按照这个速度，最多只能再支撑 20 天左右 更糟糕的是，他们之前完全没有意识到这个问题，直到系统崩溃才发现。这种情况下，数据迁移和表结构修改的风险非常高，可能会导致服务中断和数据丢失。 二、传统方案的局限性 为了避免自增主键耗尽的问题，我们通常会使用以下方案： 1. 定期手动检查 -- 检查当前最大 ID 和使用百分比 SELECT TABLE_NAME, AUTO_INCREMENT, (AUTO_INCREMENT / POW(2, 31)) * 10....

问题背景 在使用 Redis 作为缓存时，缓存雪崩是一个常见的性能问题。当大量缓存 Key 在同一时间过期时，会导致以下问题： 数据库压力剧增：所有请求都会直接访问数据库，导致数据库过载 系统响应变慢：数据库处理能力有限，无法处理大量并发请求 服务雪崩：系统可能因此崩溃，影响整个应用的可用性 用户体验下降：响应时间变长，甚至出现超时 缓存雪崩的常见原因包括： 集中过期：大量缓存 Key 设置了相同的过期时间 缓存预热：系统启动时批量加载缓存，设置了相同的过期时间 缓存失效：Redis 服务重启或网络故障导致缓存全部失效 热点数据：热点数据的过期时间集中，导致大量请求同时回源 核心概念 缓存雪崩 缓存雪崩是指在某一时间段内，大量缓存 Key 同时过期或失效，导致所有请求都直接访问数据库，造成数据库压力剧增的现象。 随机偏移 随机偏移是指在设置缓存过期时间时，添加一个随机值，使缓存的过期时间分散，避免集中过期。 互斥重建 互斥重建是指在缓存失效时，只有一个线程去重建缓存，其他线程等待或返回旧值，避免多个线程同时重建缓存导致的数据库压力。 缓存穿透 缓存穿透是指查询一个不存在的数据，....

问题背景 在使用 Seata 等分布式事务框架时，undo_log 表会存储大量的事务回滚日志，用于在事务失败时进行回滚操作。随着业务量的增长，undo_log 表会不断膨胀，甚至可能达到几十 GB 或上百 GB，导致以下问题： 数据库存储空间不足：undo_log 表占用大量磁盘空间，影响数据库性能 查询性能下降：表数据量大，导致查询速度变慢 备份时间过长：数据库备份时间增加，影响系统维护 恢复时间延长：数据库恢复时间变长，增加系统 downtime 维护成本增加：手动清理日志的成本高，容易出错 核心概念 undo_log 表 undo_log 表是 Seata 等分布式事务框架用于存储事务回滚日志的表，主要包含以下字段： id：主键 branch_id：分支事务 ID xid：全局事务 ID context：上下文信息 rollback_info：回滚信息（二进制数据） log_status：日志状态 log_created：创建时间 log_modified：修改时间 自动归档策略 自动归档策略是指定期将过期的 undo_log 数据归档到历史表或外部存储，以减少主表的数....

问题背景 在分布式系统中，事务补偿是保证系统最终一致性的重要手段。然而，当系统面临网络故障、数据库异常或业务逻辑错误时，事务补偿任务可能会失败并积压。如果这些失败的任务得不到及时处理，不仅会影响系统的一致性，还可能导致业务流程中断，给企业带来严重的损失。 常见的问题包括： 任务积压：失败的事务补偿任务堆积，数量超过阈值 人工介入不及时：系统无法自动通知相关人员处理积压任务 处理效率低下：人工处理积压任务效率低，容易遗漏 监控盲区：缺乏对事务补偿任务状态的实时监控 风险评估困难：无法准确评估积压任务对系统的影响 核心概念 事务补偿 事务补偿是指在分布式事务中，当某个分支事务执行失败时，通过执行相反的操作来恢复系统状态，确保系统的最终一致性。 补偿任务 补偿任务是指需要执行事务补偿操作的任务，通常包含以下信息： 任务ID：唯一标识补偿任务 业务类型：补偿任务的业务类型 业务ID：关联的业务ID 补偿状态：任务状态（待处理、处理中、成功、失败、重试中） 重试次数：已重试次数 失败原因：失败的具体原因 创建时间：任务创建时间 最后处理时间：最后处理时间 任务积压 任务积压是指系统中待处....

问题背景 在微服务架构中，分布式事务是一个绕不开的挑战。Seata 作为一款开源的分布式事务解决方案，以其简单易用的特点赢得了广泛的应用。其中，AT 模式由于其无侵入性，成为了很多开发者的首选。然而，在高并发场景下，Seata AT 模式的锁冲突问题逐渐凸显： 全局锁等待超时：多个事务同时操作同一数据时，后到的事务需要等待前面的事务释放锁，超过超时时间后会导致事务失败 性能下降：锁冲突严重时，系统吞吐量显著下降，响应时间延长 死锁风险：在复杂的业务场景中，可能出现死锁，导致系统完全不可用 难以定位：锁冲突的原因复杂，难以快速定位和解决 核心概念 Seata AT 模式原理 Seata AT 模式是一种基于数据库本地事务的两阶段提交方案： 第一阶段：业务 SQL 执行前，Seata 会记录数据的原始状态（undo log），然后执行业务 SQL，最后提交本地事务 第二阶段：如果所有分支事务都成功，Seata 会删除 undo log；如果有分支事务失败，Seata 会根据 undo log 回滚数据 全局锁机制 Seata AT 模式使用全局锁来保证分布式事务的一致性： 全局锁....

问题背景 在微服务架构中，网关作为系统的入口，承担着请求路由、安全认证等重要职责。为了保证通信安全，HTTPS 成为了标配，而双向认证（mTLS）则是更高安全级别的选择。然而，配置 HTTPS 双向认证的过程往往充满挑战： 证书管理复杂：需要创建根证书、服务器证书、客户端证书，涉及多个文件和密码 配置繁琐：需要在网关和服务端分别配置证书和密钥 调试困难：出现问题时，难以定位是证书问题、配置问题还是网络问题 连通性验证：需要编写测试代码或使用复杂的命令行工具验证双向认证是否正常 环境差异：不同环境（开发、测试、生产）的证书配置不同，容易出错 核心概念 HTTPS 双向认证原理 HTTPS 双向认证（mTLS，Mutual TLS）是一种安全通信协议，要求通信双方都需要验证对方的身份： 客户端验证服务端：客户端验证服务端的证书是否由可信任的CA签发 服务端验证客户端：服务端验证客户端的证书是否由可信任的CA签发 证书链结构 ┌─────────────────┐ │ 根证书 (CA) │ └────────────┬────┘ │ ┌────────────▼────┐ ┌────....

引言 在微服务架构中，全链路追踪是确保系统可观测性的关键技术之一。通过在请求头中传递TraceID，我们可以将分布式系统中各个服务的日志和调用链关联起来，实现端到端的请求追踪。然而，在使用Spring Cloud Gateway作为API网关时，常常会遇到一个棘手的问题：请求头中的TraceID等关键信息在经过网关后丢失，导致全链路追踪中断，给问题排查带来极大困难。 本文将深入探讨Spring Cloud Gateway请求头透传丢失的原因，分析其技术原理，并提供完整的修复方案，确保TraceID等关键请求头能够在整个微服务调用链中正确传递。 问题背景 全链路追踪的重要性 全链路追踪（Distributed Tracing）是微服务架构中不可或缺的技术，它通过在请求头中传递唯一的TraceID，将分布式系统中各个服务的调用关联起来，形成完整的调用链路。这对于： 问题排查：快速定位服务调用中的异常和瓶颈 性能分析：识别系统中的性能瓶颈 服务依赖分析：了解服务之间的调用关系 系统监控：实时监控系统的运行状态 请求头透传丢失的表现 在使用Spring Cloud Gateway时，常见的....

引言 在微服务架构中，API网关作为系统的统一入口，承担着请求路由、负载均衡、安全认证、限流等重要职责。其中，限流是保障系统稳定性的关键手段之一，它可以防止系统被突发流量压垮，保护后端服务的可用性。 然而，传统的限流配置通常需要在代码中硬编码或在配置文件中静态配置，当遇到突发流量时，运维人员需要修改配置文件并重启服务才能生效，这种方式响应速度慢，无法及时应对流量变化。 本文将深入探讨Spring Boot网关限流配置热更新的实现方案，通过配置文件监听、动态刷新等技术，实现限流阈值的秒级调整，无需重启服务，确保系统在面对突发流量时能够快速响应。 问题背景 传统限流配置的痛点 配置静态化：限流阈值通常在配置文件中静态定义，无法动态调整 重启生效：修改配置后需要重启服务才能生效，响应速度慢 无法应对突发流量：面对突发流量时，无法及时调整限流阈值 运维成本高：每次调整都需要重启服务，增加运维负担 影响用户体验：重启过程中服务暂时不可用，影响用户体验 热更新的需求 实时性：配置修改后能立即生效，无需重启服务 安全性：配置更新过程中不影响现有请求处理 可靠性：配置更新失败时能回滚到原配置 可....

引言 在微服务架构中，API网关作为系统的统一入口，承担着请求路由、负载均衡、安全认证等重要职责。Spring Cloud Gateway作为新一代的响应式API网关，因其高性能、低延迟的特性，被广泛应用于微服务架构中。 然而，在实际生产环境中，路由配置错误是导致网关服务中断的常见原因之一。路由配置错误可能导致以下问题：下游服务地址配置错误、下游服务不可用、路由规则冲突等。这些问题会导致网关返回500错误，严重影响用户体验和系统可用性。 本文将深入探讨Spring Cloud Gateway路由配置错误的熔断机制，以及如何实现自动降级返回友好提示，确保网关服务的高可用性。 问题背景 路由配置错误的常见类型 在Spring Cloud Gateway中，路由配置错误主要分为以下几类： 下游服务地址错误：URI地址配置错误，如端口号错误、路径错误等 下游服务不可用：下游服务宕机或网络不可达 路由规则冲突：多个路由规则匹配同一请求，导致路由不确定 超时配置不合理：请求超时时间设置过短，导致大量超时 负载均衡策略错误：负载均衡配置错误，导致请求分发失败 路由错误的影响 路由配置错误会导致以....