数据库类场景一、理赔业务8张表强关联JOIN无法删减业务除索引外还有哪些优化方案业务层技术层两层如果业务上确实没办法精简关联表数量先做业务层面梳理再用多层技术方案兜底1. 业务前置优化和产品、业务方确认8张表里有没有可以提前冗余的静态基础数据比如基础配置、用户基础信息这类很少变更的数据提前冗余到宽表里面减少实时JOIN的表数量也可以拆分查询场景把一次性多维度大查询拆成分步小查询前端做数据聚合降低单条SQL压力。2. 技术落地优化① SQL层面建立联合覆盖索引避免回表拆解大JOIN为小关联子查询先过滤小结果集再做关联禁止select *只查询业务必需字段减少IO。② 存储层面把高频多表查询结果预热到Redis做缓存如果查询量级很大同步把数据同步到ES用搜索引擎做复杂多条件关联查询MySQL只承载基础事务写入。③ 架构层面定时任务离线预计算报表类查询结果线上直接读取预计算数据避免实时计算压力。二、只能用UUID做主键怎么解决分页慢索引页分裂问题UUID无序带来两大问题深分页遍历慢、主键索引频繁页分裂分两步解决1. 主键改造放弃无序UUID v4改用有序UUID v7或者雪花算法ID保证插入有序从根源解决InnoDB主键页分裂、磁盘碎片问题插入性能恢复到接近自增主键水平。2. 分页优化规避大offset深分页采用主键游标分页比如 where id 上一页最大id limit 20 同时给分页查询条件建立覆盖索引减少回表开销超大分页场景限制前端最大分页页数或者引导用户用筛选条件缩小范围。三、冷热数据共存多年历史保单在保热保单海量数据怎么优化结合业务做冷热分层兼顾查询性能和存储成本1. 业务分层归档定义归档规则比如保单完结超过3年判定为冷数据定时迁移到归档分表或者OceanBase冷分区热数据保留在主表缩小主表体量日常查询绝大多数只会命中热数据。2. 存储区分热数据留在高性能MySQL/OceanBase冷数据可以低成本存储至对象存储ES检索只有用户主动查询历史保单时才检索冷数据。3. 缓存区分热保单信息常驻Redis缓存冷保单不做缓存减少缓存内存占用。Java并发虚拟线程场景一、异步核保任务必须使用synchronized加锁会钉住虚拟线程业务不能改锁类型怎么折中解决核心矛盾是 synchronized是操作系统阻塞锁虚拟线程阻塞时会一直占用载体线程失去轻量调度优势 无法替换锁的前提下我有两套折中落地方案1. 任务拆分隔离把需要加锁的同步代码块最小化只把竞争修改共享数据的代码放在锁内锁外耗时逻辑全部拆分到虚拟线程异步执行缩短锁持有时间减少载体线程长时间占用。2. 载体线程资源扩容给执行这类带synchronized的虚拟线程单独配置专属载体线程池和普通无阻塞虚拟线程池物理隔离避免同步阻塞耗尽公共载体线程影响整体异步任务调度。3. 兜底监控接入线程监控识别长时间被synchronized阻塞的虚拟线程告警业务死锁、长时间阻塞问题线上及时干预。二、自研隔离线程池怎么给多业务核保/扣费/通知做资源隔离防止雪崩参考之前导出引擎自定义线程池隔离的经验做业务线程池物理隔离1. 按业务维度拆分独立线程池核保、资金扣费、消息通知、报表导出分别配置专属线程池设置独立核心线程数、拒绝策略一个业务线程池打满阻塞不会占用其他业务线程资源。2. 配置差异化拒绝策略资金扣费这类核心业务使用CallerRuns策略保障业务不丢失导出、通知非核心业务使用丢弃告警策略高峰期主动限流保护核心链路。3. 统一监控所有线程池暴露监控指标线程活跃数、队列堆积、拒绝次数出现队列堆积提前告警扩容或者限流。Redis分布式锁缓存一致性场景一、理缓存更新失败如何用RocketMQ做最终一致性兜底还要保证消息不丢不重复沿用「先写库更新缓存MQ兜底」的思路适配高可靠要求1. 正常流程业务更新保单数据库之后直接同步更新Redis缓存保证绝大多数场景实时一致性。2. 失败兜底如果缓存更新抛出异常本地发送可靠事务消息到RocketMQ消息携带保单ID、更新字段消费端重试执行缓存更新操作。3. 可靠性保障消息不丢失生产者使用事务消息保证本地库更新成功才投递消息Broker开启同步刷盘消费者手动ACK处理失败重试。消息不重复消费端基于保单唯一ID做Redis幂等标记或者数据库唯一索引防重复更新。二、分布式锁出现锁过期、业务还未执行完Redisson看门狗失效怎么办怎么兜底防数据错乱正常情况下Redisson看门狗会每隔1/3过期时间自动续期看门狗失效属于异常场景双层兜底1. 事前规避拉长锁过期时间根据业务压测得出最大执行耗时锁过期时间设置为最大耗时的2~3倍减少过期概率。2. 异常兜底看门狗失效锁提前释放后业务执行更新前做数据版本号校验乐观锁比如update set status新状态 where id保单id and version当前版本号版本不匹配直接放弃更新防止并发覆盖脏数据同时记录异常日志告警人工复盘看门狗失效原因。RocketMQ分布式事务场景一、跨服务流程核保→扣费→生成保单TCC/事务消息/SAGA怎么选型结合业务容错性选型1. RocketMQ事务消息适合最终一致性要求、回滚成本低的场景比如核保成功之后扣费失败回滚核保状态适配绝大多数普通理赔流程开发成本低。2. TCC适合资金强一致性场景比如扣费环节需要Try锁定资金、Confirm实际扣款、Cancel释放资金金融资金链路优先TCC一致性最强开发成本最高。3. SAGA适合长链路复杂理赔流程拆分本地子事务失败逆向补偿适配流程节点多、跨多系统的理赔场景。架构优化类场景一、接手老旧系统大量慢查询、老旧接口如何制定优化方案推动业务方配合改造分为落地执行跨部门推动两步1. 技术落地步骤① 监控摸底接入慢查询日志、接口RT监控统计慢SQL访问频次、影响用户范围划分优先级优先优化高频影响核心接口慢查询。② 小步迭代先做无业务侵入优化比如索引优化、SQL改写、缓存预热快速降低线上故障高频且改造难度大的慢查询设计分阶段重构方案。2. 业务推动方式给业务方提供数据支撑展示慢查询带来的用户投诉、高峰期超时率、服务器资源损耗同时提供兼容改造方案保证改造期间业务无停机、无功能变更打消业务方改动风险顾虑小范围灰度验证效果之后再全量推广优化。总结没有完整落地过的场景可以基于掌握的通用技术原理结合技术业务双向思路推导方案。如果是并发数据安全问题我会用分布式锁、乐观锁、事务消息保障一致性如果是流量打垮数据库用缓存、限流、读写分离做分层防护同时一定会联动业务侧精简无效逻辑从源头降低技术压力上线前做压测验证稳定性。