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

项目简介 本项目是基于Spring Boot的高并发注册示例工程，演示如何使用MySQL的唯一索引和ON DUPLICATE KEY UPDATE语法来防止重复注册，同时大幅提升系统性能。 核心功能 唯一索引：在用户名、邮箱、手机号等字段上创建唯一索引，保证数据的唯一性 ON DUPLICATE KEY：使用MySQL的INSERT ... ON DUPLICATE KEY UPDATE语法，实现原子性的插入或更新操作 性能优化：减少数据库操作次数，提高并发性能 注册日志：记录所有注册操作，便于问题排查和分析 技术栈 Spring Boot 2.7.5 Spring Web Spring Data JPA Spring Security MySQL 8.0 Lombok 工程结构 high-concurrency-register-demo/ ├── src/ │ ├── main/ │ │ ├── java/com/example/demo/ │ │ │ ├── config/ # 配置类 │ │ │ ├── entity/ # 实体类 │ │ │ ├── repositor....

一、缓存一致性的噩梦 之前参与过一个电商平台，使用了SpringBoot + Redis缓存架构。为了提高性能，在应用层也加入了本地缓存（Caffeine），形成了二级缓存架构： L1缓存：本地缓存（Caffeine），响应速度快 L2缓存：Redis缓存，支持分布式 原本以为这样可以兼顾性能和一致性，但实际运行中却出现了严重的缓存不一致问题。 用户在APP上看到的商品价格和库存信息经常与实际不符，有时候明明已经缺货的商品，页面上还显示有库存，导致用户下单后无法发货，投诉不断。 "我们的缓存更新策略是：修改数据时，先更新数据库，然后删除本地缓存，再删除Redis缓存。但还是会出现不一致的情况。" 这样的场景，作为后端开发的你，是不是也遇到过？ 二、多级缓存一致性的挑战 在多级缓存架构中，一致性问题主要来自以下几个方面： 1. 更新顺序问题 如果先更新数据库，再删除缓存，可能会出现： 线程A：读取数据，发现缓存不存在 线程A：从数据库读取数据 线程B：更新数据库 线程B：删除缓存 线程A：将读取到的旧数据写入缓存 结果：缓存中存储的是旧数据 如果先删除缓存，再更新数据库，....

一、跨服务调用的重复提交噩梦 上周，一位朋友找我吐槽：他们公司的订单系统又出问题了。 用户在APP上下单，点击"提交"按钮后，因为网络延迟，页面没有立即响应，用户以为没提交成功，就又点击了一次。结果系统创建了两个相同的订单，用户收到了两条订单确认短信，商家也收到了两条订单通知。 更糟糕的是，这个问题不是第一次出现了。之前在支付、退款、发货等环节都发生过类似的重复操作问题。 "我们的系统是微服务架构，订单服务、支付服务、库存服务都是独立部署的，"朋友无奈地说，"跨服务调用的时候，很难保证操作不被重复执行。" 这样的场景，作为后端开发的你，是不是也遇到过？ 二、为什么重复提交这么难解决？ 在微服务架构下，重复提交问题变得更加复杂： 1. 网络不稳定 网络延迟、抖动、丢包等问题，可能导致客户端以为请求失败，从而重复发送请求。 2. 服务端处理延迟 服务端处理请求的时间过长，客户端超时后可能会重新发送请求。 3. 重试机制 为了提高系统的可靠性，很多系统都实现了自动重试机制，这也可能导致重复请求。 4. 跨服务调用 在微服务架构下，一个业务流程可能涉及多个服务的调用，任何一个环节的失败都可能导....

前言 上个月公司发生了个重大事故，财务部门发现账目对不上，订单系统和财务系统的数据出现了几十万的差异。我们花了整整一周时间才找出问题，原来是支付回调异常导致的数据不一致。 这次事故让我们深刻认识到自动化对账的重要性。我们花费了几周时间，基于SpringBoot打造了一套完整的自动化对账系统，实现了每日自动核对账务，差异自动告警修复。现在整个团队都轻松多了。 今天就把这套方案分享给大家。 问题背景 在大型分布式系统中，数据一致性是永恒的话题，经常会遇到以下问题： 跨系统数据不一致：订单系统和财务系统数据对不上 手动对账效率低：每天需要人工核对大量数据 异常处理不及时：发现问题时已经造成损失 缺乏有效监控：不知道数据何时开始不一致 修复流程复杂：发现问题后修复流程繁琐 这些问题会导致： 财务风险增加 运维成本高昂 用户信任度下降 业务流程受阻 法规合规风险 传统方案 vs 优化方案 传统方案：手工对账 // 传统手工对账流程 public void manualReconciliation() { // 1. 从业务系统获取数据 List<Order> orders =....

前言 上周生产环境出了个事故，订单系统在处理一笔重要订单时，支付服务调用失败了，虽然我们有异常处理，但后续的库存回滚、积分扣除等操作没有执行，导致数据不一致。 当时只能手动修复数据，费了很大劲才把数据恢复过来。这让我意识到，仅仅捕获异常还不够，我们需要一个完整的事务补偿机制，让失败的事务可查、可重试、可跳过。 今天就分享一下我们的解决方案。 问题背景 在分布式系统中，事务失败是不可避免的，经常会遇到以下问题： 事务失败后处理遗漏：异常处理后，某些操作没有执行 补偿逻辑复杂：需要编写大量补偿代码 缺乏监控手段：不知道哪些事务失败了需要补偿 人工干预困难：出现问题只能手动修复数据 补偿状态不透明：无法知道补偿是否成功 这些问题会导致： 数据不一致 业务流程中断 运维成本高 用户体验差 系统可靠性降低 传统方案 vs 优化方案 传统方案：手动补偿 // 订单创建流程 @Transactional public Order createOrder(OrderRequest request) { try { // 1. 创建订单 Order order = orderService.cr....

问题背景 在软件开发过程中，新版本上线是一个高风险环节，经常会遇到以下问题： 压测环境不真实：测试环境和生产环境差异大，压测结果不可信 压测数据不真实：压测数据和真实业务数据差异大，无法模拟真实场景 压测影响生产：直接在生产环境压测会影响正常业务 问题发现晚：问题往往在上线后才暴露，影响范围大 回滚成本高：上线后发现问题，回滚成本高，影响用户体验 这些问题会导致： 上线风险高，经常出现线上故障 用户体验差，服务经常不可用 运维压力大，经常需要紧急回滚 业务损失大，影响公司收入 传统方案 vs 优化方案 传统方案：测试环境压测 # 在测试环境进行压测 ab -n 10000 -c 100 http://test.example.com/api/user 问题： 测试环境和生产环境差异大 压测数据和真实业务数据差异大 无法模拟真实的用户行为 压测结果不可信 优化方案：流量镜像+影子库 // 1. 按比例镜像生产流量 // 2. 将镜像流量发送到影子库 // 3. 在影子库上进行压测 // 4. 不影响生产环境 优势： 使用真实的生产流量 真实的业务数据 不影响生产环境 提....

问题背景 在前后端分离的开发模式下，跨域请求是不可避免的。浏览器出于安全考虑，会对跨域请求进行限制，这就带来了以下问题： 预检请求频繁：每次复杂请求都会先发一个OPTIONS预检请求 预检请求慢：OPTIONS请求需要经过完整的请求处理流程 重复预检：相同的预检请求重复发送，浪费资源 前端联调困难：OPTIONS请求被拦截，影响开发效率 用户体验差：请求等待时间长，用户感知明显 这些问题会导致： 前端开发效率低，联调困难 请求响应慢，用户体验差 服务器压力大，资源浪费 前端同事抱怨多，团队协作不畅 传统方案 vs 优化方案 传统方案：每次都处理预检请求 @Configuration public class CorsConfig { @Bean public CorsWebFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("*"); config.addAllowedMethod("*"); config.addAllowedHead....

问题背景 在对接银行、政务系统等第三方接口时，通常需要使用HTTPS双向认证，这会带来以下问题： 证书频繁过期：银行/政务系统的证书有效期很短，有的只有30-90天 证书经常更换：出于安全考虑，对方会定期更换证书 需要重启服务：证书更新后需要重启服务才能生效 影响业务连续性：重启服务会导致短暂的业务中断 运维压力大：半夜证书过期，运维人员需要起来重启服务 这些问题会导致： 用户体验差，系统经常不可用 业务中断，影响核心功能 客服压力大，投诉电话多 运维被动救火，疲于奔命 证书管理混乱，容易出错 传统方案 vs 优化方案 传统方案：静态证书配置 server: ssl: key-store: classpath:keystore.p12 key-store-password: changeit trust-store: classpath:truststore.jks trust-store-password: changeit 问题： 证书更新后需要重启服务 无法动态加载新证书 影响业务连续性 运维工作量大 优化方案：动态证书加载 // 1. 监控证书目录变化 // 2.....

前言 之前我们对接了一个第三方支付接口，对方服务不太稳定，经常超时或者返回502。结果就是，用户支付失败率飙升，客服电话被打爆了。 刚开始我们只是在业务代码里加了重试逻辑，但效果不理想。后来在Gateway层统一处理，配合降级兜底，问题彻底解决了。今天就把这套方案分享给大家。 问题背景 在微服务架构中，我们经常需要调用第三方接口，比如支付、短信、物流等。这些接口往往存在以下问题： 服务不稳定：第三方服务经常超时或返回错误 网络抖动：网络质量差导致请求失败 突发流量：第三方服务扛不住突发流量 维护窗口：第三方服务定期维护，暂时不可用 这些问题会导致： 用户体验差，请求失败率高 业务中断，影响核心功能 客服压力大，投诉电话多 运维被动救火，疲于奔命 传统方案 vs 优化方案 传统方案：业务层重试 public PaymentResult pay(PaymentRequest request) { for (int i = 0; i < 3; i++) { try { return thirdPartyPayService.pay(request); } catch (Exce....

前言 上周五下午，我刚准备下班，突然收到售后的电话："用户反馈消息收不到，赶紧看看！" 我赶紧打开监控一看，死信队列里堆积了几万条消息，用户投诉电话已经打爆了。结果就是，周末两天都在处理这个问题，连摸鱼都取消了。 这件事让我深刻意识到，被动救火真的太痛苦了。后来我设计了一套死信消息自动分析和告警系统，现在遇到问题能提前发现，周末也能安心休息了。 问题背景 在消息队列的使用过程中，死信消息是不可避免的问题。但很多团队对死信消息的处理方式存在问题： 被动发现：等用户投诉了才发现问题 手动排查：逐条查看死信消息，效率低下 处理不及时：发现问题的时候，影响已经造成 缺乏监控：不知道死信消息的积累情况 没有告警：无法及时通知相关人员 这些问题导致运维人员经常处于被动救火的状态，工作压力大，用户体验也差。 什么是死信消息 死信消息是指无法被正常消费的消息，常见原因包括： 消息处理失败：消费者处理消息时抛出异常 重试次数超限：消息重试次数超过配置的最大值 消息格式错误：消息格式不符合预期 业务逻辑异常：业务校验失败 消费者异常：消费者服务异常或宕机 死信消息如果不及时处理，会导致： 消息堆....

前言 最近有一个数据同步项目，需要从消息队列消费大量数据并写入数据库。刚开始用的是单条消费+自动ACK，结果发现消费速度根本跟不上生产速度，队列积压越来越严重，系统 CPU 使用率也飙升到 90% 以上。 后来通过优化，采用批量消费+手动ACK的方式，消费速度直接提升了10倍，CPU使用率降到了30%以下。今天就把这套方案分享给大家。 问题背景 在高吞吐场景下，传统的消息消费方式存在以下问题： 单条消费效率低：每次只处理一条消息，网络IO和数据库操作频繁 自动ACK风险大：消息还没处理完就确认，可能导致消息丢失 消费节奏不可控：无法根据系统负载调整消费速度 资源浪费严重：频繁的上下文切换和网络往返 这些问题在数据量较大时尤为明显，严重影响系统稳定性和吞吐量。 传统方案 vs 优化方案 传统方案：单条消费+自动ACK @RabbitListener(queues = "message-queue") public void onMessage(Message message) { // 1. 解析消息 // 2. 业务处理 // 3. 数据库操作 // 4. 自动ACK } 问题：....

前言 最近在做一个即时通讯项目，上线后用户反馈最多的就是"消息收不到"、"连接经常断"。排查日志发现，移动端在弱网环境下WebSocket连接频繁断开，导致消息推送失败。 这个问题困扰了我好几天，尝试过各种方案，最终通过心跳机制+断线重连的组合拳，让连接稳定性提升了90%以上。今天就把这套方案分享给大家。 问题背景 WebSocket作为实时通信的首选方案，在移动端应用中广泛使用。但实际生产环境中，我们经常遇到这些问题： 网络抖动导致连接断开：用户在电梯、地铁等信号不稳定区域，WebSocket连接很容易断开 长时间无交互被中间设备断开：NAT设备、防火墙等中间设备会清理长时间无数据传输的连接 应用切后台被系统杀掉：移动端系统为了省电，会限制后台应用的网络连接 服务端无法感知客户端状态：连接断开后服务端还在推送消息，造成资源浪费 这些问题在弱网环境下尤为明显，严重影响用户体验。 问题分析 为什么WebSocket连接会断开？ WebSocket连接断开的原因有很多，但主要可以归纳为以下几类： 网络层面： 网络质量差，TCP连接超时 NAT设备超时清理空闲连接 防火墙规则限制长连接....

引言 在电商系统中，订单状态的变更是一个核心业务流程。从订单创建到支付、处理、发货、送达，每个状态变更都必须严格按照业务逻辑顺序执行。如果出现状态乱序，比如"已送达"的消息比"已发货"先到达，就会导致严重的业务逻辑错误。 传统的消息处理方式往往无法保证这种严格的顺序性要求，这就是我们今天要解决的核心问题：如何在SpringBoot应用中通过消息队列实现订单状态变更的严格按序处理。 问题场景分析 让我们先看一个典型的订单状态变更流程： 订单创建(CREATED) → 已支付(PAID) → 处理中(PROCESSING) → 已发货(SHIPPED) → 已送达(DELIVERED) 在高并发场景下，如果不做特殊处理，可能会出现这样的问题： - 消息1：订单ID=12345，状态：CREATED → PAID - 消息2：订单ID=12345，状态：PAID → PROCESSING - 消息3：订单ID=12345，状态：PROCESSING → SHIPPED 由于网络延迟、消息队列负载等因素，消费者可能以这样的顺序接收到消息： **消息3 → 消息1 → 消息2** 这就会导致....

大家好，今天我们来聊聊一个SaaS产品中的核心挑战：如何用一套规则引擎服务上千家企业客户，同时保证每家企业的规则完全独立、互不干扰。 多租户系统的现实痛点 在企业级应用开发中，我们经常面临这样的场景： 场景一：电商平台SaaS化 "老板，我们要把电商系统做成SaaS产品，服务1000家商户，每家商户的促销规则都不一样，怎么设计？" 场景二：风控系统多租户 "不同银行的风控策略差异很大，但底层逻辑相似，能不能用一套系统？" 场景三：业务规则定制化 "每个客户都要定制自己的业务规则，难道要为每个客户部署一套系统？" 这些问题的核心痛点是：如何在一套系统中实现数据和逻辑的完全隔离。 解决方案：多租户规则隔离架构 有没有一种方式，让一套规则引擎能够： ✅ 服务上千家企业 ✅ 每家企业规则完全独立 ✅ 规则互不干扰 ✅ 性能不受影响 答案是：多租户规则隔离架构！ 核心实现思路 1. 架构设计总览 ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ 企业A客户端 │ │ 企业B客户端 │ │ 企业N客户端 │ ....

大家好，今天咱们聊聊一个在业务快速迭代中非常关键的话题：如何实现业务规则的热更新。 业务规则管理的痛点 在传统的业务系统开发中，我们经常遇到这样的困扰： 场景一：紧急促销活动 "老板，双11活动马上开始了，但是折扣规则需要调整，能不能现在就改？" "这个...需要改代码，然后测试，再部署上线，最快也要1个小时..." 场景二：风控策略调整 "发现有个新的风险点，需要立即更新风控规则！" "规则写在代码里，要重启服务才能生效..." 场景三：个性化配置 "不同用户群体需要不同的优惠策略，每次调整都要发版？" 这些问题的核心痛点是：业务规则与代码耦合太紧，变更成本高，响应速度慢。 解决方案：规则热更新 有没有一种方式，让业务规则像配置一样可以动态调整，修改后立即生效，而无需重启应用？ 答案是：规则热更新 + Nacos配置监听！ 核心实现思路 1. 架构设计 我们的解决方案采用以下架构： ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ 业务应用 │ │ Nacos配置中心 │ │ 规则管理平台 │ │ ....