Caffeine+Redis 二级缓存，解决缓存穿透、击穿、雪崩

核心技术知识点

1. 本地缓存 Caffeine 特性：高内存读写、进程内无网络 IO、淘汰策略 LRU
2. 分布式缓存 Redis 做兜底存储
3. 布隆过滤器拦截不存在数据（防穿透）
4. 热点 key 分布式锁 + 重试（防击穿）
5. 缓存过期随机偏移（防雪崩）
6. Lua 脚本统一缓存操作，保证原子性

生活化通俗举例

超市货架分层放商品：

1. 收银台手边小货架（Caffeine 本地缓存）：高频热销商品，随手就能拿，不用跑仓库；
2. 后方大仓库（Redis）：存放全部商品，需要走一段路调取；
3. 门口安检黑名单（布隆过滤器）：顾客要买不存在的商品，直接拦在门外，不用去仓库翻找；
4. 爆款限量商品抢购（热点 key）：一次只放一个购买名额锁，防止所有人同时冲进仓库抢空；
5. 商品保质期错开设置（过期随机偏移）：不会同一天全部商品过期下架，仓库瞬间爆满。

架构流程图

优化前后对比表格

优化前痛点

1. 仅单层 Redis，每次查询走网络 IO，延迟高；
2. 无布隆过滤器，空手机号大量穿透数据库；
3. 热点营销 key 并发击穿 MySQL；
4. 缓存同时过期，定时活动雪崩。

落地改造方案

1. Caffeine 本地缓存 + Redis 二级缓存架构；
2. 启动预加载有效手机号至布隆过滤器，拦截无效查询；
3. 热点 key 加分布式锁 + 短休眠重试，避免击穿；
4. 所有缓存 key 过期时间随机 ±30 分钟，打散过期峰值。

模块小结

二级缓存优先读取本地内存减少网络开销，搭配布隆过滤器、分布式锁、随机过期三大方案一次性解决缓存穿透、击穿、雪崩三大经典问题，有明确线上量化性能提升。

RabbitMQ 多级死信 + msgId 幂等，千万短信异步削峰推送

核心技术知识点

1. RabbitMQ 同步转异步解耦、批量投递削峰
2. 业务队列本地有限次数重试机制
3. 独立死信队列兜底重试，失败消息归档 MySQL
4. 全局唯一 msgId 生成规则（商户 ID + 活动 ID + 手机号 + 时间戳）
5. Redis+Lua 原子幂等校验，重复消息拦截
6. 消息持久化、生产者确认保障消息不丢失

生活化通俗举例

奶茶店接单配送改造：

改造前：顾客下单，店员当场现做 + 亲自送货，高峰期订单挤满，店员全部被占用，后面顾客排队卡死；配送没人签收直接丢掉订单，同一顾客重复下单会重复送两杯。

改造后：

1. 前台只写订单丢进收纳筐（MQ 队列），立刻接待下一位顾客（异步削峰）；
2. 配送员取单配送，第一次没人签收重试 5 次（本地重试）；
3. 5 次失败丢进退货筐（死信队列），晚上专人统一再试 3 轮兜底；
4. 每张订单有专属单号 msgId，配送前先查登记本，送过的单直接跳过（幂等防重复）；
5. 订单全部纸质存档，筐子上锁，不会弄丢任何订单（持久化）。

全链路流转流程图

优化前后对比表格

优化前痛点

1. 同步调用短信通道，长时间占用 Tomcat 线程，峰值消息严重堆积；
2. 无重试、死信机制，网络波动直接丢失短信；
3. MQ 重复投递无幂等控制，同一用户收到多条相同营销短信，大量投诉。

落地改造方案

1. 同步下发改为 RabbitMQ 异步架构，批量消息分批投递实现流量削峰；
2. 业务队列配置最多 5 次本地递增重试，达到上限转入专属死信队列；
3. 定时任务消费死信队列执行 3 轮兜底重试，多次失败消息归档 MySQL 支持手动补发；
4. 基于商户、活动、手机号、时间戳拼接全局 msgId，消费前通过 Lua 脚本原子校验幂等，重复消息直接拦截；
5. 开启消息持久化、生产者 confirm 机制，保障消息零丢失。

模块小结

通过 MQ 异步解决同步线程耗尽、流量峰值堆积问题；多级重试 + 死信队列兜底保证短信不丢失；全局 msgId+Redis 幂等从消费层杜绝重复下发，整套方案支撑千万级日短信推送，有完整可量化业务优化指标。

冷热数据分层存储，千万日志 MySQL 迁移 ES

核心技术知识点

1. 冷热数据划分标准：热数据高频查询、冷数据海量明细检索
2. MySQL 存储短字段核心热数据，ES 存储海量日志冷数据
3. ES 按天分索引、索引生命周期管理自动清理过期数据
4. ES 联合倒排索引优化多条件模糊检索
5. MQ 异步批量写入 ES，不阻塞短信主业务链路
6. 查询分流：简单统计查 MySQL，复杂日志排查查 ES

生活化通俗举例

公司仓库记账改造：

改造前：所有销售小票、详细交易明细全部存在前台小保险柜（MySQL）。每天产生上万张单据，柜子很快塞满；要查半年前某一笔详细记录，需要翻完整柜子，耗费几十分钟。

改造后分两处存放：

1. 前台保险柜（MySQL 热数据）：只存订单号、手机号、发送状态等简短核心信息，日常快速查发送状态；
2. 大型档案库房（ES 冷数据）：存放完整回执、错误码、渠道耗时等全部明细；每天分新档案盒（按天分索引），7 个月前旧档案自动清理；
3. 专门后勤人员统一批量归档（日志 MQ 异步消费），不占用前台收银工作；
4. 只查是否发送成功去前台，查报错明细、批量筛选去档案库。

整体架构流程图

优化前后对比表格

优化前痛点

1. 短信执行日志单表千万行，多条件分页检索极慢；
2. 每日新增百万级日志，MySQL 磁盘暴涨，频繁磁盘告警；
3. 线上排查短信失败原因，检索日志耗时分钟级，定位问题效率极低；
4. 批量推送同步写入全量日志，瞬间打满 MySQL 磁盘 IO，所有业务接口卡顿。

落地改造方案

1. 冷热数据拆分：短状态热数据留存 MySQL，完整明细冷日志迁移 Elasticsearch；
2. ES 按天分索引，配置索引生命周期策略，7 天自动清理过期日志；
3. ES 对手机号、活动 ID、时间、错误码建立联合倒排索引，加速多维度检索；
4. 下发完成后完整日志走独立 MQ 异步批量写入 ES，与短信主链路解耦；
5. 业务查询做分流，简单统计走 MySQL，复杂明细检索走 ES。

模块小结

通过冷热分层将海量明细日志剥离 MySQL，利用 ES 擅长海量全文检索的特性解决大表慢查询、磁盘爆满问题；异步写入架构隔离主业务压力，极大缩短线上故障排查时间，数据库资源全部留给核心短信下发业务。

Quartz 持久化定时任务 + Redis 分布式锁解决集群重复调度

核心技术知识点

1. SpringTask 原生缺陷：单机内存运行、集群并发重复执行、无持久化
2. Quartz 定时框架：数据库持久化任务、可视化任务管理
3. Redis 分布式锁实现跨节点任务互斥执行
4. 锁超时 TTL 兜底，防止服务宕机死锁
5. 运营后台动态配置任务，无需重启服务生效

生活化通俗举例

门店定时大扫除场景

改造前：每家分店（集群服务节点）都设置凌晨 2 点闹钟，一到点所有店员同时打扫同一个仓库，重复干活，浪费人力，还重复整理出多份相同活动通知发给客户。

改造后：

1. 统一登记台账（Quartz 持久化到 MySQL），所有打扫计划全部存档，不会因为店员下班丢任务；
2. 打扫前先拿唯一钥匙（Redis 分布式锁），只有抢到钥匙的店员打扫，其他人直接下班；
3. 钥匙自带失效时间，如果店员打扫中途晕倒，超时自动归还钥匙，不耽误第二天打扫；
4. 店长后台直接改打扫时间、新增打扫计划，不用召集所有分店重新设置闹钟。

任务完整流转流程图

优化前后对比表格

优化前痛点

1. SpringTask 基于本机内存，集群多节点同时触发同一任务，重复筛选人群、重复生产短信；
2. 定时任务仅内存存储，服务重启直接丢失营销推送计划；
3. 无可视化管理，调整推送时间、新增活动任务必须重启服务，中断业务。

落地改造方案

1. 替换原生 SpringTask，引入 Quartz 框架，任务信息持久化存储 MySQL；
2. 定时任务执行前争抢全局唯一 Redis 锁，保证同一任务同一时间仅单个节点执行；
3. 分布式锁设置合理 TTL 超时时间，防止节点宕机造成永久死锁；
4. 开发运营可视化后台，支持任务启停、推送时间、人群条件在线修改，实时生效。

模块小结

用 Quartz 解决定时任务丢失、不可管控问题，搭配 Redis 分布式锁解决集群多节点重复调度的核心痛点，从消息生产源头杜绝重复短信，无人工停机发布，大幅减少重复短信带来的客户投诉与通道成本损耗。

Sentinel 多维度限流熔断，多短信通道自动故障切换

核心技术知识点

1. Sentinel 流量防护核心能力：限流、熔断降级、热点参数限流、系统保护
2. 多维度流量管控：手机号、商户、IP 三层独立限流规则
3. 熔断半开探测机制，故障通道自动隔离
4. 多短信服务商通道集群，熔断后自动路由备用线路
5. 通道全故障时消息转入死信队列兜底存储

生活化通俗举例

外卖配送门店风控改造

改造前：不限制下单人数，大量黄牛批量下单占满配送员；某配送骑手全部订单超时、丢单，门店依旧不停派单，所有订单全部积压，顾客全收不到餐。

改造后：

1. 单人、单个公司、单个地址每日下单次数做上限（手机号 / 商户 / IP 限流），防止黄牛刷单；
2. 某个骑手频繁超时就暂时停止派单给他（熔断），隔一段时间少量试单测试是否恢复（半开探测）；
3. 同时合作多家骑手团队，一个团队故障，订单自动分给其他骑手；
4. 所有骑手都忙不过来时，订单统一登记延后配送（死信队列）。

完整业务流程图

优化前后对比表格

优化前痛点

1. 无任何流量防护，爬虫批量刷短信接口，大量无效请求压垮服务与第三方通道；
2. 仅单条短信通道，通道超时、报错时全部营销任务阻塞，服务不可用；
3. 未区分商户、手机号、IP 做分层限流，恶意客户占用大量短信额度，正常用户短信延迟。

落地改造方案

1. 接入 Sentinel 组件，针对短信接口、第三方通道接口配置独立限流、熔断规则；
2. 三层限流管控：单手机号验证码 / 营销短信频次、商户每日短信总额度、客户端 IP 访问频次；
3. 对接多家第三方短信通道，通道触发熔断后自动路由至备用线路；
4. 熔断配置半开探测窗口期，自动恢复已修复通道；
5. 所有通道全部故障时，消息转入死信队列，后续定时重试补发。

模块小结

Sentinel 从入口拦截恶意流量，通过熔断隔离故障短信通道，搭配多通道自动切换实现故障无感恢复，彻底解决第三方通道雪崩、恶意流量挤占资源问题，保障营销短信业务稳定运行。

Nacos 配置中心热更新，业务配置动态生效无需重启服务

核心技术知识点

1. Nacos 配置中心：配置统一托管、Namespace 环境隔离
2. SpringBoot @RefreshScope 注解实现 Bean 动态刷新
3. 短信额度、限流阈值、通道密钥等业务配置云端存储
4. 配置变更实时推送，毫秒级热生效
5. 区分开发 / 测试 / 生产多环境配置隔离，避免配置污染

生活化通俗举例

奶茶店价目表改造

改造前：所有饮品定价、限购规则全部打印贴墙，要改价格 / 限购数量，必须停业重新打印张贴，顾客暂时无法下单，一次调整要折腾半小时。

改造后：

1. 统一后台电子价目表（Nacos 云端配置），分店共用一套配置，区分门店测试区、营业区（Namespace 隔离）；
2. 店长后台直接修改价格、限购规则，点击保存立刻全门店生效；
3. 不用关门、不用重启收银机器，顾客下单不受任何中断；
4. 渠道对接密码、每日活动发放上限统一存在后台，不需要写死在收银机程序里。

配置加载与热更新流程图

优化前后对比表格

优化前痛点

1. 短信通道密钥、限流阈值、营销额度硬编码在项目配置文件，修改必须重新打包、重启服务；
2. 每次调整规则需要停机发布，业务出现长时间空档；
3. 开发、测试、生产环境配置混在一起，容易误改线上参数引发故障；
4. 密钥写在本地配置文件，代码上传仓库存在明文泄露安全隐患。

落地改造方案

1. 将限流规则、信渠道密钥、单日推送上限、重试次数全部迁移至 Nacos 统一托管；
2. 划分不同 Namespace 隔离开发、测试、生产三套环境，配置互不干扰；
3. 业务配置类添加 @RefreshScope 注解，支持配置动态刷新；
4. 利用 Nacos 加密配置存储通道密钥，避免明文落地本地；
5. 运营人员直接在 Nacos 控制台修改参数，发布后全服务实时生效。

模块小结

通过 Nacos 统一托管全量业务配置，依靠 @RefreshScope 实现配置热更新，彻底解决修改配置需要重启服务、业务中断的问题，同时多环境隔离规避配置混淆故障，兼顾运维效率与线上稳定性。

Docker Compose 容器化统一环境，消除环境差异问题

核心技术知识点

1. Docker：业务服务镜像打包，环境与代码绑定
2. Docker Compose：一键编排 MySQL、Redis、RabbitMQ 全套中间件
3. 开发 / 测试 / 生产环境标准化，依赖版本统一
4. 新人本地环境一键启动，无需手动安装中间件
5. 规避因环境版本不一致导致的线上兼容 Bug

生活化通俗举例

连锁餐饮店标准化后厨工具

改造前：每家分店后厨工具需要厨师单独采购、安装调试，有人买老款烤箱、有人新款，做出来菜品口味不一样；新人上岗要花大半天配齐所有厨具。

改造后：

1. 总部统一成套厨具集装箱（Docker 镜像），每家分店全部同款设备；
2. 一套包装箱包含烤箱、冷藏柜、操作台等全套工具（Compose 编排所有中间件）；
3. 新人直接开箱即用，10 分钟配齐后厨，不用挨个采购调试；
4. 全国分店设备完全一致，菜品出品标准统一，不会出现奇怪故障。

环境搭建完整流程图

优化前后对比表格

优化前痛点

1. 开发环境需要手动逐个安装 MySQL、Redis、RabbitMQ，配置端口、账号，耗时极久；
2. 开发、测试、生产中间件版本不统一，本地运行正常，上线出现兼容异常；
3. 不同开发人员本地配置五花八门，出现 bug 很难复现定位；
4. 新人入职需要耗费半天时间搭建环境，上手效率极低。

落地改造方案

1. 编写项目 Dockerfile，将 Java 业务服务打包为标准化镜像；
2. 编写 docker-compose.yml 统一编排 MySQL、Redis、RabbitMQ 中间件容器；
3. 统一固定所有中间件版本，开发、测试、生产保持版本一致；
4. 提供一键启动脚本，新人拉取代码后一条命令拉起全套环境；
5. 测试环境、预发环境全部使用相同镜像部署，保证环境无差异。

模块小结

借助 Docker 镜像固化运行环境，Docker Compose 实现中间件一键编排，统一全环境依赖版本，大幅降低开发环境搭建成本，彻底解决 “本地正常线上报错” 的环境兼容类故障，提升开发与测试整体效率。

JVM 堆内存参数调优，降低 Full GC 频率与接口卡顿

核心技术知识点

1. JVM 堆内存参数 Xms、Xmx 原理，堆内存伸缩带来性能损耗
2. 新生代 Eden、Survivor 分区分配规则，新生代占比调优
3. Minor GC、Full GC 触发条件，频繁 GC 对接口响应的影响
4. GC 日志打印、OOM 自动 dump 文件，线上内存问题排查手段
5. 老年代内存泄漏监控，提前发现堆内存持续上涨隐患

生活化通俗举例

办公室储物间改造

改造前：储物间最小面积和最大面积差距很大，东西一多就要临时扩建，扩建期间所有人不能放东西、等待卡顿；储物区留给短期杂物的空间太小，垃圾频繁清理，不停中断办公。

改造后：

1. 储物间固定统一大小，一开始直接给到最大面积，不用反复扩容；
2. 短期临时杂物区占整体三分之一，减少频繁打扫清理；
3. 全程监控储物间占用量，一旦堆满自动留存全部物品清单方便排查；
4. 不会出现频繁停工打扫，员工办事不再排队卡顿。

JVM 内存分区与 GC 调优流程图

优化前后对比表格

优化前痛点

1. Xms 远小于 Xmx，程序运行时频繁扩容堆内存，产生长时间 STW 停顿；
2. 新生代内存分配过小，Eden 区快速占满，Minor GC 频繁，接口偶发延迟卡顿；
3. 未开启 GC 日志、OOM 快照，出现内存溢出、长时间 GC 时无任何排查依据；
4. 老年代持续内存泄漏无法提前感知，容易引发服务卡死、宕机。

落地改造方案

1. 统一配置 Xms = Xmx，固定堆内存大小，消除运行期堆扩容；
2. 新生代设置为堆总内存 1/3，提升短期对象容纳量，减少 Minor GC 频次；
3. 启动参数开启完整 GC 日志持久化存储，记录每次 GC 耗时、回收内存大小；
4. 配置 OOM 时自动 dump 堆快照文件，用于事后离线分析内存泄漏；
5. 监控老年代内存增长曲线，提前预警内存持续上涨隐患。

模块小结

通过固定堆内存、合理分配新生代空间，从根源减少 Minor GC 与 Full GC 次数，降低 GC 停顿造成的接口卡顿；配套 GC 日志与 OOM dump 能力，提供完整线上内存故障排查依据，提升服务运行稳定性。

智能营销千万级短信平台全链路整合优化

核心技术知识点总览

整套系统由 8 大优化技术体系串联，全链路覆盖请求入口→缓存层→定时任务生产消息→MQ 异步推送→流量熔断防护→第三方通道调用→日志冷热存储→配置动态管控→底层 JVM 容器环境，完整闭环：

1. 接入层：Nacos 动态配置 + Sentinel 多维度限流熔断防护
2. 缓存层：Caffeine+Redis 二级缓存 + 布隆过滤器解决缓存三大问题
3. 任务生产层：Quartz 持久化定时任务 + Redis 分布式锁防集群重复生成短信
4. 消息异步层：RabbitMQ 异步削峰、多级死信重试、全局 msgId 幂等防重复下发
5. 通道调用层：多短信服务商通道自动切换、故障隔离
6. 数据存储层：冷热数据分离，MySQL 存业务热状态、ES 存储海量短信执行日志
7. 底层运维层：Docker Compose 容器标准化开发测试环境
8. 底层 JVM 层：堆内存参数调优，减少 GC 停顿，提升服务稳定

生活化完整串联举例

连锁奶茶门店完整改造流程

改造前：门店单机经营，接单、制作、配送、记账全部同步操作；价格规则写死机器，改价必须关门；后厨多人重复做同款饮品；大量小票全部堆在前台小账本；配送员单一、经常爆单卡顿；后厨设备版本杂乱；后厨储物间分配不合理频繁大扫除卡顿。

完整改造后全流程：

1. 门店规则统一后台管理（Nacos），限购、定价、配送额度实时修改不用停业；
2. 门口前台设置限流风控（Sentinel），限制单人单日购买次数，黄牛批量下单直接拦截；
3. 热销饮品放在前台随手货架（Caffeine 本地缓存），冷门商品仓库调取（Redis），不存在的饮品直接拦下（布隆过滤器）；
4. 定时活动奶茶统一排班制作（Quartz 定时任务），一把专属制作钥匙（分布式锁）保证同一批饮品只做一次；
5. 顾客订单统一放入收纳筐异步制作配送（RabbitMQ），每张订单唯一单号（msgId）避免重复配送；配送失败最多重试 5 次，多次失败丢入退货筐夜间兜底补发；
6. 合作多家配送骑手（多短信通道），某骑手频繁超时自动切换其他骑手；
7. 订单简短状态记前台小账本（MySQL 热数据），完整配送回执存入大型档案库（ES），查详情去档案库；
8. 全部门店统一标准化厨具套装（Docker Compose），新人 10 分钟配齐环境；
9. 后厨储物间固定大小、合理分区（JVM 调优），减少频繁打扫卡顿，保证营业流畅。

全链路完整总流程图

八大模块整体优化前后总对比汇总表

全链路整体综合业务成果总结

整套八大优化方案串联落地后，平台整体能力得到质的提升：

1. 业务承载：日短信推送量从 10 万条提升至 1000 万条，并发承载能力扩大 10 倍；
2. 性能指标：全链路接口平均响应 320ms 优化至 62ms，整体性能提升 80.6%；
3. 稳定性：缓存雪崩、通道故障、重复短信、数据库 IO 打满、频繁 GC 等线上故障全年清零；
4. 服务可用性：系统全年可用率达到 99.99%；
5. 运维效率：配置修改、环境搭建、故障排查、任务发布全流程运维效率大幅提升，人工维护成本显著下降。