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

一、惊魂5分钟：那个被“爆款商品”打崩的下午 大促当天14:03，监控突然爆红！ 🔥 某新款手机开售，商品ID=10086的Key单点QPS冲到12万+ 🔥 Redis CPU瞬间100%，连接池耗尽 🔥 所有服务接口503，客服电话被打爆... 复盘时运维拍桌：“早知道是热点Key，加个本地缓存不就完了？” 可问题来了： ❓ 热点Key谁能提前预知？（昨天卖拖鞋，今天卖火箭） ❓ 手动加缓存？等发现时雪崩已完成 ❓ 加了缓存怎么清理？数据不一致更致命 今天，教你用“自动发现+智能兜底”组合拳 让系统在Redis崩溃前自动防御、秒级自愈，把故障消灭在萌芽！✨ 二、为什么热点Key是“隐形炸弹”？ 场景表现后果 爆款商品秒杀单Key QPS 10万+Redis CPU打满，全站瘫痪 明星离婚热搜突发流量涌入连接池耗尽，服务雪崩 恶意爬虫攻击针对性刷某Key资源被耗尽，正常用户无法访问 💡 致命痛点： ❌ 传统方案靠“人肉监控+手动加缓存”，响应速度永远慢半拍 ❌ 固定加本地缓存？99%的Key不需要，浪费内存还引发一致性问题 ✅ 正确姿势：让系统自己“感知热点→自动....

作者：服务端技术精选 标签：Spring Boot · Spring Session · Redis · 微服务 难度：中级 前言 你是否遇到过这样的场景： 用户在服务 A 登录成功，跳转到服务 B 时却提示未登录 多个服务部署在不同服务器，用户刷新页面后 Session 丢失 水平扩展后，新增的服务器无法访问用户 Session 单点登录（SSO）需求，需要跨系统共享登录状态 这些问题在单体应用中不存在，但在微服务架构中却是常见痛点。传统的 HTTP Session 存储在服务器内存中，无法在多个服务之间共享。 今天要介绍的「Spring Session + Redis 分布式会话」方案，将彻底解决这个问题——多服务共享会话，水平扩展无障碍。 一、传统会话的痛点 场景重现 你的系统从单体应用拆分为微服务架构： 单体应用： ┌─────────────────────────────────┐ │ Nginx │ │ ┌───────────────────────┐ │ │ │ 单体应用 │ │ │ │ (Session 存在内存) │ │ │ └─────────────....

导语 在高并发系统中，缓存是提升性能的关键手段。然而，当热点 Key 过期时，大量并发请求同时穿透缓存直接访问数据库，可能导致数据库压力骤增甚至宕机。这种现象被称为"缓存击穿"。 本文将介绍如何在 SpringBoot 应用中实现 Redis 缓存击穿防护和互斥重建机制，确保热点 Key 过期时，只有一个线程回源数据库，其他线程等待或使用旧数据，从而保护数据库免受高并发冲击。 一、缓存击穿的概念与危害 1.1 什么是缓存击穿 缓存击穿是指某个热点 Key 在高并发访问时突然过期，导致大量并发请求同时穿透缓存直接访问数据库的现象。 场景描述： 某个商品信息被大量用户频繁访问 该商品的缓存 Key 设置了过期时间 缓存过期瞬间，大量请求同时到达 所有请求都发现缓存不存在，同时访问数据库 数据库瞬间承受巨大压力，可能导致宕机 1.2 缓存击穿与相关概念的区别 概念描述解决方案 缓存击穿热点 Key 过期，大量请求同时访问数据库互斥锁、永不过期 缓存穿透查询不存在的数据，请求直接访问数据库布隆过滤器、缓存空值 缓存雪崩大量 Key 同时过期，导致数据库压力骤增过期时间随机化、预热 ....

一、问题背景：为什么需要 Redis 实现登录校验？ 在传统的单体应用中，我们通常使用 Session 来管理用户登录状态。但在微服务架构和分布式系统中，Session 面临着诸多挑战： 传统 Session 的痛点 单点故障：Session 存储在单个服务器上，服务器宕机会导致所有用户登录状态丢失 无法水平扩展：多台服务器之间无法共享 Session，用户请求可能被路由到不同服务器导致登录失效 内存压力：大量用户 Session 占用服务器内存，影响性能 跨域问题：前后端分离架构下，Session 跨域处理复杂 Redis 方案的优势 特性传统 SessionRedis + Token 分布式支持❌ 不支持✅ 天然支持 水平扩展❌ 困难✅ 容易 性能⚠️ 内存受限✅ 独立缓存服务 跨域❌ 复杂✅ 天然支持 安全性⚠️ 一般✅ 可设置过期时间 持久化❌ 易丢失✅ 可持久化 二、核心概念：Token + Redis 认证机制 1. 认证流程 ┌─────────────┐ 1. 登录请求 ┌─────────────┐ │ 客户端 │ ─────────────────&....

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

今天我们聊聊一个在高并发场景下经常遇到的问题——缓存与数据库一致性问题，以及如何用SpringBoot AOP + Redis实现延时双删来解决这个问题。 问题背景：缓存与数据库一致性 在高并发系统中，我们通常会引入缓存来提升系统的响应速度。但在数据更新时，经常会遇到缓存与数据库不一致的问题。 举个例子：当一个商品的价格发生变化时，如果只更新了数据库而没有清除缓存，那么用户在一段时间内看到的还是旧价格；如果先删除缓存再更新数据库，在高并发场景下可能会出现以下情况： 线程A删除缓存 线程B查询数据，发现缓存为空，从数据库读取旧数据并写入缓存 线程A更新数据库 最终缓存中仍然是旧数据 延时双删：一种巧妙的解决方案 延时双删（Delayed Double Delete）是一种解决缓存一致性问题的策略，其核心思想是在更新数据库后，先删除一次缓存，等待一段合适的时间后，再次删除缓存。 具体步骤如下： 删除缓存 更新数据库 延时一段时间（如500ms） 再次删除缓存 为什么要延时后再删除一次缓存呢？这是为了防止在第1步和第2步之间，有其他线程读取到旧数据并重新写入缓存的情况。通过延时再删除....

引言 最近在优化用户登录体验时，发现一个有意思的现象：用户平均每天打开APP 3-5次，但每次都要求输入密码，体验真的很差。于是我们引入了七天免密登录功能，用户勾选"七天内自动登录"后，7天内无需输入密码，大大提升了用户体验。 很多同学可能觉得免密登录很复杂，其实只要合理利用Redis的过期机制，实现起来并不难。今天就来聊聊如何用SpringBoot + Redis实现一个安全可靠的七天免密登录系统。 为什么需要七天免密登录？ 用户体验痛点 传统的登录方式存在这些问题： 频繁登录： 用户每天多次打开APP都要输入账号密码 忘记密码导致登录失败 手机端输入密码体验差 记忆负担： 多个APP需要记住不同密码 密码复杂度要求高，难以记忆 密码管理混乱 安全与便利的平衡： 短期免密登录：兼顾安全与便利 长期记住密码：安全风险高 永久免密登录：安全隐患大 核心架构设计 我们的七天免密登录架构： ┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ 用户浏览器 │───▶│ SpringBoot │───▶│ Re....

前言 在日常开发中，我们经常遇到这样的问题：单个Redis实例扛不住高并发访问，或者在分布式环境下多节点间缓存无法保持一致。这时候，一个巧妙的多级缓存方案就能帮我们解决这些问题。 今天就来分享一套基于SpringBoot + Redis发布订阅的多级缓存架构，让你的应用在高并发下依然保持飞一般的速度。 为什么需要多级缓存？ 在微服务架构下，随着业务复杂度的增加和并发量的上升，单级缓存已经无法满足性能要求。多级缓存的价值在于： 性能优化：就近访问，减少网络延迟 容量扩展：多层级存储，突破单点容量限制 可用性提升：多级冗余，提高系统健壮性 成本控制：合理分配存储资源，降低成本 Redis发布订阅核心原理 Redis的发布订阅（Pub/Sub）模式是一种消息通信模式，发送者（publisher）发送消息，订阅者（subscriber）接收消息。其核心优势在于： 实时性：消息发布后立即推送给所有订阅者 解耦性：发布者和订阅者无需知道彼此的存在 轻量级：相比消息队列，实现简单，性能更高 在多级缓存场景中，我们可以利用Pub/Sub机制实现缓存的实时同步。 实现方案详解 1. 多级缓存架构....

在日常开发中，我们经常会遇到需要延迟执行任务的场景，比如订单超时取消、优惠券到期提醒、邮件定时发送、消息重试等。传统的做法可能是使用定时任务扫描数据库，但这种方式效率低下，特别是在高并发场景下。 Redis作为一个高性能的内存数据库，为我们提供了多种实现延时队列的方式。今天我就来详细介绍4种基于Redis的延时队列实现方式，并分析它们各自的优缺点和适用场景。 什么是延时队列？ 延时队列顾名思义，是指元素进入队列后，可以延时一定时间再被消费者取出执行。这与普通队列的区别在于，普通队列中的元素一旦入队就可以被立即消费，而延时队列中的元素需要等到指定时间后才能被消费。 为什么要使用Redis实现延时队列？ 使用Redis实现延时队列有几个显著优势： 高性能：Redis基于内存操作，读写速度极快 丰富的数据结构：支持String、Hash、List、Set、ZSet、Stream等多种数据结构 原子性操作：Redis的命令都是原子性的，保证了数据一致性 持久化支持：可以配置RDB和AOF持久化，防止数据丢失 4种实现方式详解 1. 基于Sorted Set的延时队列 这是最经典也是最常用的....

大家好，我是服务端技术精选的作者。今天咱们聊聊一个在电商领域极其重要的话题：高并发秒杀系统。 秒杀系统的挑战 在我们的日常开发工作中，经常会遇到这样的场景： 限量商品开售瞬间，成千上万的用户同时访问 系统在秒杀开始时直接崩溃，用户无法下单 超卖现象频发，库存被抢购一空 黑产机器人恶意刷单，正常用户买不到商品 传统的库存扣减方式在高并发场景下根本无法胜任，今天我们就来聊聊如何用Redis + Lua构建一个高并发的秒杀系统。 为什么选择Redis + Lua 相比传统的数据库事务方案，Redis + Lua有以下优势： 高性能：内存操作，响应速度极快 原子性：Lua脚本在Redis中是原子执行的 低延迟：避免数据库的网络IO开销 高并发：Redis单机可支撑10万+ QPS 系统架构设计 1. 整体架构 用户请求 → API网关 → 限流过滤 → Redis Lua脚本 → 库存扣减 → 订单创建 2. 核心组件 Redis：存储商品库存和用户限购信息 Lua脚本：原子性执行库存扣减逻辑 消息队列：异步处理订单创建 限流组件：防止恶意刷单 Lua脚本实现 1. 库存扣减脚本....