背景：为什么需要"七天免登录"？ 在日常使用各种 App 和网站时，"七天免登录"是一个非常常见的功能。用户只需要登录一次，在接下来的七天内无需再次输入账号密码，极大地提升了用户体验。 但是，这个看似简单的功能背后，却涉及到一系列复杂的技术问题： 如何在保证安全的前提下实现长期免登录？ Token 过期了怎么办？ 用户主动退出或修改密码后如何处理？ 多设备登录如何管理？ 如何防止 Token 被盗用？ 本文将从原理到代码，全面拆解"七天免登录"的标准实现方案。 核心概念：双 Token 机制 "七天免登录"的核心在于双 Token 机制，即使用两种不同生命周期的 Token： Access Token（访问令牌）：短期有效，用于接口访问认证 Refresh Token（刷新令牌）：长期有效（如7天），用于获取新的 Access Token 为什么需要双 Token？ 如果只使用一个长期有效的 Token，存在以下风险： 安全风险：Token 一旦泄露，攻击者可以长期冒充用户 撤销困难：无法快速撤销已颁发的 Token 灵活性差：无法动态调整 Token 的有效期 双 Tok....

前言 在当今数据安全日益重要的时代，保护用户敏感信息已成为每个系统必须面对的挑战。特别是在接口返回数据时，如何在不影响业务逻辑的情况下，对敏感信息进行脱敏处理，是一个值得深入研究的问题。 本文将详细介绍如何使用 Spring Boot 实现基于注解驱动的数据脱敏策略，实现手机号、银行卡号等敏感信息在返回时自动掩码处理。 一、数据脱敏的重要性 1. 法规要求 《网络安全法》：要求网络运营者对用户个人信息进行保护 《个人信息保护法》：明确规定个人敏感信息的处理规则 《数据安全法》：要求建立数据分类分级保护制度 2. 业务需求 保护用户隐私：防止用户敏感信息泄露 符合审计要求：满足内部审计和外部监管需求 提升系统安全性：减少敏感信息在系统中的暴露面 增强用户信任：让用户对系统的数据处理更有信心 3. 常见脱敏场景 场景敏感信息脱敏要求 用户注册手机号、邮箱部分掩码 订单管理银行卡号、身份证号部分掩码 员工管理薪资、联系方式部分掩码 日志记录用户信息、交易数据全量脱敏 二、技术选型 技术版本用途 Spring Boot3.2.0基础框架 Jackson2.15.0J....

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

前言 你是否遇到过这样的场景： 用户上传一个 1GB 的 Excel 文件，需要 5 分钟才能处理完成 导出 10 万条数据到 Excel，需要等待 2 分钟 批量处理 1000 个订单，每个订单需要调用 3 个第三方接口 这些长时间运行的任务，如果让用户一直等待页面响应，体验极差。更糟糕的是，如果系统崩溃或重启，任务进度全部丢失，用户需要重新提交。 今天要介绍的「异步任务结果持久化 + 查询接口」方案，将彻底解决这个问题——任务进度实时可查，系统重启不丢失。 一、传统异步任务的痛点 场景重现 产品经理说：「用户需要导出 10 万条订单数据，这个功能要尽快上线。」 你很快写出了代码： @RestController @RequestMapping("/export") public class ExportController { @GetMapping("/orders") public void exportOrders(HttpServletResponse response) { List<Order> orders = orderService.findAl....

作者：服务端技术精选 标签：Spring Boot · 线程池 · Apollo · 动态配置 难度：中级 前言 你是否遇到过这样的场景： 大促活动前，需要临时调大线程池的核心线程数，但必须重启服务才能生效 线上出现线程池配置不合理导致任务堆积，想快速调整参数却束手无策 不同环境（开发、测试、生产）需要不同的线程池配置，每次都要重新打包部署 传统的线程池配置方式，参数一旦启动就固定了。想要修改？重启服务！这不仅影响用户体验，还可能带来不必要的风险。 今天要介绍的「动态线程池 + Apollo 配置中心」方案，将彻底解决这个问题——运行时调整线程池参数，无需重启服务。 一、传统线程池的痛点 场景重现 双十一大促前夕，监控系统告警：订单服务线程池队列堆积严重，大量任务等待执行。 你一看配置： @Configuration public class ThreadPoolConfig { @Bean("orderExecutor") public ThreadPoolTaskExecutor orderExecutor() { ThreadPoolTaskExecutor execu....

作者：服务端技术精选 标签：Java 并发编程 · 线程池 · 结构化并发 难度：中级 前言 你是否曾被多线程代码折磨过？一个简单的「并发调用三个接口」，写起来却要 50 多行代码：创建线程池、提交任务、处理 Future、写 try-finally 确保关闭、加超时逻辑、处理异常传播……每次都要重新思考一遍边界条件。 今天要介绍的 ThreadForge，就是为解决这个痛点而生的。 一、被忽视的并发复杂度 场景重现 产品经理说：「用户详情页太慢了，能不能优化一下？」 你一看代码，三个接口串行调用：先查用户信息（200ms），再查订单列表（200ms），最后查积分余额（200ms），加起来 600ms。 「简单，改成并发调用就行。」你心想。 于是你写出了这样的代码： ExecutorService executor = Executors.newFixedThreadPool(10); try { Future<User> userFuture = executor.submit(() -> userService.get(uid)); Future<Li....

导语 在分布式系统中，任务的执行往往跨越多个服务和组件，如何追踪任务的完整执行链路，了解每一步的执行状态和耗时，是系统可观测性的重要组成部分。本文将介绍如何在SpringBoot应用中实现任务执行的链路追踪和TraceID透传，从任务调度到执行完成，实现全链路的可观测性。通过这种方式，您可以实时监控任务的执行状态，快速定位问题，提高系统的可靠性和可维护性。 一、任务执行链路追踪的概念 1.1 什么是链路追踪 链路追踪（Distributed Tracing）是一种用于监控和观察分布式系统中请求或任务执行过程的技术。它通过为每个请求或任务分配一个唯一的标识符（TraceID），并在整个执行过程中传递这个标识符，从而实现对整个执行链路的追踪。 1.2 任务执行链路的特点 1. 跨服务 任务执行可能涉及多个微服务 不同服务之间需要传递上下文信息 需要追踪任务在不同服务中的执行状态 2. 异步执行 任务可能是异步执行的 执行过程可能涉及消息队列 需要追踪异步操作的完整链路 3. 长时间运行 任务可能运行时间较长 需要实时监控任务的执行状态 需要记录任务的执行历史 1.3 链路追踪的....

导语 在大型应用系统中，为了提升数据库的并发处理能力，通常会采用读写分离的架构。主库负责处理写操作，而从库负责处理读操作。然而，这种架构带来了一个常见的问题：主从复制存在延迟，导致从库读取的数据可能是过期数据。本文将介绍如何在SpringBoot应用中实现读写分离，并针对事务场景提供强制主库的解决方案，确保在事务内读取的数据是最新的，避免因主从延迟导致的脏读问题。 一、读写分离与主从延迟问题 1.1 读写分离架构 1. 架构设计 在读写分离架构中： 主库（Master）：负责处理所有的写操作（INSERT、UPDATE、DELETE） 从库（Slave）：负责处理所有的读操作（SELECT） 数据复制：主库的数据通过复制机制同步到从库 2. 优势 优势描述 读写负载分离写操作和读操作分别由不同的数据库处理 提高并发能力可以部署多个从库分担读压力 提升读取性能读操作分散到多个从库，减少单库压力 高可用性主库故障时，可以将从库提升为主库 1.2 主从延迟问题 1. 延迟原因 复制机制：MySQL主从复制是异步的，存在延迟 网络问题：主从之间的网络延迟 负载过高：从库处理能....

导语 在现代应用中，邮件推送是一种常见的功能，用于用户注册验证、密码重置、业务通知等场景。QQ邮箱作为国内常用的邮箱服务，提供了稳定的SMTP服务，方便开发者集成到应用中。本文将介绍如何在Spring Boot应用中集成QQ邮箱的SMTP服务，实现邮件推送功能。通过本文的技术方案，您将能够快速实现邮件发送功能，为应用添加通知能力。 一、QQ邮箱SMTP服务配置 1.1 开启SMTP服务 登录QQ邮箱 访问 https://mail.qq.com/ 并登录您的QQ邮箱 进入设置页面 点击顶部导航栏的「设置」按钮 选择「账户」选项卡 开启SMTP服务 找到「POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV服务」部分 开启「SMTP服务」 生成授权码 点击「生成授权码」 按照提示完成验证（通常需要短信验证） 复制生成的授权码，这将作为邮件发送的密码 1.2 重要注意事项 授权码而非QQ密码：使用SMTP服务时，需要使用生成的授权码作为密码，而不是QQ登录密码 安全保存：授权码具有与密码相同的权限，需要安全保存 定期更新：如果担....

导语 在大数据量的系统中，分页查询是一个常见的需求。传统的基于 OFFSET 和 LIMIT 的分页方式在处理大数据量时会遇到性能瓶颈，特别是当翻到较深的页面时，查询速度会变得非常慢。本文将介绍一种基于游标和时间戳的分页优化方案，通过避免使用 OFFSET，实现千万级数据的高效分页，即使翻到第 10 万页依然能保持毫秒级响应。 一、传统分页的性能问题 1.1 传统分页的实现 基于 OFFSET 和 LIMIT 的分页 -- 第 1 页，每页 10 条 SELECT * FROM users ORDER BY id DESC LIMIT 10 OFFSET 0; -- 第 10 万页，每页 10 条 SELECT * FROM users ORDER BY id DESC LIMIT 10 OFFSET 999990; 1.2 性能问题分析 1. 数据扫描 当 OFFSET 很大时，数据库需要扫描大量数据 例如，OFFSET 999990 时，数据库需要扫描 100 万条数据才能返回 10 条结果 随着页码的增加，扫描的数据量线性增长 2. 索引使用 虽然使用了索引，但 OFFS....

导语 在现代应用开发中，灵活的数据存储需求越来越常见。传统的关系型数据库表结构难以应对频繁变化的业务需求，而 NoSQL 数据库虽然灵活但缺乏事务支持。MySQL 5.7+ 引入的 JSON 字段类型为我们提供了一种折中的解决方案，既保持了关系型数据库的可靠性，又获得了 NoSQL 的灵活性。 然而，JSON 字段的查询性能一直是一个挑战。MySQL 8.0 引入的虚拟列索引技术为解决这个问题提供了可能，使得我们可以在 JSON 字段上创建索引，获得接近传统列的查询性能。 本文将介绍如何在 SpringBoot 应用中使用 MySQL JSON 字段和虚拟列索引，实现灵活存储配置的同时，不妥协查询性能。 一、MySQL JSON 字段的特性与优势 1.1 JSON 字段的基本特性 1. 数据类型 MySQL 5.7+ 支持原生 JSON 数据类型 自动验证 JSON 格式的有效性 提供丰富的 JSON 函数进行操作 2. 存储方式 采用二进制格式存储，更紧凑高效 支持快速访问 JSON 对象的特定元素 避免了传统文本存储的解析开销 3. 操作函数 JSON_EXTRACT()....

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

导语 在分布式系统中，跨服务操作是常见的场景。然而，当多个服务同时操作共享资源时，可能会出现竞态条件和死锁问题。分布式锁是解决这类问题的有效手段，但如何处理锁的超时释放和事务的回滚，是一个需要仔细考虑的问题。 一、分布式锁的原理与实现 1.1 分布式锁的概念 分布式锁是一种在分布式系统中用于协调多个服务对共享资源访问的机制。它确保在同一时间只有一个服务能够访问特定的资源，从而避免竞态条件和数据不一致的问题。 1.2 分布式锁的实现方式 1. 基于 Redis 的分布式锁 使用 Redis 的 SETNX 命令 支持过期时间设置 实现简单，性能高 2. 基于 ZooKeeper 的分布式锁 使用 ZooKeeper 的临时节点 支持顺序锁和公平锁 可靠性高，但性能相对较低 3. 基于数据库的分布式锁 使用数据库的唯一约束 实现简单，但性能较低 1.3 分布式锁的特性 特性描述 互斥性同一时间只有一个服务能够获取锁 可重入性同一服务可以多次获取同一把锁 超时释放锁在一定时间后自动释放，防止死锁 高可用性锁服务高可用，避免单点故障 公平性按照请求顺序获取锁 二、事务超....

背景：分布式事务的挑战 在微服务架构中，分布式事务是一个常见的挑战。传统的2PC（两阶段提交）方案虽然能保证强一致性，但性能开销大，不适合高并发场景。而最终一致性方案虽然性能更好，但如何确保事务最终达成一致，以及如何处理失败的事务，成为了新的挑战。 想象一下这些场景： 订单创建成功，但库存扣减失败 支付成功，但订单状态更新失败 消息发送成功，但消费者处理失败 跨服务调用时网络中断，部分操作成功部分失败 这些问题如果不及时处理，会导致系统数据不一致，影响业务正常运行。 核心概念：最终一致性 + 补偿任务看板 本文将介绍一种基于 SpringBoot 的最终一致性解决方案，通过以下核心机制确保分布式事务的最终一致性： 事务日志：记录每笔分布式事务的执行状态 补偿机制：自动或手动处理失败的事务 任务看板：可视化展示失败事务，支持人工介入 重试策略：智能的重试机制，避免无效重试 架构设计 系统架构 ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ 微服务 A │ │ 微服务 B │ │ 微服务 C │ └────....

背景：订单与支付状态不一致的困扰 在电商、金融等系统中，订单状态与支付状态不一致是一个常见且棘手的问题。想象一下这些场景： 用户支付成功，但订单状态仍显示"待支付" 订单显示"已支付"，但支付平台显示"支付失败" 系统崩溃导致部分交易数据丢失 网络延迟造成状态更新不同步 这些问题不仅影响用户体验，还可能导致财务风险和审计难题。传统的解决方案往往依赖人工对账，效率低下且容易出错。 核心概念：事务日志快照 + 定时对账 本文将介绍一种基于 SpringBoot 的自动化解决方案，通过以下核心机制实现订单与支付状态的一致性保障： 事务日志快照：记录每笔交易的状态变更历史 定时对账：定期比对订单系统与支付系统的状态 自动修复：发现差异后自动进行状态修正 异常处理：对无法自动修复的情况进行告警 架构设计 系统架构 ┌───────────────┐ ┌────────────────┐ ┌─────────────────┐ │ 订单系统 │ │ 支付系统 │ │ 对账系统 │ └───────────────┘ └────────────────┘ └─────────────────....