内容Seata AT、Sentinel、QLExpress、DockerCompose 四大核心技术 Redis 底层、CaffeineRedis 二级缓存、缓存三大问题Seata AT 分布式事务AT 模式三阶段完整执行流程一阶段执行业务本地事务执行业务 SQL新增 AI 短信记录、扣商户额度同步生成 undo 回滚日志存入库提交本地 MySQL 事务给对应业务行加锁此时数据入库但全局事务未结束外部其他服务看不到本次修改。二阶段提交TC 事务协调器通知分支提交服务删除本地 undo 日志释放行锁数据对外完全可见。二阶段回滚TC 通知分支回滚读取 undo 日志生成反向补偿 SQL撤销一阶段所有增删改数据释放行锁恢复到执行前状态。项目落地业务场景批量 AI 短信生成、定时营销任务需要同时操作三张数据短信生成记录表、商户额度表、Redis 缓存额度。若不加 Seata AT会出现短信记录插入成功、商户额度扣减 SQL 报错导致商户免费下发短信数据不一致。添加GlobalTransactional全局事务注解保证多库操作原子性要么全成功、要么全撤销。AT / TCC / SAGA 三种分布式事务对比方案代码侵入度锁机制适用场景项目选用原因AT极低仅注解行锁同步锁MySQL 同步数据库操作短信平台以 MySQL 为主开发成本低TCC极高需手写 Try/Confirm/Cancel无数据库锁业务自定义对接第三方支付、非关系型存储项目几乎不用开发工作量大SAGA中等手动写补偿逻辑无锁最终一致性超长异步流程、跨异构系统批量异步任务极少使用一致性弱线上高频失效踩坑点方法不是 public、同类内部调用全局事务失效多数据源未配置 Seata 代理数据源MQ 异步、子线程无法传递全局事务上下文undo 日志长期堆积需定时清理 undo 表。项目排查和问题处理1.使用 Seata AT 分布式事务出现「短信记录入库成功商户额度扣减失败」数据不一致请写出完整排查思路。第一步检查业务方法上是否添加GlobalTransactional全局事务注解无注解则完全不生效第二步校验当前事务方法访问修饰符必须是 public如果是 private /protected/ 同类内部自调用Spring AOP 无法生成代理全局事务直接失效第三步查看日志定位扣减额度 SQL 抛出的异常确认异常是否被try-catch捕获且没有主动抛出被吞掉的异常不会触发 Seata 回滚第四步核对项目多数据源配置是否全部使用 Seata 代理数据源未代理的库操作不参与全局事务第五步查询 undo_log 回滚日志表确认一阶段是否正常生成回滚记录第六步排查是否存在异步 MQ、新开子线程执行扣减逻辑子线程无法传递全局事务上下文事务隔离第七步观察 TC 事务协调器日志查看二阶段是提交指令还是回滚指令定位异常分支。2.简述 Seata AT 一阶段、二阶段提交、二阶段回滚分别做了哪些核心操作一阶段执行业务增删改 SQL同步生成 undo 日志里面存反向补偿 SQL提交本地 MySQL 事务同时对操作的数据加行锁此时外部看不到本次修改的数据。二阶段提交TC 事务协调器收集所有 RM 分支执行状态全部无异常则通知各分支删除本地 undo 日志、释放行锁修改后的数据对外可见。二阶段回滚只要任意分支执行异常TC 下发回滚指令RM 读取 undo 日志里的反向 SQL 执行数据恢复完成后释放行锁undo 日志会做归档清理。3.结合咱们营销短信平台业务说一说项目为什么选择 Seata AT而不用 TCC、SAGA我们平台核心业务都是 MySQL 同步落库场景所以优先选用 Seata ATAT 侵入极低仅需在方法上加GlobalTransactional注解框架自动生成 undo 日志实现事务控制几乎不用改动原有业务代码开发维护成本低TCC 侵入性极强需要手动编写 Try、Confirm、Cancel 三段逻辑代码改动量大适合对接第三方支付、非数据库异构场景我们项目没有这类需求SAGA 无锁、依靠手动补偿适合超长异步业务流程一致性偏弱我们短信下发、AI 文案生成都是短同步事务追求强一致完全不匹配 SAGA 适用场景。Sentinel 限流熔断熔断三大状态流转关闭 Closed接口正常运行持续统计 QPS、超时率、异常比例指标未超阈值请求直接放行。打开 Open异常 / 超时占比超过阈值熔断器开启直接拒绝所有请求执行降级逻辑防止雪崩拖垮服务。半开 Half-Open冷却窗口期结束放行少量探测流量探测请求正常→切回关闭探测仍报错→重回打开。三种限流算法对比算法特点项目使用场景滑动窗口精准统计固定时间窗口流量粒度细Sentinel 单机限流、Redis Lua 集群限流主力漏桶流出速率固定削峰无法应对突发流量MQ 消费者批量消费控并发令牌桶可积累令牌允许瞬时突发高并发大促活动临时扩容流量场景项目落地场景网关层后台/admin/**接口全局粗粒度限流防止运营并发压垮服务AI 大模型、第三方短信通道接口配置熔断设计三级降级验证码接口手机号、IP 防刷限流配置持久化限流熔断规则统一存 Nacos支持热更新控制台仅用来监控不存储生产规则。AI 接口三级降级策略1 级降级切换备用大模型2 级降级读取 MySQL 预制短信模板3 级降级返回通用 “系统繁忙” 兜底提示。集群限流兜底方案Redis Lua 分布式滑动窗口实现全集群统一限流若 Redis 宕机自动切换 Sentinel 本地内存限流兜底避免裸跑无防护。项目排查和问题处理1.项目对接第三方 AI 大模型频繁超时如何使用 Sentinel 做服务保护首先我们会给 AI 生成接口单独定义 Sentinel 资源标识持续统计接口的响应超时率、异常比例限流管控配置接口整体 QPS 限流也支持热点参数限流限制单商户、单 IP 的调用频次避免单个客户疯狂调用占用资源限流阈值统一放在 Nacos 可动态调整熔断保护当大模型接口超时、报错占比超过设定阈值熔断器直接打开不再持续调用不稳定的第三方 LLM避免大量超时请求堆积拖垮我们自身服务三级降级兜底熔断触发后依次执行降级策略优先切换备用大模型备用模型不可用就读取 MySQL 预制合规短信模板两种方案都失效则返回 “系统繁忙请稍后重试” 友好提示故障兜底分布式限流依赖 Redis Lua一旦 Redis 宕机自动切换 Sentinel 本地内存限流保证接口始终有防护不会裸跑。2.简述滑动窗口、漏桶、令牌桶三种限流算法的特点以及项目各自使用场景。滑动窗口特点将时间切分为多个小段滚动统计流量统计粒度细能精准识别短时间突发流量避免临界流量误放行 项目场景Sentinel 单机本地限流、Redis Lua 集群统一限流平台主流限流方案。漏桶算法特点流出速率恒定无论请求涌入多快都以固定速度处理强制削峰无法应对瞬时突发流量 项目场景RabbitMQ 消费者批量拉取消息控制批量 AI 生成任务的消费速度防止一次性压垮向量库与大模型。令牌桶算法特点系统匀速生成令牌存入桶内空闲时段令牌可累积突发高并发时能一次性取出存量令牌支持瞬时流量峰值 项目场景营销大促活动允许短时间爆发式请求适配活动流量突增场景。3.我们项目 Redis 宕机后限流不会完全失效依靠什么兜底方案逻辑是什么项目采用双层限流兜底架构正常情况下通过 Redis Lua 滑动窗口实现集群统一限流保证多实例流量管控标准一致一旦 Redis 宕机、无法访问系统自动降级切换到 Sentinel 本地内存限流单机独立统计接口流量避免服务完全裸跑无防护保障接口基础限流能力不丢失。QLExpress 规则引擎硬编码 if/else 人群筛选的痛点如果客户分群、营销筛选逻辑写死在代码里新增、修改筛选条件必须改代码、打包发版、重启服务迭代周期长运营无法自主配置规则开发工作量大。QLExpress 核心能力可视化页面拖拽配置表达式运营不用写代码就能自定义人群筛选条件内置安全沙箱拦截危险执行语法杜绝表达式注入安全风险表达式本地缓存重复执行不用重复解析提升批量圈选人群性能支持逻辑判断、数值区间、多条件组合完全匹配客户分层业务。项目落地场景批量定时营销任务中运营在后台配置人群筛选表达式执行定时推送时通过 QLExpress 动态解析规则批量圈选出符合条件的目标客户无需开发介入发版迭代。项目排查和问题处理1.项目为什么不用 if-else 硬编码做人群筛选选择 QLExpress业务里营销人群筛选规则变动十分频繁如果用 if-else 硬编码实现每次新增、修改筛选条件都需要开发改代码、打包、发版、重启服务迭代周期长占用大量开发人力。 引入 QLExpress 后解决了这些痛点后台提供可视化拖拽页面运营可以自主配置筛选表达式不用依赖开发、无需发版就能调整人群规则内置安全沙箱限制危险语法执行防止表达式注入带来安全漏洞表达式做本地缓存批量圈选人群时不用重复解析提升批量筛选性能支持多条件逻辑、区间判断等各类筛选语法完全适配我们客户分层、营销圈人业务。2.QLExpress 安全沙箱有什么作用对应项目什么安全风险QLExpress 内置安全沙箱机制会拦截危险、非法语法通过黑白名单管控可执行方法与操作我们项目运营自主编写筛选表达式如果没有沙箱限制恶意表达式可能执行文件读写、反射等高危操作造成表达式注入漏洞威胁服务安全沙箱能隔离这类风险只开放业务允许的逻辑判断、数值计算语法从源头避免恶意表达式攻击。DockerCompose 容器编排核心作用依靠一份 yml 配置文件一条命令就能一键拉起项目全套中间件MySQL、Redis、RabbitMQ、PgVector、ES自动完成端口映射、容器网络创建、数据持久化挂载。落地业务价值统一团队所有人本地开发环境规避中间件版本不一致引发的各种诡异 bug新人上手成本极低无需手动下载安装、配置各类中间件拉取项目后直接启动 compose 即可区分环境隔离开发、测试环境可通过不同 compose 配置快速切换。Docker / DockerCompose / K8s 三者定位区分表格工具核心定位使用场景Docker容器引擎打包单个应用镜像打包业务服务、单独启动单个中间件DockerCompose单机多容器编排工具本地开发、小型测试环境单机管理一组容器K8s分布式集群容器编排平台线上生产大规模集群服务部署、扩缩容、自愈项目排查和问题处理1.本地开发环境为什么不直接在 Windows 系统手动安装 MySQL、Redis而是选用 DockerCompose如果团队成员在 Windows 本地手动安装 MySQL、Redis 等中间件很容易出现中间件版本、配置参数不统一的问题经常出现本地运行正常提交代码到测试环境就报错的环境差异 bug。 使用 DockerCompose 有几点核心优势统一约束所有中间件版本与配置团队所有人本地环境完全一致规避环境差异类 bug新人上手简单不用手动下载、安装、配置各类中间件一条命令就能启动整套依赖支持多套 yml 配置快速隔离开发、测试两套环境切换方便自动完成端口映射、数据持久化、容器网络配置省去大量手动配置工作。2.简述 DockerCompose 核心作用以及它的配置文件是什么DockerCompose 是单机多容器编排工具核心作用通过一份统一配置文件一键批量启动、管理项目所需全部中间件容器自动处理网络、端口、数据持久化统一团队开发环境。 配置文件固定名称为docker-compose.yml。Redis 全套底层 CaffeineRedis 二级缓存Redisson 分布式锁核心原理底层通过 Lua 脚本实现加锁、解锁保证操作原子性支持可重入锁记录持有锁的线程标识同一线程多次加锁不会死锁看门狗自动续期长任务后台自动延长锁过期时间防止任务没执行完锁提前释放RedLock 红锁机制过半 Redis 节点加锁成功才算拿到锁解决主从切换锁丢失问题项目用于 Quartz 集群定时任务防重复执行。原生 SETNX 锁四大缺陷不可重入、无自动续期、解锁非原子操作、主从切换锁丢失项目全部用 Redisson 替代原生方案。Lua 脚本原子性项目落地场景Redis Lua 滑动窗口多维度限流手机号、商户 ID、IPRedLock 分布式锁加解锁逻辑批量更新商户额度缓存多条缓存操作保持原子执行。Redis 在项目中的使用场景分布式锁、分布式限流、JWT 黑名单、布隆过滤器、二级分布式缓存、接口幂等校验、计数器。缓存三大问题穿透 / 击穿 / 雪崩完整方案缓存穿透现象查询数据库不存在的数据缓存无记录请求全部打穿到 MySQL压垮数据库 业务场景恶意请求不存在的商户 ID、无效手机号 解决方案前置布隆过滤器拦截无效 key空值短期缓存接口参数合法性校验缓存击穿现象热点 key 过期瞬间大量并发请求同时查询数据库 业务场景高热度商户额度配置高频查询 解决方案热点 key 永不过期分布式锁控制单线程查库回填缓存缓存雪崩现象大量 key 同一时刻过期Redis 整体宕机流量全部涌向 MySQL 解决方案过期时间随机偏移CaffeineRedis 多级缓存接口限流熔断Redis 集群高可用CaffeineRedis 二级缓存完整查询链路查询顺序优先读取 Caffeine 本地缓存进程内存无网络 IO速度最快→未命中查询 Redis 分布式缓存→两级都未命中才查询 MySQL查询成功双向回填两级缓存。 优势Caffeine 拦截大部分热点请求大幅减少 Redis 网络请求Redis 保证多服务实例之间缓存数据一致双重兜底Redis 故障时本地缓存仍可提供基础数据访问。生活化举例Redisson 分布式锁把锁想象成卫生间钥匙SETNX 是一次性钥匙进去之后没法再开门中途超时钥匙自动消失Redisson 可重入锁支持同一个人反复进出看门狗相当于定时续时防止洗澡没结束门锁自动打开RedLock 相当于多间卫生间超过一半房间拿到钥匙才算占用避免主卫生间故障导致锁失效。缓存三大问题穿透不停查不存在的物品仓库没有就全都去翻数据库库房库房被挤爆布隆过滤器相当于门卫不存在的物品直接拦在门外。击穿爆款商品标签刚好过期所有人同一时间冲去库房给标签永久保存或者只放一个人去库房更新。雪崩所有商品标签同时过期瞬间所有人冲进库房每个商品过期时间错开同时办公桌存一份备份。项目排查和问题处理1.原生 SETNX 实现分布式锁存在哪些缺陷项目为什么选用 Redisson原生 SETNX 分布式锁四大缺陷不可重入同一个线程多次加锁会直接死锁不支持嵌套调用无自动续期任务执行时长超过锁过期时间锁会提前释放并发错乱解锁非原子性先判断持有者再删除锁并发场景下极易误删别人的锁主从切换锁丢失主节点拿到锁还未同步给从节点就宕机新主节点不存在该锁出现并发安全问题。Redisson 全部补齐以上痛点自带可重入锁、看门狗自动续期、Lua 脚本保证加解锁原子性、提供 RedLock 红锁规避主从锁丢失风险开发开箱即用稳定性更强因此项目统一使用 Redisson。2.分别说明缓存穿透、缓存击穿、缓存雪崩三者区别以及各自对应的解决办法。1. 缓存穿透现象请求一直查询 Redis、MySQL 都不存在的数据缓存永远无法留存数据大量请求持续直达数据库压垮 MySQL大多是恶意刷无效 ID、手机号造成。解决方案前置布隆过滤器提前拦截不存在的 key查询为空时在 Redis 写入短期空值缓存接口前置参数校验过滤非法参数。2. 缓存击穿现象单个超高热度缓存 key 到期一瞬间海量并发请求同时绕过缓存涌向数据库。解决方案热点 key 设置永不过期使用分布式锁仅放行一个请求去数据库查询并回填缓存其余请求等待缓存刷新完成。3. 缓存雪崩现象分两种① 大批量缓存 key 集中同一时间过期流量瞬间全部打入数据库 ② Redis 集群整体宕机缓存彻底失效请求全部访问 MySQL。解决方案给过期时间加上随机偏移值错开批量过期时间搭建 CaffeineRedis 二级缓存Redis 故障时本地缓存兜底Redis 做主从集群保证高可用搭配 Sentinel 限流熔断限制打库流量。三者核心区分 穿透查不存在的数据击穿单个热点 key 过期雪崩大批 key 集体过期 / Redis 整体瘫痪3.项目引入 CaffeineRedis 二级缓存有什么好处1.访问速度大幅提升Caffeine 属于进程内本地内存缓存无网络 IO 开销绝大多数热点请求可直接命中本机缓存响应速度远快于 Redis大幅降低接口耗时。2.削减 Redis 压力与网络开销高频热点数据常驻本地缓存不必频繁和 Redis 交互有效减轻 Redis 集群负载节省内网网络传输损耗。3.多重防护抵御缓存异常场景缓解缓存雪崩大量 key 集中过期或 Redis 宕机时本地 Caffeine 依旧可以兜底提供数据访问缓解缓存击穿热点数据留存本地规避热点 key 过期瞬间流量涌入数据库 搭配限流策略一起给数据库多层防护。4.兼顾分布式数据一致本地 Caffeine 负责高速访问Redis 统一存储集群共享数据服务实例间数据以 Redis 为准兼顾性能与分布式一致性。JVM 调优 OOM 问题排查JVM 内存区域划分1.堆 Heap存放所有对象实例分新生代Eden、S0、S1 老年代GC 主要回收区域OOM 最常发生在这里。2.虚拟机栈每个线程私有存放局部变量、方法调用栈帧栈太深会栈溢出 StackOverflowError。3.本地方法栈支撑 native 本地方法调用。4.程序计数器记录线程执行字节码位置唯一一个无 OOM 的内存区域。5.元空间 Metaspace存放类信息、常量、静态变量、字节码JDK8 取消永久代改用元空间直接使用操作系统内存。新生代 GC 流程复制算法新对象优先分配在 Eden 区Eden 满了触发 Minor GC存活对象复制到空闲 Survivor 区两个 Survivor 来回交换存放存活对象对象熬过 15 次 Minor GC 晋升到老年代 大对象直接进入老年代避免新生代来回复制开销。常见 OOM 四种场景 诱因1.Java heap space 堆内存溢出最普遍集合无限添加对象未释放、大文件一次性读取加载、缓存无上限堆积。2.Metaspace 元空间溢出频繁动态创建类、动态代理大量生成 class、热部署频繁重载类。3.栈溢出 StackOverflowError递归深度过大、方法循环调用无终止条件。4.直接内存 Direct Buffer 溢出Netty、NIO 大量使用堆外内存未主动释放。线上 OOM 排查标准步骤发生 OOM 时开启-XX:HeapDumpOnOutOfMemoryError自动导出堆快照 dump 文件使用 MAT 内存分析工具导入 dump 文件查看内存占用最大对象、引用链定位代码里未释放的集合 / 缓存 / 大资源修复代码逻辑、调整 JVM 参数、限制缓存容量。项目 JVM 基础参数配置示例Xms初始堆内存Xmx最大堆内存两者设一致避免运行时堆扩容消耗性能Xmn新生代大小SurvivorRatioEden 和 Survivor 比例MetaspaceSize元空间初始大小生活化举例JVM 内存好比办公仓库堆内存 开放式大储物区绝大部分货物对象都放这里堆满就要清理垃圾GCEden 区 临时置物桌新东西先放桌面满了收拾一遍常用物品搬到储物架Survivor老年代 固定储物柜长期不用但还要保留的物品放这里虚拟机栈 每个人手边笔记本记录当下工作步骤写太多本子装不下就栈溢出元空间 产品说明书档案柜存放各类产品图纸类字节码。OOM 就是仓库彻底塞满再也放不下货物必须清理无用货品、扩容仓库或者改掉疯狂囤货的代码。项目排查和问题处理1.JDK8 为什么废弃永久代改用元空间 Metaspace永久代存在哪些弊端永久代PermGen弊端永久代属于 JVM 堆内存的一部分内存上限固定很难预估所需大小设置过小容易频繁 Full GC 甚至溢出设置过大又造成内存闲置浪费永久代内存回收复杂类卸载条件严苛热部署、动态代理、频繁加载类的场景极易出现永久代溢出不同 JDK 版本永久代大小参数不一致兼容性差。JDK8 替换为元空间 Metaspace 的原因元空间直接使用本地操作系统内存不再占用 JVM 堆内存理论上限是物理内存大幅降低溢出概率元空间会动态伸缩内存无需人为精准预估容量运维更省心优化了类加载与卸载机制Spring 热部署、动态创建类、反射代理等场景更稳定统一了不同平台内存管理逻辑跨系统兼容性更好。2.线上出现java.lang.OutOfMemoryError: Java heap space堆内存溢出完整排查流程是什么1.提前配置 JVM 启动参数项目启动时预先加上参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/xxx/dump一旦触发堆 OOMJVM 会自动生成堆快照 dump 文件留存现场内存数据。2.下载 dump 文件使用 MAT 工具解析将 dump 文件拉取至本地借助 Eclipse MAT 内存分析工具打开快照。3.定位内存泄漏根源查看内存占用排行最高的对象追踪对象引用链找出长期持有对象却未释放的代码位置常见为无限扩容的 List/Map 集合、无上限缓存、一次性读取超大文件、大对象常驻内存等。4。落地优化方案代码层面清理无用集合、读取文件采用流式分批加载、给本地缓存设置最大容量与淘汰策略JVM 参数层面合理调整堆初始值 Xms、最大值 Xmx新生代配比架构层面超大批量数据拆分处理避免一次性加载至内存。5.上线验证优化后观察 GC 日志、堆内存走势、FullGC 频次确认 OOM 不再复现。3.简述 Minor GC 和 Full GC 的触发时机以及二者区别一、触发时机1.Minor GC新生代 GCEden 区内存被新对象占满时自动触发只回收新生代Eden 两块 Survivor。2.Full GC常见触发场景① 老年代空间不足放不下晋升过来的对象② 主动调用System.gc()③ 元空间内存耗尽④ 空间分配担保失败会回收整个堆新生代 老年代部分垃圾回收器还会顺带回收元空间。二、核心区别1.回收范围不同Minor GC仅新生代 Full GC整堆新生代 老年代。2.耗时与影响差距极大Minor GC频次高、速度快停顿很短对系统性能影响微弱Full GC开销巨大、STW 停顿时间很长频繁 Full GC 会严重拖慢接口响应线上要极力避免。3.对象流转逻辑不一样Minor GC存活对象复制到另一块 Survivor 区熬过多次 Minor GC 后满足年龄阈值晋升到老年代Full GC全盘扫描存活对象压缩整理老年代空闲空间清理全部无效对象。4.频次Minor GC 日常频繁发生Full GC 应当极少出现。RabbitMQ 消息队列MQ 三大核心作用1.系统解耦短信推送、日志记录、营销通知等下游业务剥离出去主业务下单 / 提交请求完成即可返回不用串行等待多个附属服务执行上下游互不影响改动互不干涉。2.流量削峰填谷大促、定时批量营销时段瞬间海量请求涌入MQ 缓冲瞬时流量消费端匀速拉取消息处理避免瞬间流量压垮数据库。3.异步提速耗时业务转为异步执行缩短主接口响应时长提升用户体验。消息可靠性保障防止消息丢失消息丢失四个节点逐一处理生产者发送阶段丢失开启生产者确认机制publisher-confirm-type消息投递到 Broker 收到回执才算发送成功失败重试交换机转发队列丢失设置备份交换机Broker 服务器丢失镜像队列、集群部署消息多副本持久化磁盘消费端丢失关闭自动 ACK业务处理完成后手动 ACK处理失败不确认消息重回队列。消息重复消费问题幂等性解决方案网络卡顿、ACK 超时会导致消息重复投递必须做幂等每条消息携带唯一业务 ID消费前先查询数据库 / Redis 判断该 ID 是否已处理已处理直接跳过未处理执行业务逻辑执行完成标记已消费。死信队列 DLX消息满足以下条件会进入死信队列不会一直重试阻塞正常队列消息被多次消费均失败消息过期队列达到最大长度被丢弃用处存放异常消息人工排查错误原因、重新补发避免无效消息无限循环占用资源。项目落地场景批量营销短信异步推送、定时任务分发、日志异步存储、订单后续附属流程解耦。项目排查和问题处理1.项目使用 RabbitMQ 最核心的三个作用分别是什么RabbitMQ 三大核心用途系统解耦把短信推送、消息通知这类附属业务从主业务剥离主服务和下游消费服务互不依赖一方修改、故障不会直接牵连另一方。流量削峰填谷大促、批量发短信等高并发瞬间流量先存入 MQ 缓冲消费端平稳匀速处理避免瞬时海量请求压垮数据库与业务服务。异步提升响应速度耗时的后置流程异步化处理主接口完成核心逻辑就直接返回结果大幅缩短接口耗时优化使用体验。2.RabbitMQ 消息丢失一共分为四个环节分别是哪些各自如何保障消息不丢失RabbitMQ 消息丢失四大环节及对应保障方案1.生产者投递阶段丢失开启生产者确认机制ConfirmBroker 成功接收消息后返回确认回执未收到回执则触发重试投递保证消息可靠送出。2.交换机转发至队列时丢失配置备份交换机路由失败的消息会转发至备份交换机对应的队列避免消息路由异常直接丢弃。3.Broker 服务端消息丢失开启消息、队列持久化消息写入磁盘搭建 RabbitMQ 集群 镜像队列消息存储多副本节点宕机数据不会丢失。4.消费端消息丢失关闭自动 ACK改为手动 ACK 模式业务逻辑完整处理完毕后再手动发送确认指令业务异常处理失败则拒绝 ACK消息重新退回原队列等待再次消费。3.说说幂等性在 RabbitMQ 里具体怎么落地实现1.生成全局唯一消息标识每条消息封装唯一业务 ID订单号、短信批次号、uuid 均可生产者发送时把该 ID 一并塞入消息体。2.消费前置校验消费者拿到消息后先去 Redis / 数据库查询这条消息 ID 是否已经处理完成若已存在记录判定为重复消息直接丢弃不再执行业务逻辑若无记录继续往下处理业务。3.业务执行成功后做标记业务逻辑完整执行完毕写入标识方案 1Redis 存入该消息 ID并设置过期时间方案 2数据库新建消息消费记录表写入主键 id 处理状态。业务失败不打标处理异常时不记录消费状态消息重回队列重试不会被误判为已消费。补充两种常用方案数据库唯一索引针对入库类业务给业务流水字段加唯一索引重复消息插入直接报错天然拦截重复数据状态机控制依靠业务单据状态待处理、已完成判断已完结单据不再二次处理。校验逻辑放在消费端而非发送端重复消费是 ACK 超时、网络抖动导致 MQ 重复推送消息引发的问题生产者一般只会发送一次。SkyWalking ELK 链路追踪与日志监控SkyWalking 核心定位面向微服务分布式架构的 APM应用性能监控工具 核心三大能力1.分布式调用链路追踪一次前端请求依次经过网关 → 短信服务 → 营销服务 → 缓存 → MQ → 数据库SkyWalking 会生成一条完整链路统一 TraceId 串联全流程每个服务分段生成 SpanId链路页面能看清每一段耗时、调用顺序、哪个服务卡顿、哪一步抛出异常。2.服务性能指标监控自动采集各项数据接口平均响应时间、QPS 吞吐量、错误率、JVM 运行状态、线程池占用、数据库耗时绘制曲线图直观看到高峰期性能下滑、接口抖动。3.告警推送接口错误率飙升、响应超时、服务离线、JVM 内存占用过高可配置邮件 / 消息告警提早发现线上故障。关键术语通俗解释1.TraceId一次完整请求全局唯一编号整条链路所有服务共用同一个 TraceId凭借它就能检索整条调用记录。2.Span链路里的每一小段调用比如网关调用后端服务、服务查询 MySQL、发送 MQ 都单独算作一个 Span会记录耗时、状态、异常信息。3.采样率线上请求量巨大不会采集所有链路配置采样比例比如 10%减轻服务与存储压力排查问题时可临时调高采样。SkyWalking Java Agent 核心优势全程零业务代码修改只需要在服务启动命令添加-javaagent探针参数即可接入监控探针依附 JVM 运行自动拦截接口调用、数据库访问、MQ 收发、Feign 远程调用等行为自动采集链路耗时、异常信息开发无需埋点编码。探针分为两种采集模式字节码增强默认运行期修改字节码无侵入主流方案SDK 埋点手动编码埋点极少场景才会使用。ELK 是什么和 SkyWalking 分工区别ELK 由三款组件构成Elasticsearch Logstash Kibana作用统一收集、存储、检索、可视化系统日志日志代码打印的 info、error、异常堆栈、参数详情场景报错后想看具体报错堆栈、入参、上下文日志用 ELKLogstash日志采集管道负责日志收集、过滤、清洗、转换从各个微服务、服务器抓取零散日志剔除无用空格、杂乱字符、拆分日志字段、过滤无效日志处理完毕后统一推送至 Elasticsearch。补充现在很多场景会用 Filebeat 替代 Logstash 做轻量采集占用资源更低。lasticsearch ES日志存储 检索引擎日志最终存放仓库核心能力海量日志持久化存储支持全文快速检索、按 TraceId、时间、报错关键词精准查询日志日志分片分布式存储量大也不会卡顿。Kibana可视化展示面板负责前端可视化绘制日志量曲线图、报错统计饼图提供检索页面输入关键词、TraceId 就能查询日志配置日志告警、仪表盘直观查看系统日志健康状态。三者流转链路各个服务散落日志 → Logstash 采集清洗 → Elasticsearch 存储索引 → Kibana 查看检索二者分工重点区分工具核心侧重点适用场景SkyWalking调用链路、性能耗时、服务调用关系、慢接口定位查接口为什么慢、哪个服务拖后腿、服务间调用报错ELK原始日志、异常堆栈、请求参数详情定位具体代码报错、查看入参出参、详细错误日志二者搭配使用流程发现接口卡顿 / 报错 → SkyWalking 查链路锁定出问题的服务节点拿到该链路 TraceId → 去 ELK 根据 TraceId 检索整条链路的详细日志查看具体异常堆栈、参数定位代码 bug。项目部署简单流程服务启动挂载 SkyWalking Agent 探针javaagent无代码侵入自动采集链路数据探针将数据上报 SkyWalking OAP 服务UI 面板可视化展示调用链、性能报表日志统一采集推送至 ELK链路与日志通过 TraceId 关联打通。适用场景短信营销项目举例批量发送短信接口缓慢SkyWalking 查看链路网关耗时很短卡在 RabbitMQ 消息投递 数据库写入环节ELK 根据 TraceId 检索日志发现数据库索引缺失批量插入耗时太久优化索引之后响应速度明显下降。 项目技术点总结--四大核心技术+缓存
内容Seata AT、Sentinel、QLExpress、DockerCompose 四大核心技术 Redis 底层、CaffeineRedis 二级缓存、缓存三大问题Seata AT 分布式事务AT 模式三阶段完整执行流程一阶段执行业务本地事务执行业务 SQL新增 AI 短信记录、扣商户额度同步生成 undo 回滚日志存入库提交本地 MySQL 事务给对应业务行加锁此时数据入库但全局事务未结束外部其他服务看不到本次修改。二阶段提交TC 事务协调器通知分支提交服务删除本地 undo 日志释放行锁数据对外完全可见。二阶段回滚TC 通知分支回滚读取 undo 日志生成反向补偿 SQL撤销一阶段所有增删改数据释放行锁恢复到执行前状态。项目落地业务场景批量 AI 短信生成、定时营销任务需要同时操作三张数据短信生成记录表、商户额度表、Redis 缓存额度。若不加 Seata AT会出现短信记录插入成功、商户额度扣减 SQL 报错导致商户免费下发短信数据不一致。添加GlobalTransactional全局事务注解保证多库操作原子性要么全成功、要么全撤销。AT / TCC / SAGA 三种分布式事务对比方案代码侵入度锁机制适用场景项目选用原因AT极低仅注解行锁同步锁MySQL 同步数据库操作短信平台以 MySQL 为主开发成本低TCC极高需手写 Try/Confirm/Cancel无数据库锁业务自定义对接第三方支付、非关系型存储项目几乎不用开发工作量大SAGA中等手动写补偿逻辑无锁最终一致性超长异步流程、跨异构系统批量异步任务极少使用一致性弱线上高频失效踩坑点方法不是 public、同类内部调用全局事务失效多数据源未配置 Seata 代理数据源MQ 异步、子线程无法传递全局事务上下文undo 日志长期堆积需定时清理 undo 表。项目排查和问题处理1.使用 Seata AT 分布式事务出现「短信记录入库成功商户额度扣减失败」数据不一致请写出完整排查思路。第一步检查业务方法上是否添加GlobalTransactional全局事务注解无注解则完全不生效第二步校验当前事务方法访问修饰符必须是 public如果是 private /protected/ 同类内部自调用Spring AOP 无法生成代理全局事务直接失效第三步查看日志定位扣减额度 SQL 抛出的异常确认异常是否被try-catch捕获且没有主动抛出被吞掉的异常不会触发 Seata 回滚第四步核对项目多数据源配置是否全部使用 Seata 代理数据源未代理的库操作不参与全局事务第五步查询 undo_log 回滚日志表确认一阶段是否正常生成回滚记录第六步排查是否存在异步 MQ、新开子线程执行扣减逻辑子线程无法传递全局事务上下文事务隔离第七步观察 TC 事务协调器日志查看二阶段是提交指令还是回滚指令定位异常分支。2.简述 Seata AT 一阶段、二阶段提交、二阶段回滚分别做了哪些核心操作一阶段执行业务增删改 SQL同步生成 undo 日志里面存反向补偿 SQL提交本地 MySQL 事务同时对操作的数据加行锁此时外部看不到本次修改的数据。二阶段提交TC 事务协调器收集所有 RM 分支执行状态全部无异常则通知各分支删除本地 undo 日志、释放行锁修改后的数据对外可见。二阶段回滚只要任意分支执行异常TC 下发回滚指令RM 读取 undo 日志里的反向 SQL 执行数据恢复完成后释放行锁undo 日志会做归档清理。3.结合咱们营销短信平台业务说一说项目为什么选择 Seata AT而不用 TCC、SAGA我们平台核心业务都是 MySQL 同步落库场景所以优先选用 Seata ATAT 侵入极低仅需在方法上加GlobalTransactional注解框架自动生成 undo 日志实现事务控制几乎不用改动原有业务代码开发维护成本低TCC 侵入性极强需要手动编写 Try、Confirm、Cancel 三段逻辑代码改动量大适合对接第三方支付、非数据库异构场景我们项目没有这类需求SAGA 无锁、依靠手动补偿适合超长异步业务流程一致性偏弱我们短信下发、AI 文案生成都是短同步事务追求强一致完全不匹配 SAGA 适用场景。Sentinel 限流熔断熔断三大状态流转关闭 Closed接口正常运行持续统计 QPS、超时率、异常比例指标未超阈值请求直接放行。打开 Open异常 / 超时占比超过阈值熔断器开启直接拒绝所有请求执行降级逻辑防止雪崩拖垮服务。半开 Half-Open冷却窗口期结束放行少量探测流量探测请求正常→切回关闭探测仍报错→重回打开。三种限流算法对比算法特点项目使用场景滑动窗口精准统计固定时间窗口流量粒度细Sentinel 单机限流、Redis Lua 集群限流主力漏桶流出速率固定削峰无法应对突发流量MQ 消费者批量消费控并发令牌桶可积累令牌允许瞬时突发高并发大促活动临时扩容流量场景项目落地场景网关层后台/admin/**接口全局粗粒度限流防止运营并发压垮服务AI 大模型、第三方短信通道接口配置熔断设计三级降级验证码接口手机号、IP 防刷限流配置持久化限流熔断规则统一存 Nacos支持热更新控制台仅用来监控不存储生产规则。AI 接口三级降级策略1 级降级切换备用大模型2 级降级读取 MySQL 预制短信模板3 级降级返回通用 “系统繁忙” 兜底提示。集群限流兜底方案Redis Lua 分布式滑动窗口实现全集群统一限流若 Redis 宕机自动切换 Sentinel 本地内存限流兜底避免裸跑无防护。项目排查和问题处理1.项目对接第三方 AI 大模型频繁超时如何使用 Sentinel 做服务保护首先我们会给 AI 生成接口单独定义 Sentinel 资源标识持续统计接口的响应超时率、异常比例限流管控配置接口整体 QPS 限流也支持热点参数限流限制单商户、单 IP 的调用频次避免单个客户疯狂调用占用资源限流阈值统一放在 Nacos 可动态调整熔断保护当大模型接口超时、报错占比超过设定阈值熔断器直接打开不再持续调用不稳定的第三方 LLM避免大量超时请求堆积拖垮我们自身服务三级降级兜底熔断触发后依次执行降级策略优先切换备用大模型备用模型不可用就读取 MySQL 预制合规短信模板两种方案都失效则返回 “系统繁忙请稍后重试” 友好提示故障兜底分布式限流依赖 Redis Lua一旦 Redis 宕机自动切换 Sentinel 本地内存限流保证接口始终有防护不会裸跑。2.简述滑动窗口、漏桶、令牌桶三种限流算法的特点以及项目各自使用场景。滑动窗口特点将时间切分为多个小段滚动统计流量统计粒度细能精准识别短时间突发流量避免临界流量误放行 项目场景Sentinel 单机本地限流、Redis Lua 集群统一限流平台主流限流方案。漏桶算法特点流出速率恒定无论请求涌入多快都以固定速度处理强制削峰无法应对瞬时突发流量 项目场景RabbitMQ 消费者批量拉取消息控制批量 AI 生成任务的消费速度防止一次性压垮向量库与大模型。令牌桶算法特点系统匀速生成令牌存入桶内空闲时段令牌可累积突发高并发时能一次性取出存量令牌支持瞬时流量峰值 项目场景营销大促活动允许短时间爆发式请求适配活动流量突增场景。3.我们项目 Redis 宕机后限流不会完全失效依靠什么兜底方案逻辑是什么项目采用双层限流兜底架构正常情况下通过 Redis Lua 滑动窗口实现集群统一限流保证多实例流量管控标准一致一旦 Redis 宕机、无法访问系统自动降级切换到 Sentinel 本地内存限流单机独立统计接口流量避免服务完全裸跑无防护保障接口基础限流能力不丢失。QLExpress 规则引擎硬编码 if/else 人群筛选的痛点如果客户分群、营销筛选逻辑写死在代码里新增、修改筛选条件必须改代码、打包发版、重启服务迭代周期长运营无法自主配置规则开发工作量大。QLExpress 核心能力可视化页面拖拽配置表达式运营不用写代码就能自定义人群筛选条件内置安全沙箱拦截危险执行语法杜绝表达式注入安全风险表达式本地缓存重复执行不用重复解析提升批量圈选人群性能支持逻辑判断、数值区间、多条件组合完全匹配客户分层业务。项目落地场景批量定时营销任务中运营在后台配置人群筛选表达式执行定时推送时通过 QLExpress 动态解析规则批量圈选出符合条件的目标客户无需开发介入发版迭代。项目排查和问题处理1.项目为什么不用 if-else 硬编码做人群筛选选择 QLExpress业务里营销人群筛选规则变动十分频繁如果用 if-else 硬编码实现每次新增、修改筛选条件都需要开发改代码、打包、发版、重启服务迭代周期长占用大量开发人力。 引入 QLExpress 后解决了这些痛点后台提供可视化拖拽页面运营可以自主配置筛选表达式不用依赖开发、无需发版就能调整人群规则内置安全沙箱限制危险语法执行防止表达式注入带来安全漏洞表达式做本地缓存批量圈选人群时不用重复解析提升批量筛选性能支持多条件逻辑、区间判断等各类筛选语法完全适配我们客户分层、营销圈人业务。2.QLExpress 安全沙箱有什么作用对应项目什么安全风险QLExpress 内置安全沙箱机制会拦截危险、非法语法通过黑白名单管控可执行方法与操作我们项目运营自主编写筛选表达式如果没有沙箱限制恶意表达式可能执行文件读写、反射等高危操作造成表达式注入漏洞威胁服务安全沙箱能隔离这类风险只开放业务允许的逻辑判断、数值计算语法从源头避免恶意表达式攻击。DockerCompose 容器编排核心作用依靠一份 yml 配置文件一条命令就能一键拉起项目全套中间件MySQL、Redis、RabbitMQ、PgVector、ES自动完成端口映射、容器网络创建、数据持久化挂载。落地业务价值统一团队所有人本地开发环境规避中间件版本不一致引发的各种诡异 bug新人上手成本极低无需手动下载安装、配置各类中间件拉取项目后直接启动 compose 即可区分环境隔离开发、测试环境可通过不同 compose 配置快速切换。Docker / DockerCompose / K8s 三者定位区分表格工具核心定位使用场景Docker容器引擎打包单个应用镜像打包业务服务、单独启动单个中间件DockerCompose单机多容器编排工具本地开发、小型测试环境单机管理一组容器K8s分布式集群容器编排平台线上生产大规模集群服务部署、扩缩容、自愈项目排查和问题处理1.本地开发环境为什么不直接在 Windows 系统手动安装 MySQL、Redis而是选用 DockerCompose如果团队成员在 Windows 本地手动安装 MySQL、Redis 等中间件很容易出现中间件版本、配置参数不统一的问题经常出现本地运行正常提交代码到测试环境就报错的环境差异 bug。 使用 DockerCompose 有几点核心优势统一约束所有中间件版本与配置团队所有人本地环境完全一致规避环境差异类 bug新人上手简单不用手动下载、安装、配置各类中间件一条命令就能启动整套依赖支持多套 yml 配置快速隔离开发、测试两套环境切换方便自动完成端口映射、数据持久化、容器网络配置省去大量手动配置工作。2.简述 DockerCompose 核心作用以及它的配置文件是什么DockerCompose 是单机多容器编排工具核心作用通过一份统一配置文件一键批量启动、管理项目所需全部中间件容器自动处理网络、端口、数据持久化统一团队开发环境。 配置文件固定名称为docker-compose.yml。Redis 全套底层 CaffeineRedis 二级缓存Redisson 分布式锁核心原理底层通过 Lua 脚本实现加锁、解锁保证操作原子性支持可重入锁记录持有锁的线程标识同一线程多次加锁不会死锁看门狗自动续期长任务后台自动延长锁过期时间防止任务没执行完锁提前释放RedLock 红锁机制过半 Redis 节点加锁成功才算拿到锁解决主从切换锁丢失问题项目用于 Quartz 集群定时任务防重复执行。原生 SETNX 锁四大缺陷不可重入、无自动续期、解锁非原子操作、主从切换锁丢失项目全部用 Redisson 替代原生方案。Lua 脚本原子性项目落地场景Redis Lua 滑动窗口多维度限流手机号、商户 ID、IPRedLock 分布式锁加解锁逻辑批量更新商户额度缓存多条缓存操作保持原子执行。Redis 在项目中的使用场景分布式锁、分布式限流、JWT 黑名单、布隆过滤器、二级分布式缓存、接口幂等校验、计数器。缓存三大问题穿透 / 击穿 / 雪崩完整方案缓存穿透现象查询数据库不存在的数据缓存无记录请求全部打穿到 MySQL压垮数据库 业务场景恶意请求不存在的商户 ID、无效手机号 解决方案前置布隆过滤器拦截无效 key空值短期缓存接口参数合法性校验缓存击穿现象热点 key 过期瞬间大量并发请求同时查询数据库 业务场景高热度商户额度配置高频查询 解决方案热点 key 永不过期分布式锁控制单线程查库回填缓存缓存雪崩现象大量 key 同一时刻过期Redis 整体宕机流量全部涌向 MySQL 解决方案过期时间随机偏移CaffeineRedis 多级缓存接口限流熔断Redis 集群高可用CaffeineRedis 二级缓存完整查询链路查询顺序优先读取 Caffeine 本地缓存进程内存无网络 IO速度最快→未命中查询 Redis 分布式缓存→两级都未命中才查询 MySQL查询成功双向回填两级缓存。 优势Caffeine 拦截大部分热点请求大幅减少 Redis 网络请求Redis 保证多服务实例之间缓存数据一致双重兜底Redis 故障时本地缓存仍可提供基础数据访问。生活化举例Redisson 分布式锁把锁想象成卫生间钥匙SETNX 是一次性钥匙进去之后没法再开门中途超时钥匙自动消失Redisson 可重入锁支持同一个人反复进出看门狗相当于定时续时防止洗澡没结束门锁自动打开RedLock 相当于多间卫生间超过一半房间拿到钥匙才算占用避免主卫生间故障导致锁失效。缓存三大问题穿透不停查不存在的物品仓库没有就全都去翻数据库库房库房被挤爆布隆过滤器相当于门卫不存在的物品直接拦在门外。击穿爆款商品标签刚好过期所有人同一时间冲去库房给标签永久保存或者只放一个人去库房更新。雪崩所有商品标签同时过期瞬间所有人冲进库房每个商品过期时间错开同时办公桌存一份备份。项目排查和问题处理1.原生 SETNX 实现分布式锁存在哪些缺陷项目为什么选用 Redisson原生 SETNX 分布式锁四大缺陷不可重入同一个线程多次加锁会直接死锁不支持嵌套调用无自动续期任务执行时长超过锁过期时间锁会提前释放并发错乱解锁非原子性先判断持有者再删除锁并发场景下极易误删别人的锁主从切换锁丢失主节点拿到锁还未同步给从节点就宕机新主节点不存在该锁出现并发安全问题。Redisson 全部补齐以上痛点自带可重入锁、看门狗自动续期、Lua 脚本保证加解锁原子性、提供 RedLock 红锁规避主从锁丢失风险开发开箱即用稳定性更强因此项目统一使用 Redisson。2.分别说明缓存穿透、缓存击穿、缓存雪崩三者区别以及各自对应的解决办法。1. 缓存穿透现象请求一直查询 Redis、MySQL 都不存在的数据缓存永远无法留存数据大量请求持续直达数据库压垮 MySQL大多是恶意刷无效 ID、手机号造成。解决方案前置布隆过滤器提前拦截不存在的 key查询为空时在 Redis 写入短期空值缓存接口前置参数校验过滤非法参数。2. 缓存击穿现象单个超高热度缓存 key 到期一瞬间海量并发请求同时绕过缓存涌向数据库。解决方案热点 key 设置永不过期使用分布式锁仅放行一个请求去数据库查询并回填缓存其余请求等待缓存刷新完成。3. 缓存雪崩现象分两种① 大批量缓存 key 集中同一时间过期流量瞬间全部打入数据库 ② Redis 集群整体宕机缓存彻底失效请求全部访问 MySQL。解决方案给过期时间加上随机偏移值错开批量过期时间搭建 CaffeineRedis 二级缓存Redis 故障时本地缓存兜底Redis 做主从集群保证高可用搭配 Sentinel 限流熔断限制打库流量。三者核心区分 穿透查不存在的数据击穿单个热点 key 过期雪崩大批 key 集体过期 / Redis 整体瘫痪3.项目引入 CaffeineRedis 二级缓存有什么好处1.访问速度大幅提升Caffeine 属于进程内本地内存缓存无网络 IO 开销绝大多数热点请求可直接命中本机缓存响应速度远快于 Redis大幅降低接口耗时。2.削减 Redis 压力与网络开销高频热点数据常驻本地缓存不必频繁和 Redis 交互有效减轻 Redis 集群负载节省内网网络传输损耗。3.多重防护抵御缓存异常场景缓解缓存雪崩大量 key 集中过期或 Redis 宕机时本地 Caffeine 依旧可以兜底提供数据访问缓解缓存击穿热点数据留存本地规避热点 key 过期瞬间流量涌入数据库 搭配限流策略一起给数据库多层防护。4.兼顾分布式数据一致本地 Caffeine 负责高速访问Redis 统一存储集群共享数据服务实例间数据以 Redis 为准兼顾性能与分布式一致性。JVM 调优 OOM 问题排查JVM 内存区域划分1.堆 Heap存放所有对象实例分新生代Eden、S0、S1 老年代GC 主要回收区域OOM 最常发生在这里。2.虚拟机栈每个线程私有存放局部变量、方法调用栈帧栈太深会栈溢出 StackOverflowError。3.本地方法栈支撑 native 本地方法调用。4.程序计数器记录线程执行字节码位置唯一一个无 OOM 的内存区域。5.元空间 Metaspace存放类信息、常量、静态变量、字节码JDK8 取消永久代改用元空间直接使用操作系统内存。新生代 GC 流程复制算法新对象优先分配在 Eden 区Eden 满了触发 Minor GC存活对象复制到空闲 Survivor 区两个 Survivor 来回交换存放存活对象对象熬过 15 次 Minor GC 晋升到老年代 大对象直接进入老年代避免新生代来回复制开销。常见 OOM 四种场景 诱因1.Java heap space 堆内存溢出最普遍集合无限添加对象未释放、大文件一次性读取加载、缓存无上限堆积。2.Metaspace 元空间溢出频繁动态创建类、动态代理大量生成 class、热部署频繁重载类。3.栈溢出 StackOverflowError递归深度过大、方法循环调用无终止条件。4.直接内存 Direct Buffer 溢出Netty、NIO 大量使用堆外内存未主动释放。线上 OOM 排查标准步骤发生 OOM 时开启-XX:HeapDumpOnOutOfMemoryError自动导出堆快照 dump 文件使用 MAT 内存分析工具导入 dump 文件查看内存占用最大对象、引用链定位代码里未释放的集合 / 缓存 / 大资源修复代码逻辑、调整 JVM 参数、限制缓存容量。项目 JVM 基础参数配置示例Xms初始堆内存Xmx最大堆内存两者设一致避免运行时堆扩容消耗性能Xmn新生代大小SurvivorRatioEden 和 Survivor 比例MetaspaceSize元空间初始大小生活化举例JVM 内存好比办公仓库堆内存 开放式大储物区绝大部分货物对象都放这里堆满就要清理垃圾GCEden 区 临时置物桌新东西先放桌面满了收拾一遍常用物品搬到储物架Survivor老年代 固定储物柜长期不用但还要保留的物品放这里虚拟机栈 每个人手边笔记本记录当下工作步骤写太多本子装不下就栈溢出元空间 产品说明书档案柜存放各类产品图纸类字节码。OOM 就是仓库彻底塞满再也放不下货物必须清理无用货品、扩容仓库或者改掉疯狂囤货的代码。项目排查和问题处理1.JDK8 为什么废弃永久代改用元空间 Metaspace永久代存在哪些弊端永久代PermGen弊端永久代属于 JVM 堆内存的一部分内存上限固定很难预估所需大小设置过小容易频繁 Full GC 甚至溢出设置过大又造成内存闲置浪费永久代内存回收复杂类卸载条件严苛热部署、动态代理、频繁加载类的场景极易出现永久代溢出不同 JDK 版本永久代大小参数不一致兼容性差。JDK8 替换为元空间 Metaspace 的原因元空间直接使用本地操作系统内存不再占用 JVM 堆内存理论上限是物理内存大幅降低溢出概率元空间会动态伸缩内存无需人为精准预估容量运维更省心优化了类加载与卸载机制Spring 热部署、动态创建类、反射代理等场景更稳定统一了不同平台内存管理逻辑跨系统兼容性更好。2.线上出现java.lang.OutOfMemoryError: Java heap space堆内存溢出完整排查流程是什么1.提前配置 JVM 启动参数项目启动时预先加上参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/xxx/dump一旦触发堆 OOMJVM 会自动生成堆快照 dump 文件留存现场内存数据。2.下载 dump 文件使用 MAT 工具解析将 dump 文件拉取至本地借助 Eclipse MAT 内存分析工具打开快照。3.定位内存泄漏根源查看内存占用排行最高的对象追踪对象引用链找出长期持有对象却未释放的代码位置常见为无限扩容的 List/Map 集合、无上限缓存、一次性读取超大文件、大对象常驻内存等。4。落地优化方案代码层面清理无用集合、读取文件采用流式分批加载、给本地缓存设置最大容量与淘汰策略JVM 参数层面合理调整堆初始值 Xms、最大值 Xmx新生代配比架构层面超大批量数据拆分处理避免一次性加载至内存。5.上线验证优化后观察 GC 日志、堆内存走势、FullGC 频次确认 OOM 不再复现。3.简述 Minor GC 和 Full GC 的触发时机以及二者区别一、触发时机1.Minor GC新生代 GCEden 区内存被新对象占满时自动触发只回收新生代Eden 两块 Survivor。2.Full GC常见触发场景① 老年代空间不足放不下晋升过来的对象② 主动调用System.gc()③ 元空间内存耗尽④ 空间分配担保失败会回收整个堆新生代 老年代部分垃圾回收器还会顺带回收元空间。二、核心区别1.回收范围不同Minor GC仅新生代 Full GC整堆新生代 老年代。2.耗时与影响差距极大Minor GC频次高、速度快停顿很短对系统性能影响微弱Full GC开销巨大、STW 停顿时间很长频繁 Full GC 会严重拖慢接口响应线上要极力避免。3.对象流转逻辑不一样Minor GC存活对象复制到另一块 Survivor 区熬过多次 Minor GC 后满足年龄阈值晋升到老年代Full GC全盘扫描存活对象压缩整理老年代空闲空间清理全部无效对象。4.频次Minor GC 日常频繁发生Full GC 应当极少出现。RabbitMQ 消息队列MQ 三大核心作用1.系统解耦短信推送、日志记录、营销通知等下游业务剥离出去主业务下单 / 提交请求完成即可返回不用串行等待多个附属服务执行上下游互不影响改动互不干涉。2.流量削峰填谷大促、定时批量营销时段瞬间海量请求涌入MQ 缓冲瞬时流量消费端匀速拉取消息处理避免瞬间流量压垮数据库。3.异步提速耗时业务转为异步执行缩短主接口响应时长提升用户体验。消息可靠性保障防止消息丢失消息丢失四个节点逐一处理生产者发送阶段丢失开启生产者确认机制publisher-confirm-type消息投递到 Broker 收到回执才算发送成功失败重试交换机转发队列丢失设置备份交换机Broker 服务器丢失镜像队列、集群部署消息多副本持久化磁盘消费端丢失关闭自动 ACK业务处理完成后手动 ACK处理失败不确认消息重回队列。消息重复消费问题幂等性解决方案网络卡顿、ACK 超时会导致消息重复投递必须做幂等每条消息携带唯一业务 ID消费前先查询数据库 / Redis 判断该 ID 是否已处理已处理直接跳过未处理执行业务逻辑执行完成标记已消费。死信队列 DLX消息满足以下条件会进入死信队列不会一直重试阻塞正常队列消息被多次消费均失败消息过期队列达到最大长度被丢弃用处存放异常消息人工排查错误原因、重新补发避免无效消息无限循环占用资源。项目落地场景批量营销短信异步推送、定时任务分发、日志异步存储、订单后续附属流程解耦。项目排查和问题处理1.项目使用 RabbitMQ 最核心的三个作用分别是什么RabbitMQ 三大核心用途系统解耦把短信推送、消息通知这类附属业务从主业务剥离主服务和下游消费服务互不依赖一方修改、故障不会直接牵连另一方。流量削峰填谷大促、批量发短信等高并发瞬间流量先存入 MQ 缓冲消费端平稳匀速处理避免瞬时海量请求压垮数据库与业务服务。异步提升响应速度耗时的后置流程异步化处理主接口完成核心逻辑就直接返回结果大幅缩短接口耗时优化使用体验。2.RabbitMQ 消息丢失一共分为四个环节分别是哪些各自如何保障消息不丢失RabbitMQ 消息丢失四大环节及对应保障方案1.生产者投递阶段丢失开启生产者确认机制ConfirmBroker 成功接收消息后返回确认回执未收到回执则触发重试投递保证消息可靠送出。2.交换机转发至队列时丢失配置备份交换机路由失败的消息会转发至备份交换机对应的队列避免消息路由异常直接丢弃。3.Broker 服务端消息丢失开启消息、队列持久化消息写入磁盘搭建 RabbitMQ 集群 镜像队列消息存储多副本节点宕机数据不会丢失。4.消费端消息丢失关闭自动 ACK改为手动 ACK 模式业务逻辑完整处理完毕后再手动发送确认指令业务异常处理失败则拒绝 ACK消息重新退回原队列等待再次消费。3.说说幂等性在 RabbitMQ 里具体怎么落地实现1.生成全局唯一消息标识每条消息封装唯一业务 ID订单号、短信批次号、uuid 均可生产者发送时把该 ID 一并塞入消息体。2.消费前置校验消费者拿到消息后先去 Redis / 数据库查询这条消息 ID 是否已经处理完成若已存在记录判定为重复消息直接丢弃不再执行业务逻辑若无记录继续往下处理业务。3.业务执行成功后做标记业务逻辑完整执行完毕写入标识方案 1Redis 存入该消息 ID并设置过期时间方案 2数据库新建消息消费记录表写入主键 id 处理状态。业务失败不打标处理异常时不记录消费状态消息重回队列重试不会被误判为已消费。补充两种常用方案数据库唯一索引针对入库类业务给业务流水字段加唯一索引重复消息插入直接报错天然拦截重复数据状态机控制依靠业务单据状态待处理、已完成判断已完结单据不再二次处理。校验逻辑放在消费端而非发送端重复消费是 ACK 超时、网络抖动导致 MQ 重复推送消息引发的问题生产者一般只会发送一次。SkyWalking ELK 链路追踪与日志监控SkyWalking 核心定位面向微服务分布式架构的 APM应用性能监控工具 核心三大能力1.分布式调用链路追踪一次前端请求依次经过网关 → 短信服务 → 营销服务 → 缓存 → MQ → 数据库SkyWalking 会生成一条完整链路统一 TraceId 串联全流程每个服务分段生成 SpanId链路页面能看清每一段耗时、调用顺序、哪个服务卡顿、哪一步抛出异常。2.服务性能指标监控自动采集各项数据接口平均响应时间、QPS 吞吐量、错误率、JVM 运行状态、线程池占用、数据库耗时绘制曲线图直观看到高峰期性能下滑、接口抖动。3.告警推送接口错误率飙升、响应超时、服务离线、JVM 内存占用过高可配置邮件 / 消息告警提早发现线上故障。关键术语通俗解释1.TraceId一次完整请求全局唯一编号整条链路所有服务共用同一个 TraceId凭借它就能检索整条调用记录。2.Span链路里的每一小段调用比如网关调用后端服务、服务查询 MySQL、发送 MQ 都单独算作一个 Span会记录耗时、状态、异常信息。3.采样率线上请求量巨大不会采集所有链路配置采样比例比如 10%减轻服务与存储压力排查问题时可临时调高采样。SkyWalking Java Agent 核心优势全程零业务代码修改只需要在服务启动命令添加-javaagent探针参数即可接入监控探针依附 JVM 运行自动拦截接口调用、数据库访问、MQ 收发、Feign 远程调用等行为自动采集链路耗时、异常信息开发无需埋点编码。探针分为两种采集模式字节码增强默认运行期修改字节码无侵入主流方案SDK 埋点手动编码埋点极少场景才会使用。ELK 是什么和 SkyWalking 分工区别ELK 由三款组件构成Elasticsearch Logstash Kibana作用统一收集、存储、检索、可视化系统日志日志代码打印的 info、error、异常堆栈、参数详情场景报错后想看具体报错堆栈、入参、上下文日志用 ELKLogstash日志采集管道负责日志收集、过滤、清洗、转换从各个微服务、服务器抓取零散日志剔除无用空格、杂乱字符、拆分日志字段、过滤无效日志处理完毕后统一推送至 Elasticsearch。补充现在很多场景会用 Filebeat 替代 Logstash 做轻量采集占用资源更低。lasticsearch ES日志存储 检索引擎日志最终存放仓库核心能力海量日志持久化存储支持全文快速检索、按 TraceId、时间、报错关键词精准查询日志日志分片分布式存储量大也不会卡顿。Kibana可视化展示面板负责前端可视化绘制日志量曲线图、报错统计饼图提供检索页面输入关键词、TraceId 就能查询日志配置日志告警、仪表盘直观查看系统日志健康状态。三者流转链路各个服务散落日志 → Logstash 采集清洗 → Elasticsearch 存储索引 → Kibana 查看检索二者分工重点区分工具核心侧重点适用场景SkyWalking调用链路、性能耗时、服务调用关系、慢接口定位查接口为什么慢、哪个服务拖后腿、服务间调用报错ELK原始日志、异常堆栈、请求参数详情定位具体代码报错、查看入参出参、详细错误日志二者搭配使用流程发现接口卡顿 / 报错 → SkyWalking 查链路锁定出问题的服务节点拿到该链路 TraceId → 去 ELK 根据 TraceId 检索整条链路的详细日志查看具体异常堆栈、参数定位代码 bug。项目部署简单流程服务启动挂载 SkyWalking Agent 探针javaagent无代码侵入自动采集链路数据探针将数据上报 SkyWalking OAP 服务UI 面板可视化展示调用链、性能报表日志统一采集推送至 ELK链路与日志通过 TraceId 关联打通。适用场景短信营销项目举例批量发送短信接口缓慢SkyWalking 查看链路网关耗时很短卡在 RabbitMQ 消息投递 数据库写入环节ELK 根据 TraceId 检索日志发现数据库索引缺失批量插入耗时太久优化索引之后响应速度明显下降。