高频真实场景题

某头部电商平台年度大促秒杀活动，核心商品（如旗舰手机）库存 1000 件，预约用户 500 万，活动开启瞬间峰值 QPS 达 120 万，是日常峰值（1.2 万 QPS）的 100 倍。要求：下单成功率 99.99%、绝不超卖、页面响应 P99 < 200ms、活动结束后 10 分钟内完成库存对账。系统部署在阿里云杭州、北京双 Region，MySQL 8.0 主从集群 + Redis 6.2 Cluster + RocketMQ 5.x（5.x 引入 Proxy 收口访问、Controller 模式原生主备切换与 Pop 消费，削峰异步落库等核心能力向下兼容 4.x）。

1. 瞬时流量洪峰：100 倍突发流量打穿数据库，连接池瞬间耗尽；2. 库存超卖：高并发下 Redis 扣减与 DB 落库之间的并发窗口导致超卖；3. 恶意请求：黄牛脚本刷单，机器人占比可达 30%；4. 热点问题：单 key 扣减形成 Redis 热点与 DB 行锁热点；5. 容灾兜底：任一环节宕机不能造成资金损失与超卖。

采用漏斗模型逐层过滤流量：CDN/Nginx 拦截 70% 静态与恶意流量 → 网关层限流（令牌桶 + IP/设备指纹风控）拦截 20% → 应用层 Redis 预扣减 + MQ 削峰承接 9% → 数据层仅放行 1% 真实下单请求。核心原则：读多写少走缓存、写少精走 DB，库存扣减用 Redis + Lua 保证原子性，DB 落库异步化。流量与库存分离，请求链路尽量短，写操作尽量异步。

接入层：活动页静态化推送到 CDN，动态接口走 Nginx；Nginx 层 limit_req 按 IP 限流（10 QPS）；网关层 Sentinel 集群限流（QPS 上限 = 库存×冗余系数 3），结合设备指纹 + 滑块验证码过滤机器人。

应用层：库存预热到 Redis（key=seckill:stock:{skuId}），下单请求先走 Lua 脚本原子扣减 Redis 库存，扣减成功即发送 MQ 消息（Topic=seckill_order），立即返回"排队中"；Redis 扣减失败直接返回售罄，不进 DB。

数据层：消费者从 MQ 拉取消息，执行 DB 真正扣减（UPDATE stock SET num=num-1 WHERE sku_id=? AND num>0 利用乐观锁兜底防超卖），生成订单；库存分桶（将 1000 件拆为 10 桶各 100 件）打散热点；DB 采用分库分表按 skuId 取模。

• 如果 Redis 扣减成功但 MQ 发送失败，库存怎么办？
  采用本地消息表 + 定时补偿：扣减 Redis 后先写本地消息表（与业务同事务），异步投递 MQ，失败则扫描未发送消息重投；同时设置库存回滚兜底任务，超时未落库则回补 Redis 库存。
• 库存分桶后某桶售罄但其他桶还有，怎么处理？
  客户端路由失败时执行"桶迁移"：从余量桶借调一定数量到空桶（原子 Lua），或采用一致性哈希动态路由；也可在 Redis 维护全局余量，桶空后回查全局再分配。
• 如何防止同一用户在多端并发重复下单？
  下单前以 userId+skuId 写入 Redis SET 去重（SADD 返回 0 即重复）；关键在于去重判断与库存扣减放入同一 Lua 脚本内原子执行，避免"去重通过但扣减失败"的并发漏洞。
• 百万 QPS 下 Sentinel 集群限流本身会不会成为瓶颈？
  集群限流 Server 是单点热点，可改为：网关本地限流（单机阈值=总阈值/实例数×1.2）兜底 + 集群限流做精确控制；或将限流规则下推到 Nginx 的 limit_req 共享内存做分布式限流，避免 Java 层单点。

• 先查后扣的非原子操作：先 GET 库存判断 >0 再 DECR，两步之间存在并发窗口导致超卖。必须用 Lua 脚本或 WATCH/MULTI 保证原子性。
• Redis 与 DB 库存初始不一致：预热时人工设置 Redis 库存与 DB 不一致，活动结束对账才发现超卖。预热必须以 DB 为准自动同步，且加 checksum 校验。
• MQ 消费者单线程消费：消费者并发度设为 1，百万消息堆积数小时，用户长时间收不到结果。需根据 DB 承受能力设置合理并发（如 50）并监控堆积。
• 缓存击穿未设空值：活动未开始时 key 不存在，请求穿透到 DB。应预热时即写入库存 key（含 0 值），并对不存在的活动 key 缓存短 TTL 空值。

某社交营销平台短链服务，累计短链 2000 亿条，日新增 5000 万条，短链访问 QPS 峰值 80 万，平均长链长度 200 字符。要求：短码长度 ≤ 7 位（62 进制可表达 3521 亿），长链访问 P99 < 30ms，同一长链生成相同短码（去重），短链永久有效。存储成本敏感，单条记录需控制在 100 字节以内。

1. 存储海量：2000 亿条单表无法承载，需分库分表且短码到库表的路由要高效；2. 短码冲突：自增 ID 转 62 进制有序易被遍历，哈希有碰撞；3. 缓存穿透：大量不存在的短码查询击穿到 DB；4. 长链去重：同一长链重复生成浪费存储且短码不一致；5. 读多写少：读 QPS 是写的 50 倍，缓存命中率要求 99%+。

采用"发号器 + 进制转换 + 布隆过滤器 + 多级缓存"架构：写链路用分布式发号器（号段模式）生成全局唯一 ID，转 62 进制得短码，保证不冲突且无序化（混淆码本防遍历）；长链做 MD5 去重表。读链路用 BloomFilter 判存在 → Redis 缓存 → DB 回源三级过滤，BloomFilter 拦截 99% 不存在请求。分库分表按短码哈希取模，保证读均匀。

接入层：Nginx + Lua 直接查 Redis，命中则 302 重定向；未命中回源应用层。BloomFilter 部署在应用层本地（Guava/CuckooFilter）或 Redisson RBloomFilter，容量 2000 亿，误判率 0.01%。

应用层：生成短码——号段模式从 DB 取 [start,end] 区间，自增发号，转 62 进制后加盐混淆（位置置换 + 异或）防遍历；长链 MD5 写 long_url_dedup 表去重。查询短码——BloomFilter 判存在 → Redis（短码→长链，TTL 7 天）→ DB 回源并回填缓存。

数据层：短码记录表按 short_code 哈希分 1024 库 × 4 表 = 4096 分片（ShardingSphere）；字段精简为 short_code(7)+long_url_md5(16)+db_offset，长链原文存 Tair/KV 存储。冷数据归档到 HBase。

• 布隆过滤器误判导致不存在的短码也查 DB，如何进一步降低穿透？
  采用双层 BloomFilter 或 CuckooFilter（支持删除）；对误判命中的空结果也缓存短 TTL（如 60s 空值缓存），形成第二道防线；监控误判率，超过阈值重建扩容。
• 号段发号器宕机如何保证发号不中断不重复？
  号段模式双 buffer：当前号段用到 20% 时异步预加载下一段；DB 主从切换时利用号段非连续性（每实例分配奇偶/步长隔离 ID 空间）避免重复；可结合雪花算法时钟回拨兜底。
• 2000 亿数据分 4096 分片，单分片仍有近 5000 万，热点短链怎么办？
  热点短链（如营销活动）单独抽到独立缓存集群 + 本地缓存（Caffeine，TTL 1s）；监控访问 TopN 短链自动加入热点白名单；DB 层对热点分片做读写分离，读走从库。
• 短链需要支持过期与统计点击量，架构如何扩展？
  过期：记录 expire_at，查询时校验并异步清理；统计点击量：302 重定向前异步写 Kafka，Flink 聚合后写 ClickHouse，避免同步统计拖慢重定向。

• 混淆码本泄露风险：固定的位置置换表一旦被逆推，短码可被批量遍历枚举。需定期轮换码本并对历史短码做版本标记兼容。
• 布隆过滤器不支持删除：短链删除后 BloomFilter 仍判存在导致永久误判。应选用 Counting BloomFilter 或 CuckooFilter 支持删除。
• 分片键选择不当：按自增 ID 取模分片会导致新短链集中在少数分片，写热点。应按短码哈希分片使写入均匀。
• 长链去重缓存未设上限：dedup 缓存无限增长撑爆 Redis。需设置淘汰策略（LRU）并控制容量，或仅对热门长链去重。

某互联网巨头春晚跨年红包活动，全国 8 亿用户参与，活动当晚 4 小时内分 10 轮抢红包，单轮峰值并发请求 50 亿/分钟（约 8300 万 QPS），红包总金额 100 亿元，单轮发放 10 亿个红包。要求：资金零差错、不超发不漏发、任意 IDC 故障自动切换、用户 3 秒内看到结果。部署在 5 大 Region（北京/上海/广州/成都/深圳）多活。

1. 极端峰值：8300 万 QPS 远超任何单系统承受，必须多级削峰；2. 资金强一致：红包金额不能错算，超发即资金损失，需精确到分；3. 多活容灾：单 Region 故障需秒级切换，不能中断活动；4. 随机算法公平：红包金额拆分要随机且总额守恒；5. 防薅羊毛：黑产批量薅红包，需实时风控。

核心是"提前预热 + 流量漏斗 + 异步发奖 + 多活容灾"：活动前将红包总额拆分预生成存入各 Region Redis（二倍均值法拆分）；用户请求经接入层限流 → 应用层 Redis 原子抢 → MQ 异步入账；采用"单元化多活"，按 userId 路由到归属 Region，故障时切流；资金对账贯穿活动前后，T+0 实时核对。

接入层：全球 CDN + 智能 DNS 按 GeoIP 路由到最近 Region；Nginx limit_conn 限制单 IP 并发；网关层 Sentinel 按用户分桶限流（每轮总请求数 = 红包数 × 容忍系数 5），超限直接返回"手慢了"。

应用层：红包提前拆分——二倍均值法：每次抢 = rand(0.01, 剩余金额/剩余人数×2)，保证总额守恒且金额分布随机；拆分结果预存 Redis List（key=redpacket:pool:{round}），抢红包 = LPOP 原子弹出。抢中后发 MQ 异步入账，前端轮询/长连接获取结果。

数据层：账户系统按 userId 分库分表，单元化部署；入账消费者批量聚合（每 100 条一批）写库降低 DB 压力；资金流水写 TiDB（分布式事务强一致）+ 异步同步到对账系统。容灾：5 Region 单元化多活，GSLB 秒级切流，每单元独立 Redis 与 DB，故障切换时未入账的红包凭 MQ 消息重放补偿。

• 单元化多活下，用户跨 Region 移动（如出差）如何保证数据一致？
  采用"归属单元"模型，用户数据有固定归属单元，跨单元访问走单元间 RPC；用户移动不改变归属，避免数据搬迁；强一致写必须在归属单元完成，读可走就近单元的异步副本。
• Redis LPOP 成功但 MQ 入账消息丢失，导致用户没拿到钱但红包池少了，怎么办？
  采用"先持久化再弹出"：LPOP 后立即写本地消息表（与弹出动作关联），异步投递 MQ 失败则补偿重投；定时对账任务比对 Redis 已弹出数与 DB 入账数，差额补发或回滚红包池。
• 8300 万 QPS 如何做实时风控识别黑产？
  风控前置到网关层，基于设备指纹 + 行为序列（点击频率、坐标轨迹）实时规则引擎（Flink CEP）；疑似黑产请求直接拒绝不进 Redis；黑名单用 BloomFilter 本地缓存拦截，避免风控本身成瓶颈。
• 活动期间某 Region 整体宕机，如何在不超发前提下切流？
  故障 Region 的红包池作废（标记失效），流量切到备用 Region 使用其独立预热的红包池；未入账的抢中记录通过 MQ 持久化日志在异地重放补偿；总控中心统一调度各 Region 红包配额，确保总额不超。

• 红包拆分精度丢失：用 double 计算金额导致浮点误差累计超发。必须用 int（分）或 BigDecimal 整数运算，全程避免浮点。
• 抢红包同步写账户：LPOP 后同步调账户系统入账，DB 成为瓶颈拖垮整个链路。必须异步入账，抢红包只保证 Redis 原子弹出。
• 多活红包池总额重复：各 Region 预热相同总额红包池，切流后重复发放导致超发。每个 Region 必须分配独立配额，总额按权重切分。
• 容灾切流未做幂等：故障重放的 MQ 消息重复入账导致用户多拿钱。入账必须以 (userId, round) 做幂等键去重。

某头部直播电商平台头部主播带货，单直播间在线峰值 500 万人，弹幕 QPS 50 万，下单 QPS 峰值 20 万，直播时长 4 小时。要求：弹幕端到端延迟 < 500ms、商品上架秒级推送、下单成功率 99.9%、视频首帧 < 1s 且全程不卡顿。系统含直播推拉流、IM 弹幕、商品系统、订单系统四大子系统。

1. 实时消息广播：500 万人在线，单条弹幕需广播放大成百万级推送；2. 消息风暴：50 万 QPS 弹幕不能全量下发，需合并裁剪；3. 瞬时下单洪峰：主播喊"上车"瞬间 20 万 QPS；4. 长连接管理：500 万 TCP 长连接的资源消耗与心跳维护；5. 音视频与互动协同：商品讲解与上架推送需与视频时序对齐。

采用"推拉结合 + 消息合并 + 分层削峰"：弹幕用 IM 长连接（WebSocket/TCP）推为主，热点消息合并广播（每 200ms 聚合一批下发）；视频走 CDN RTMP/HLS 推拉流，互动消息走独立通道；下单复用秒杀架构（Redis 预扣 + MQ 异步）。长连接网关做水平扩展 + 一致性哈希分片管理连接。

接入层：视频流推流到 CDN（阿里云/腾讯云直播），观众拉流走就近 CDN 边缘节点；IM 长连接网关集群（Netty），按 roomId 一致性哈希分片，单机维持 10 万连接，500 万在线需 50 台网关。

应用层：弹幕——用户发送弹幕入 Kafka，消费者聚合后按房间广播，每 200ms 合并一批（最多 50 条）下发，降低推送量 50 倍；商品推送——主播上架商品发 MQ，IM 网关按房间广播"上新"消息，客户端拉取商品详情；下单——Redis Lua 预扣库存 + RocketMQ 异步创建订单，复用 S01 秒杀方案。

数据层：弹幕消息存 MongoDB（写多读少、按 roomId+时间分片）；商品与订单走 MySQL 分库分表；在线人数用 Redis HyperLogLog 统计（PFADD/PFCOUNT 误差 < 1%）。热点房间商品缓存多级：本地 Caffeine + Redis。

• 500 万长连接的心跳与断线检测如何设计，避免心跳风暴？
  客户端心跳间隔 60s 带随机抖动（避免同时心跳打满），服务端 3 次未收到心跳判定断线；网关用 epoll + Netty IdleStateHandler 检测空闲，而非轮询；心跳复用连接做在线状态上报。
• 主播喊"上车"瞬间 20 万 QPS 下单，库存只有 1 万件如何避免 19 万请求打到 DB？
  网关层按预估库存×系数（如 1.5）限流，超限直接返回售罄；Redis Lua 预扣，扣减失败立即返回，不进 MQ 不进 DB；19 万请求中 18.5 万在 Redis 层被拦截，仅 1.5 万进 MQ。
• 弹幕合并广播后，用户看到的弹幕与视频时序错乱怎么处理？
  弹幕携带视频时间戳（相对于直播开始），客户端按时间戳渲染而非接收顺序；商品上架推送附带视频 PTS，客户端在对应 PTS 时刻弹出商品卡片，保证音视频与互动时序对齐。
• IM 网关单机故障，该机上 10 万连接用户全部断线重连，引发雪崩怎么办？
  客户端指数退避重连 + 随机抖动（1s/2s/4s/8s+随机），避免同时重连；DNS/配置中心感知网关故障后摘除节点；网关扩容预案预热，重连流量分散到剩余节点。

• 弹幕全量推送：50 万 QPS 弹幕全量广播给 500 万人，推送量达 2.5 亿 QPS，网关带宽与 CPU 爆炸。必须合并裁剪 + 限量下发。
• 长连接无分片管理：所有连接随机分布，房间用户散落各网关，广播需跨网关查询放大 RPC。应按 roomId 一致性哈希聚合到少数网关。
• 视频与互动同通道：弹幕与视频走同一连接，视频带宽挤占弹幕导致延迟。互动消息必须独立轻量通道。
• 在线人数用 SET 统计：500 万人 SADD 内存爆炸且统计慢。应使用 HyperLogLog，12KB 内存统计亿级基数，误差 < 1%。

某支付平台商户收款场景，头部商户（如大型超市总账户）日交易 2000 万笔，峰值扣款/入账 TPS 5 万，账户余额需实时准确。典型热点账户：营销活动发奖账户（单账户每秒被扣 3 万次）、平台主收款账户（所有交易汇总入账）。要求：余额零差错、扣款 RT < 50ms、T+1 对账必须平账、支持透支控制。

1. 行锁热点：同一账户并发扣款在 DB 形成行锁排队，TPS 被锁竞争拖到几百；2. 强一致要求：余额不能错，超扣即资金事故，不能像秒杀那样异步弱一致；3. 透支控制：余额不足要拒绝，且检查与扣减必须原子；4. 入账汇总：主收款账户 5 万 TPS 全部 UPDATE 同一行，锁冲突极度严重；5. 对账复杂：异步缓冲后余额与流水需精确核对。

核心思路"记账分离 + 异步汇总 + 影子账户"：将"记账"（记录流水）与"更新余额"解耦，高并发请求只写流水（无热点），余额更新异步聚合批量执行；对极端热点账户采用"影子账户"拆分——主账户拆为 N 个子账户，请求按 hash 路由到不同子账户并行扣减，消除单行锁热点；最终通过汇总任务合并子账户到主账户。读余额走缓存（准实时），强一致读走 DB。

接入层：扣款请求先入 Kafka/RocketMQ（按 accountId 分区保证同账户顺序），应用层消费批量处理；网关层对单账户限流防恶意刷。

应用层：记账——每笔交易写 account_log 流水表（按 accountId 分库，无单行热点）；余额更新——消费者聚合 100ms 窗口内同账户流水，计算净额后一次 UPDATE（单账户从 3 万 TPS 降到 10 TPS）。影子账户——主账户拆 16 个子账户，扣款按 txId hash 路由，并行无锁；定时（每 1s）将子账户净额汇总回主账户。

数据层：account_log 按 accountId 分 256 库；account 表余额更新用乐观锁（version 字段）兜底；余额缓存 Redis（TTL 1s 准实时），强一致读走 DB for update；T+1 对账：sum(account_log) = account.balance，不平则告警人工介入。

• 异步聚合后余额有秒级延迟，用户实时查余额看到的不是最新值怎么办？
  读余额时合并"DB 余额 + 缓冲区未落库净额"作为可用余额返回；强一致场景（如提现）走 DB for update 同步扣减不进缓冲；客户端展示余额标注"准实时"。
• 影子账户拆分后，用户从子账户 A 扣款但钱在子账户 B，怎么保证不透支？
  子账户间不直接交互，每个子账户有独立额度（主账户余额按权重预分配）；子账户余额不足时向主账户"借调"（同步锁），或拒绝后重试其他子账户；定期汇总保证主账户总额守恒。
• 聚合任务宕机导致缓冲区流水丢失，如何保证资金不丢？
  流水先持久化到 account_log 表（与业务同事务），聚合只读流水不持有数据；宕机重启后从 account_log 重新聚合未落库部分；用 checkpoint 记录已处理流水位点，保证 exactly-once。
• T+1 对账发现 sum(log) != balance，如何定位与修复？
  按时间分片对比流水与余额变更，定位差异时间窗口；用 account_log 重新重放计算应有余额，与实际余额比对；差异记录入差异表，多扣补回、少扣补扣，全程留痕审计。

• 检查余额与扣减非原子：先 SELECT 余额再 UPDATE，两步间并发导致超扣。必须用 UPDATE...WHERE balance+amt>=0 单语句原子完成。
• 缓冲区无持久化：净额累加只在内存，宕机即丢失资金变更。流水必须先落库，聚合只做计算不持有权威数据。
• 影子账户汇总与扣减并发冲突：汇总任务 UPDATE 主账户时与扣款并发导致余额错乱。汇总需加账户级锁或串行化处理。
• 对账只对总额：总额平账不代表每笔正确，可能多扣少扣相互抵消。必须按笔核对流水与余额变更明细。

某订单系统中，多个服务实例需对同一资源（如订单号生成、库存扣减、定时任务触发）做互斥控制。系统部署 8 个微服务实例，并发请求峰值 5000 QPS，存在跨 JVM 同步需求。要求：锁可靠性高（不能因持锁节点宕机导致死锁）、获取/释放延迟 < 10ms、支持锁自动续期（业务执行时间不可预估）、可重入。基础设施含 Redis Cluster 与 ZooKeeper 集群。

1. 死锁风险：持锁节点宕机不释放锁，其他节点永久阻塞；2. 锁超时与业务超时不匹配：锁过期但业务未完成，导致并发执行；3. 网络分区：Redis 主从切换期间锁丢失，两个节点同时持锁；4. 可重入：同一线程递归调用需重入同一把锁；5. 选型权衡：CP（ZK）与 AP（Redis）的性能与一致性取舍。

分布式锁三要素：互斥性、防死锁、可重入。选型按场景：性能优先（CP 弱一致可接受）选 Redis SET NX PX + Lua 释放 + 看门狗续期（Redisson 实现）；强一致优先选 ZooKeeper 临时顺序节点（CP，session 失效自动释放锁）；跨机房/正确性敏感默认 ZK/etcd + fencing token + 幂等；Redlock 仅作可选且争议大（见 E06.02/C08），勿当默认“更高可靠”。锁续命用后台线程定时（锁 TTL/3）续期，业务结束停止续期并主动释放。

Redis 方案（Redisson）：加锁用 SET key value NX PX 30000（value=UUID+threadId 标识持锁者）；释放用 Lua 脚本比对 value 后 DEL（防误删他人锁）；看门狗（WatchDog）每 10s（TTL/3）检测锁仍持有则续期到 30s，业务结束主动释放并停止续期。支持可重入（Hash 结构记录重入次数）。

ZooKeeper 方案：创建临时顺序节点 /lock/node-xxxx，判断自己是否最小节点序号，是则获锁，否则 watch 前一个节点；持锁者宕机 session 失效自动删除临时节点触发下一节点获锁（避免死锁）；可重入用本地计数器 + 节点数据记录重入次数。

选型决策：订单防重、库存扣减等短临界区用 Redis（性能高、AP 可接受偶尔失效兜底）；金融转账、配置变更等强一致用 ZK；跨多机房正确性敏感优先 ZK/etcd + fencing；Redlock 多数派可选但需接受 Kleppmann 争议与时钟假设。

• Redis 主从切换时锁丢失导致两个节点同时持锁，如何彻底解决？
  AP 的 Redis 无法根本解决，可升级为 Redlock（多数节点加锁）降低概率；或业务侧加幂等兜底（持锁后仍做唯一性校验）；强一致场景直接换 ZK/etcd。
• 看门狗续期线程所在 JVM 卡顿（GC）导致续期失败，锁过期后他人获锁，怎么处理？
  业务执行前记录持锁 token，关键操作前再次校验 token 仍归属自己，否则中止；或业务设计为幂等，重复执行无害；GC 调优减少 STW 时间。
• ZooKeeper 的 watch 惊群效应如何优化？
  用临时顺序节点 + 只 watch 前一个节点（链式通知）而非全部 watch 同一节点，每个节点获锁只需等前驱删除，避免所有等待者同时被唤醒竞争。
• Redlock 被马丁克莱因质疑时钟漂移问题，你怎么看？
  Redlock 依赖各节点时钟一致，NTP 漂移会导致锁 TTL 计算偏差，理论上存在安全漏洞；实践中可通过引入 fence token（单调递增序号）让资源端拒绝旧 token 请求来弥补，但增加了资源端负担。
• Redlock 可靠性之争：antirez 与 Martin Kleppmann 各自的观点是什么？工程上到底该怎么用、如何防脑裂？
  争议焦点是"Redlock 是否真的提供互斥安全性"。antirez（Redis 作者）立场：Redlock 假定各节点时钟误差有界、失败检测（TTL 过期）基本可用，在合理系统模型下能给出"足够好"的互斥，且多数派（N/2+1）能容忍少数节点故障。Martin Kleppmann 反驳：在异步模型里网络延迟与 GC 停顿无上界，若持锁客户端被暂停超过 TTL，锁自动过期，另一客户端可获锁，此时两者同时持锁，Redlock 并未提供互斥；他认为真正的安全来自fencing token（单调递增序号）——资源端只接受序号更大的请求、拒绝旧请求，而非依赖锁服务本身。工程结论与适用边界：① 对"偶尔双持锁可容忍 + 业务幂等兜底"的场景（如去重、防重复调度），Redlock 可用；② 对资金等强一致关键路径，不要只靠 Redlock，应叠加 fencing token 或由 ZK/etcd 这类基于共识的实现提供更强保证；③ 防脑裂三件套：锁带单调递增 token + 资源端校验 token 拒绝陈旧操作 + 业务幂等/唯一约束兜底，三者齐备才能把脑裂风险降到可接受。

• 释放锁误删他人锁：A 持锁过期后 B 获锁，A 业务结束直接 DEL 删了 B 的锁。必须用 Lua 比对 value(唯一标识) 后再删除。
• SETNX 与 EXPIRE 非原子：分两步执行，SETNX 后宕机未 EXPIRE 导致锁永不过期死锁。必须用 SET key value NX PX 一条命令原子完成。
• 无看门狗锁过期业务未完：固定 TTL 但业务超时，锁过期他人获锁导致并发。必须看门狗续期或业务幂等兜底。
• 锁不可重入导致死锁：同一线程递归调用再次获锁阻塞。需用 Hash 结构记录 threadId 与重入次数支持重入。

某电商交易核心链路"下单"涉及 4 个微服务：订单服务（创建订单）、库存服务（扣减库存）、优惠券服务（核销券）、积分服务（增加积分）。要求这 4 个操作要么全部成功要么全部回滚，数据强一致或最终一致。系统日均订单 500 万，峰值 TPS 1 万，服务间通过 Dubbo/RPC 调用，数据库独立。需在一致性、性能、复杂度间权衡选型。

1. 跨库事务：4 个服务 4 个独立 DB，本地事务无法覆盖；2. 网络不可靠：RPC 调用超时但实际成功，重试导致重复执行；3. 部分失败回滚：库存扣减成功后积分服务失败，需回滚已成功的库存；4. 性能损耗：2PC 同步阻塞使 TPS 下降数倍；5. 幂等保证：重试与补偿必须幂等，否则数据错乱。

按一致性强度分层选型：强一致用 TCC（Try-Confirm-Cancel，业务侵入大但性能好，适合资金扣减）或 XA/2PC；最终一致用 Seata AT 模式（自动生成回滚 SQL，2PC 改造小，适合 CRUD）或本地消息表（业务与消息同事务，异步投递保证可靠投递）或事务消息（RocketMQ 半消息）。原则：核心交易链路强一致用 TCC，非核心（积分、通知）最终一致用消息表/事务消息异步解耦。

方案一：Seata AT（最终一致）：全局事务由 TC 协调，各分支注册分支事务；一阶段执行业务 SQL 并自动记录 before/after image 到 undo_log，本地事务提交；二阶段全成功则异步删除 undo_log，任一失败则按 undo_log 反向生成回滚 SQL 补偿。适合订单/库存等 CRUD 场景，无需改业务代码。

方案二：TCC（强一致高性能）：Try（预留资源，如冻结库存）、Confirm（确认扣减）、Cancel（释放预留）。订单服务作为事务发起者编排，库存/券/积分各自实现三阶段接口；Confirm/Cancel 由 TC 重试保证最终执行，必须幂等。适合资金等需精确控制的场景。

方案三：本地消息表（最终一致）：订单服务本地事务内同时写 order 表与 message 表（同事务保证一致），定时任务扫描 message 表投递 MQ；下游服务消费 MQ 执行业务并幂等。积分等弱一致场景用此方案，解耦且可靠。

• Seata AT 全局锁导致性能下降，高并发场景如何优化？
  热点数据改用 TCC 避免 AT 的全局锁竞争；或 AT 模式下配置读已提交隔离级降低锁持有时间；对非核心分支（如积分）改异步消息表，减少全局事务分支数。
• TCC 的 Cancel 阶段执行失败（如下游服务宕机），如何保证最终回滚？
  TC 会持续重试 Cancel 直到成功（需 Cancel 接口幂等）；若长期失败需人工介入；Try 阶段预留的资源需有超时自动释放机制（如冻结库存 30 分钟自动解冻）。
• 本地消息表消息已投递但下游消费失败，如何处理？
  MQ 消费失败走重试机制（指数退避），达到最大重试后进死信队列人工处理；下游消费必须幂等（基于 bizId 去重），重试不会导致重复执行业务。
• RocketMQ 事务消息相比本地消息表有什么优势？
  事务消息省去本地消息表与扫描任务，半消息机制由 MQ 服务端回调检查本地事务状态，更轻量；但强依赖 MQ 的事务能力，且回查接口需业务实现，复杂度转移。
• TCC 三坑（空回滚/悬挂/幂等）的根因是什么？如何破解，尤其是防悬挂设计？
  三大坑根因：① 空回滚——Try 的 RPC 超时/网络分区，TC 判定 Try 失败并发起 Cancel，但 Try 后来才真正执行；Cancel 时本地无预留资源记录，若直接报错会阻塞回滚。② 悬挂——Cancel 已执行（或标记为已取消）后，被延迟的 Try 才到达并执行了真实预留，这笔资源永远无法被 Confirm/Cancel，造成数据不一致。③ 幂等——TC 重试或网络重发导致 Confirm/Cancel 多次到达，重复执行会重复扣减/释放。破解：引入事务状态表（按全局事务 ID + 分支 ID）：① 防悬挂：Try 执行前先查状态，若已 CANCELLED 则直接拒绝 Try（空回滚标记存在即不执行真实预留）。② 空回滚处理：Cancel 时若无 Try 记录（status 非 INIT），插入 CANCELLED 空回滚标记并返回成功，不报错。③ 幂等：Confirm/Cancel 执行前校验 status，已 CONFIRMED/DONE 则直接返回成功；状态机仅允许 INIT→CONFIRMED / INIT→CANCELLED 单向流转。④ 兜底：Try 预留资源设超时自动释放（如冻结库存 30 分钟解冻），避免悬挂资源长期占用。

• 跨服务调用未传 XID：RPC 调用未透传 Seata 全局事务 ID，分支事务未纳入全局事务管理，回滚失效。必须配置事务上下文透传（Seata 自动织入或手动传 XID）。
• TCC 未做幂等：Confirm/Cancel 重试导致重复扣减或重复释放。必须用事务状态表记录 Confirm/Cancel 已执行，重复请求直接返回成功。
• 本地消息表与业务非同事务：消息写入与业务操作分两个事务，业务成功消息丢失或反之。必须同一本地事务内完成。
• 空回滚与悬挂：Cancel 先于 Try 执行（空回滚），或 Cancel 后 Try 才到（悬挂）。TCC 需记录 Try 是否执行，Cancel 前检查，Try 前检查是否已 Cancel。

某订单系统分库分表后（1024 库×4 表），MySQL 自增主键无法保证全局唯一，需分布式 ID 方案。系统部署 20 个应用实例，峰值发号 TPS 10 万。要求：ID 全局唯一、趋势递增（利于 B+ 树索引）、64 位 long 型（兼容现有 bigint 主键）、对业务无侵入、生成延迟 < 1ms。需考虑时钟回拨与机器位分配问题。

1. 全局唯一：多实例并发不能重复；2. 趋势递增：保证索引性能，不能完全随机；3. 时钟回拨：雪花算法依赖机器时钟，NTP 回拨导致重复 ID；4. 机器位分配：10 位机器位仅 1024 实例，动态扩缩容需协调；5. 高性能：10 万 TPS 不能依赖 DB 每次生成。

主流方案对比：雪花算法（Snowflake，1 位符号 + 41 位时间戳 + 10 位机器 + 12 位序列号，性能极高无 DB 依赖，需解决时钟回拨）；号段模式（Leaf-Segment，DB 存 max_id，应用批量取号段缓存本地，性能高且趋势递增，依赖 DB）；Redis INCR（简单但依赖 Redis 可用性、有网络开销）。选型：无 DB 依赖选雪花（需处理回拨），强递增选号段模式，二者可结合（Leaf 双 buffer 号段 + 雪花兜底）。

方案一：雪花算法：41 位时间戳（约 69 年）+ 10 位 workerId（1024 实例，由 ZK/配置中心分配）+ 12 位序列号（同毫秒内 4096 个）。时钟回拨处理：记录上次时间戳，回拨 < 5ms 则等待回拨时间，> 5ms 则报错或用扩展位借位。

方案二：号段模式（Leaf-Segment）：DB 表 leaf_alloc 存 biz_tag、max_id、step；应用取号时 UPDATE max_id=max_id+step 拿到 [old, old+step] 号段缓存在内存，双 buffer 预加载（用到 10% 时异步加载下一段）；趋势递增且抗 DB 故障。

选型决策：订单 ID 用雪花（无 DB 依赖、性能高）；对严格递增有要求的（如流水号）用号段模式；分库分表路由可复用 ID 的 workerId 或取模位。

• 雪花算法机器位只有 10 位 1024 实例，容器化动态扩缩容如何分配 workerId？
  用 ZooKeeper/etcd 持久顺序节点分配 workerId，实例启动注册领取，宕机后回收复用；或基于 IP+端口哈希 + 冲突检测动态分配；K8s 场景可用 Pod 序号 + StatefulSet 稳定标识。
• 号段模式重启会丢失未用完的号段导致跳号，能否避免？
  跳号是号段模式固有特性（用空间换性能），业务上 ID 跳号一般可接受；若强需求连续，可缩小 step 降低跳号量，或持久化当前已用位点（但牺牲性能）。订单场景跳号不影响业务。
• 雪花算法生成的 ID 暴露了生成时间，存在安全隐患怎么处理？
  对对外暴露的 ID 做混淆（如加密或 Base62 + 混淆码本变换）；内部主键用原始雪花 ID 保证有序与性能，对外 ID 用混淆后的不可逆版本。
• 分库分表时如何用分布式 ID 兼顾路由均衡？
  可在 ID 中预留分片位（如低 10 位作为分片键），或生成后对 ID 取模路由到库表；雪花 ID 因高位是时间戳趋势递增，取模后天然均匀分布。

• 时钟回拨未处理：NTP 同步导致时钟回拨，生成重复 ID。必须检测回拨并等待或报错，不可静默继续。
• workerId 重复：两实例配置相同 workerId 生成重复 ID。必须集中分配（ZK）并加唯一性校验。
• 号段模式单 buffer 断供：号段用完才去 DB 取，DB 抖动导致发号中断。必须双 buffer 预加载，用到 10% 异步取下一段。
• 序列号溢出未处理：同毫秒超 4096 个请求序列号归零，未等待下一毫秒导致重复。必须序列号满后 spin 等待下一毫秒。

某电商微服务集群 50 个服务，调用链平均深度 8 层。大促期间订单服务 RT 从 50ms 飙升到 5s，随后用户服务、商品服务相继变慢，最终网关线程池耗尽整个集群不可用（雪崩）。监控显示：下游支付服务因 DB 慢查询 RT 飙升，但上游未及时熔断，线程被积压耗尽。要求：快速定位雪崩根因、设计熔断降级方案防止扩散、建立长效治理机制。

1. 雪崩传播：底层服务故障沿调用链向上传染，逐层耗尽线程池；2. 根因定位难：8 层调用链，故障在底层但表现于上层，需全链路追踪；3. 熔断时机：熔断阈值设置不当，过灵敏误杀、过迟失效；4. 线程池隔离：不同下游共享线程池，一个下游拖垮全部；5. 治理长效：事前预防、事中止损、事后复盘机制缺失。

雪崩本质是资源耗尽级联：下游慢→上游线程阻塞→上游线程池满→上游不可用→逐层向上。治理三道防线：熔断降级（Sentinel/Resilience4j，异常率/RT 超阈值自动熔断走降级；Hystrix 已停止维护，仅作演进对比）、线程池隔离（不同下游独立线程池，避免相互拖累）、限流（入口限流防止过载）。排查用链路追踪（SkyWalking/Zipkin）还原调用拓扑，定位最慢节点。

排查层（定位根因）：通过 SkyWalking 链路追踪按 traceId 还原完整调用链，找出 RT 异常的 span（本例为支付服务的 DB 查询）；结合 Prometheus + Grafana 监控确认支付服务 DB 慢查询（连接池等待时间飙升）；最终根因：大促流量导致支付 DB 某热点表锁等待。

止损层（防止扩散）：在订单服务对支付服务的调用配置 Sentinel 熔断规则（慢调用比例 > 50% 持续 10s 触发熔断，熔断 30s 后半开探测）；线程池隔离——订单服务调用不同下游用独立线程池（支付池 50、用户池 50），支付慢不拖垮用户调用；降级策略——支付熔断后走"先创单后支付"异步流程。

治理层（长效机制）：全链路压测发现薄弱环节；服务依赖梳理与容量评估；关键服务设置 SLA（RT P99 < 200ms）并接入告警；线程池与连接池参数定期 review；故障演练（Chaos Engineering）验证熔断降级有效性。

• 熔断阈值如何科学设定，避免误杀或失效？
  基于历史监控数据设定：RT 阈值取 P99 的 2-3 倍，异常率阈值取正常异常率的 5 倍；最小请求数保证统计有意义（如 10s 内 > 100 次）；上线后灰度观察调整，结合压测验证。
• 线程池隔离导致资源利用率低，如何平衡隔离与效率？
  核心/有故障风险的下游用线程池隔离，非核心共用线程池；或用信号量隔离（轻量）替代部分线程池；动态线程池（如 Dynamic-TP）支持运行时调参，按负载弹性调整。
• 链路追踪数据量大，如何控制采样与存储成本？
  正常流量低采样率（1%），异常流量 100% 采样（异常请求必采）；Trace 数据存 Elasticsearch 仅保留 7 天，慢调用明细存 ClickHouse；按服务维度采样，核心服务提高采样率。
• 如何做故障演练验证熔断降级是否真的生效？
  用 ChaosBlade 注入下游延迟/异常/宕机，观察上游是否在预期时间内熔断并降级；验证线程池隔离是否生效（故障下游不影响其他下游）；演练后核对监控告警是否及时触发。

• 共享线程池未隔离：所有下游调用共用一个线程池，一个慢下游耗尽线程拖垮全部调用。必须按下游重要性做线程池隔离。
• 熔断后无降级直接报错：熔断生效但无降级逻辑，用户体验更差。每个熔断点必须配套降级方案（默认值/异步/缓存）。
• 超时设置层层叠加：各层超时简单累加，底层慢但上层超时更长，无法及时熔断。应上层超时 < 下游超时×调用数，快速失败。
• 熔断半开探测流量过大：半开状态放行过多探测请求，下游未恢复又被打挂。半开应只放行少量请求（如 1-5 个）逐步探测。

某商品系统，商品信息存 MySQL，读 QPS 10 万，命中率要求 95%+，用 Redis 做缓存。商品信息由运营后台修改（写 QPS 约 50），C 端用户高频读取。要求：用户看到的商品信息与 DB 最终一致（延迟 < 1s 可接受），绝不能读到脏数据（如价格错乱）。需设计更新缓存策略，避免先删缓存再更新 DB 期间的并发脏读问题。

1. 并发读写竞态：更新 DB 与删除缓存的时序在并发下产生脏数据；2. 缓存删除失败：DB 更新成功但缓存删除失败，长期脏数据；3. 主从延迟：读从库时从库尚未同步，读到旧值回填缓存；4. 一致性强度选择：强一致性能损耗大，最终一致需控制延迟窗口；5. 复杂更新场景：多表聚合的缓存更新粒度与时机。

核心原则：Cache Aside 旁路缓存，读先查缓存未命中查 DB 并回填，写更新 DB 后删除缓存（非更新缓存）。并发问题用延迟双删（删缓存→更新 DB→sleep→再删缓存）覆盖并发脏读窗口；删除可靠性用消息队列重试或Canal 订阅 binlog异步删缓存保证最终一致。强一致场景（如库存）用"更新 DB 后加锁删缓存 + 读时校验版本"。

方案一：延迟双删（最终一致）：写操作先删缓存→更新 DB→延迟 500ms（覆盖主从同步+读耗时）→再删缓存。第二次删除覆盖并发读旧值回填的脏数据。延迟时间需大于"主从同步延迟 + 一次读耗时"。

方案二：Canal 订阅 binlog（最终一致推荐）：业务只更新 DB，Canal 订阅 MySQL binlog，解析变更后发 MQ，消费者删除对应缓存 key。业务与缓存解耦，删除可靠（MQ 重试），覆盖主从延迟（监听主库 binlog）。

方案三：加锁强一致：写操作更新 DB 后获取分布式锁删缓存，读操作未命中时加锁读 DB 回填，版本号校验。性能损耗大，仅用于强一致场景（如价格、库存）。

• 为什么是删除缓存而不是更新缓存？
  更新缓存有并发问题（A、B 先后写 DB，但 B 先更新缓存 A 后更新导致缓存与 DB 不一致）；且更新缓存有写放大（多次写只读一次时浪费）；删除缓存是懒加载，下次读时按最新 DB 回填，更简单可靠。
• 延迟双删的延迟时间如何确定，太短太长有何影响？
  延迟需 > 主从同步延迟 + 一次读 DB 耗时（通常 200-500ms）。太短则并发读旧值回填发生在第二次删除后，脏数据残留；太长则脏数据窗口大，用户感知不一致。可监控主从延迟动态调整。
• Canal 订阅 binlog 删缓存，如果 Canal 挂了导致缓存不删，如何兜底？
  Canal 高可用部署（主备切换）；缓存设置合理 TTL 兜底过期；监控 binlog 位点与缓存删除的延迟，积压告警；极端情况人工触发全量缓存刷新。
• 先更新 DB 再删缓存，会不会有读到旧 DB 回填旧缓存的问题？
  理论上有极小概率：读线程读旧 DB（更新前）→ 写线程更新 DB 并删缓存 → 读线程将旧值回填缓存。此窗口极小（需读线程在更新前读、更新后回填），可加短暂延迟删除或版本校验规避。

• 先删缓存再更新 DB 无双删：删缓存后、更新 DB 前，并发读回填旧值到缓存，DB 更新后缓存仍是旧值且长期残留。必须延迟双删覆盖此窗口。
• 更新缓存而非删除：并发写导致缓存与 DB 不一致，且写放大。应删除缓存走懒加载。
• 缓存删除失败不重试：DB 更新成功但删缓存失败，脏数据长期存在。必须 MQ 重试或 Canal 补偿保证删除最终成功。
• 读从库回填缓存：主从延迟期间读到从库旧值回填缓存，导致脏数据。Canal 监听主库 binlog 删缓存可覆盖，或读强制走主库。

某业务在 @Transactional 方法内保存异常数据成功后，调用企业微信给班主任推送"处理完成"通知。某次因下游校验失败，业务方法抛出异常、事务回滚，数据库无此记录；但班主任已收到通知，点进去查不到数据，投诉"系统骗人"。监控显示通知发送量 > 实际成功落库量，存在"幽灵通知"。

1. 原子性：通知与业务写入要么都成功、要么回滚时都不发生；2. 不阻塞主流程：发送是外部 IO，不能拖慢事务；3. 上下文透传：异步线程需拿用户/租户信息；4. 可靠性分级：普通通知允许极小概率丢失，跨系统事件则不允许。

按三维分层定位：①是否有活跃事务（事务内 vs 导入批量）；②异常是否上抛（service 内部吞异常 / setRollbackOnly 会在回滚后仍发通知）；③可靠性要求（允许丢失 → afterCommit；不允许丢失 → 本地消息表）。根因几乎都落在"事务内直接开线程"或"外层异步但吞异常"两类反模式（原理题见 C05.11）。

方案 A（首选，允许极小概率丢失）：用 TransactionSynchronizationManager.afterCommit 钩子，事务提交成功后才把发送任务丢线程池；回滚则钩子不触发，通知绝不发出。无事务场景（导入）直接异步，一套代码自适应。

方案 B（消息绝不可丢）：升级本地消息表——业务与消息同事务落库，定时任务 / MQ 补偿推送（详见 C09.02 / S02.02），宕机重启可继续处理。

// 根治：事务提交后才异步发通知（回滚不触发）
asyncAfterCommitExecutor.executeAfterCommit(() ->
    wechatSender.sendToHeader(abnormalSeqList, classInfoId, orgId, submitterUserId));

// 反例（导致幽灵通知）：service 内部吞异常 + 外层异步
@Transactional
public void saveAbnormal(...) {
    try { mapper.insert(...); }
    catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); }
    // 方法正常 return，事务回滚，但外层 execute 照常发通知！
}

• 追问 1：如何快速定位是哪种反模式？查发送点是否在 @Transactional 方法内直接 execute（时序错乱），或发送是否在事务方法外且 service 有 catch+setRollbackOnly（吞异常）。前者异步线程早于 commit 查库为空；后者数据库无记录但通知已发。
• 追问 2：afterCommit 后服务宕机通知丢了怎么办？普通通知人工可复核，接受；强可靠场景必须本地消息表（方案 B）。
• 追问 3：异步线程拿不到租户 ID 怎么办？afterCommit 阶段主线程 ThreadLocal 已销毁，所需数据全部闭包传入；MDC 手动 copy（参考 C11.08）。

• 事务内直接 executor.execute：异步早于 commit，查不到新数据且回滚后仍发。
• service 内部 catch + setRollbackOnly 后在外层异步发送：方法正常 return，回滚却发通知（最隐蔽）。
• afterCommit 的 task 内读取 ThreadLocal / MDC：已销毁，必得 null。
• 认为事务事件（@TransactionalEventListener）能保送达：宕机即丢，强可靠需本地消息表。

口诀："提交才发、回滚不发、参数闭包、强可靠上消息表。"先判反模式（内开线程 / 外吞异常），再按可靠性选 afterCommit 或本地消息表；绝不依赖 ThreadLocal 在异步回调中取值。与原理题 C05.11 形成"场景 + 原理"双视角。

某头部电商平台订单中心，订单表（t_order）单表累计数据已达 12 亿行，日新增约 500 万行。业务规模：日均订单量 500 万，大促峰值 2 万 TPS 写入、8 万 QPS 查询。单表已出现严重性能瓶颈：订单列表查询 P99 从 80ms 飙升至 3.5s，统计报表查询超时频发，退款流程因查询缓慢导致超时率上升至 3%。当前架构为 MySQL 8.0 一主两从 + SSD 存储（NVMe 3.2TB），主库内存 256GB，已无法通过垂直扩容解决数据量增长问题，必须进行水平分库分表改造。

1. 分片键选择：订单查询维度多（用户维度、商家维度、时间维度），单一分片键无法覆盖全部查询场景，跨片查询会放大性能损耗。2. 数据均匀分布：大商家订单量占比 40%，按商家 ID 分片会导致严重数据倾斜。3. 不停机迁移：12 亿存量数据迁移期间业务不可中断，双写一致性与回滚机制必须可靠。4. 扩容成本：从 4 库扩到 8 库时，若分片策略不当需要全量数据重新分布，停机时间不可接受。5. 分布式事务：分库后订单与子订单、订单与库存跨库操作需保证最终一致性。

采用"容量评估 → 分片键选择 → 分片策略设计 → 迁移方案制定 → 扩容预案 → 治理体系"六步分析框架。容量评估按 3 年数据量规划（12亿 + 500万×365×3 ≈ 65 亿），按单表 2000 万上限计算需 325 张表，取 2 的幂次方对齐为 16 库 × 16 表 = 256 张物理表。分片键以 user_id 为主（C 端查询占比 85%），通过基因法将 user_id 的低位基因植入 order_id 解决商家维度查询问题。迁移采用"影子双写 + 全量同步 + 增量校验 + 灰度切读"四阶段方案。

接入层：引入 ShardingSphere-JDBC 5.2.0 作为分片中间件，采用 JDBC 直连模式（非 Proxy），避免额外网络跳转，支持行级分布式事务（XA / BASE 可选）。配置分库分表规则，分库算法采用 user_id % 16，分表算法采用 user_id / 16 % 16，保证同一用户数据落在同一物理库的不同表中。

应用层：订单 ID 采用 Snowflake 改造方案，将 user_id 的低 4 位作为"分片基因"嵌入 order_id 的指定 bit 位，商家查询时通过 order_id 中的基因反向路由到对应分片，避免全表扫描。跨片查询通过绑定表（t_order 与 t_order_item 按 user_id 绑定）和广播表（t_merchant）优化。

数据层：16 库分布在 4 台物理 MySQL 实例上（每实例 4 库），主从架构为一主一从。扩容采用"倍增翻倍"策略：4 库扩 8 库时，每个原分片的数据按 user_id 二分，仅涉及数据搬移不涉及重新 Hash，通过影子表预同步 + 双写 + 一次性切换完成，停机窗口控制在 30 分钟内。

• 1. 双写迁移过程中，如果影子表写入失败如何处理？是否会影响主流程？
  采用异步补偿机制：影子表写入失败写入 MQ 死信队列，不影响主库写入。补偿任务定期消费死信重试，超过 3 次告警人工介入。迁移窗口内保持双写开关可降级，确保主流程可用性优先。
• 2. 分库分表后，全局唯一 ID 如何保证？Snowflake 时钟回拨问题如何解决？
  采用 Snowflake 改进方案（如美团 Leaf 或百度 UidGenerator），Leaf-segment 方案通过 DB 号段模式分配，避免时钟依赖；Leaf-snowflake 方案通过 ZK 持久化 workerId 并启用时钟回拨检测，回拨超过 5ms 直接拒绝服务等待追平。
• 3. 分库后的分布式事务如何处理？强一致性 vs 最终一致性如何取舍？
  交易核心链路（下单扣库存）采用 Seata AT 模式保证最终一致（全局锁防脏写，非线性强一致）；非核心链路（积分、通知）采用本地消息表 + MQ 最终一致。评估维度：一致性要求、吞吐量、实现复杂度。金融场景强制强一致，营销场景可接受秒级最终一致。
• 4. 从 4 库扩容到 8 库时，如何实现不停机平滑扩容？
  采用倍增翻倍策略：原 user_id % 4 的每个分片，按 user_id / 4 % 2 拆分为两个新分片。预先在新库创建影子表并同步数据，切换时仅需更新路由规则（模数从 4 改为 8），同一 user_id 的数据映射关系不变，无需全量重新 Hash。
• 5. 如何监控分片后的数据分布是否均匀？发现倾斜后如何再平衡？
  搭建分片监控看板，采集各分片数据量、QPS、慢查询指标，按标准差判断倾斜度。发现倾斜后，对大用户可采用"二级分片"策略（同一 user_id 的订单按时间再分表），或对冷热数据分层（热数据留在分片表，冷数据归档到 HBase）。

• 分片键选择失误：初期为简化按 merchant_id 分片，后续 C 端用户查询全路由导致性能崩塌。规避：充分分析查询热点分布，C 端为主的业务必须以 user_id 为分片键，辅以基因法解决跨维度查询。
• 分表数量取非 2 的幂次方：分 10 库 10 表，扩容到 20 库时取模映射关系全变，必须全量数据重新分布。规避：分片数必须为 2 的幂次方（16、32、64），扩容时倍增翻倍，数据无需重新 Hash。
• 迁移期间不做数据校验：双写期间由于网络抖动导致部分数据不一致，切换后发现数据丢失。规避：必须实现全量 + 增量双向校验工具（如 DataX + 自研 diff 程序），校验不一致率低于 0.001% 才允许切换。
• 跨片 JOIN 和分页：分库后直接使用 LIMIT 分页，ShardingSphere 归并时需拉取所有分片数据，深度翻页性能极差。规避：禁止跨片深分页，采用游标分页（基于 order_id 的 where id > lastId）或 ES 二级索引方案。
• 分布式事务滥用：所有操作都套 XA 强一致事务，吞吐量下降 70% 以上。规避：按业务场景区分，仅核心交易链路用强一致，其余用最终一致，事务粒度最小化。

上述方案解决了"数据量大"的横向扩展问题，但单分片的读 QPS 打满单机后仍需进一步拆分读写压力，此时要在分库分表之上叠加读写分离，形成两层叠加架构：第一层读写分离解决读 QPS 瓶颈（主库写 + 从库读），第二层分库分表解决单库单表数据量瓶颈（水平拆分），两者叠加后每个分片内部再做读写分离——主分片写 + 从分片读。

联合路由策略（ShardingSphere 为例）：先按分片键路由到数据源组，再在组内做读写分离——写请求路由到主分片（如 ds_0.master），读请求路由到从分片（如 ds_0.slave_0），支持权重负载均衡。典型拓扑：order_id % 4 路由到 ds_0~ds_3 四个数据源组，每组内部配置一主多从，即"4 主 × N 从"整体结构，分片键路由与读写分离路由两级叠加。

主从延迟问题：分片后写后立即读一致性更难保证（主从延迟被多分片放大）。解决方案三件套：① 写主库后短窗口内强制走主库（@Master 注解 / HintManager.setMasterRouteOnly()）；② 半同步复制，至少一个从库 ACK 后再应答；③ 延迟窗口期走 Redis 缓存兜底。ShardingSphere 通过 readwrite-splitting 与 sharding 联合配置实现"先分片、再读写分离"的路由链路。

跨库事务：同一分片内仍可走本地事务（ACID 保证）；跨分片则必须选择分布式事务——XA 两阶段提交（ShardingSphere 集成 Atomikos/Narayana，强一致但性能差）或 Seata AT 模式（最终一致，适合订单核心链路），非关键链路用可靠消息最终一致。设计原则是事务边界最小化，尽量将业务收敛到单分片内。

数据迁移与扩容：除倍增翻倍外，一致性 hash 分片可将扩容数据迁移量从 50% 降到 25%（只迁移环上受影响节点）；ShardingSphere 的 scaling 模块支持在线弹性扩缩容——先影子表同步 + 双写，校验一致后灰度切流，实现不停机扩容。

• 分层叠加顺序：先解决"数据量"再解决"读压力"，顺序不可颠倒；每个分片独立做主从，形成"主分片写 + 从分片读"的最小闭环
• 写后读一致性：强制主库 + 半同步复制 + 缓存兜底三件套，按业务场景分级使用，避免一刀切
• 事务边界最小化：跨分片事务要尽量收敛为单分片本地事务，无法收敛时优先最终一致方案
• 扩容双路线：倍增翻倍（数据搬移少）与一致性 hash（搬移量降至 25%）按场景选择，配合双写与数据校验保障安全

某 SaaS 平台 CRM 模块客户跟进记录表（t_customer_follow），数据量 8000 万行，日均增长 30 万。线上告警：客户跟进列表查询 P99 从 150ms 飙升至 8.2s，P999 超过 30s，DB CPU 持续 95%+。该查询为多条件组合查询（按客户名、跟进状态、跟进时间范围、负责员工筛选），并按创建时间倒序分页。QPS 约 2000，大促期间可达 5000。MySQL 8.0.28，InnoDB 引擎，Buffer Pool 64GB。

1. 多条件组合查询索引难覆盖：查询条件组合多达 5 种字段 × 3 种操作符，无法为每种组合建索引，当前仅有主键和单列索引，EXPLAIN 显示 type=ALL 全表扫描。2. 深分页性能恶化：LIMIT 100000, 20 时回表代价巨大，Using filesort + Using temporary 同时出现。3. 模糊查询无法走索引：客户名 LIKE '%关键词%' 前导通配符导致索引失效。4. 优化不能影响线上业务：8000 万数据的大表 DDL 操作（加索引）可能导致锁表，必须在线无锁完成。

遵循"定位 → 分析 → 优化 → 验证"四步法。定位：通过慢查询日志（long_query_time=1s）和 APM（SkyWalking）抓取 Top10 慢 SQL。分析：使用 EXPLAIN FORMAT=JSON 解析执行计划，关注 type（ALL/index/range/ref）、key（实际使用索引）、rows（扫描行数）、Extra（Using filesort/Using temporary/Using index）。优化优先级：SQL 重写 → 索引优化 → 表结构优化 → 架构优化。验证：优化后在测试环境使用 EXPLAIN 验证执行计划，生产环境使用 pt-query-digest 对比优化前后性能。

接入层：应用侧引入 SQL 审计拦截器，对慢 SQL 自动记录并上报，对 LIMIT 深度超过 1000 的查询强制拦截并提示使用游标分页。前端分页改为"上一页/下一页"游标模式，基于 WHERE create_time < lastCreateTime ORDER BY create_time DESC LIMIT 20 替代 OFFSET。

应用层：SQL 重写——将 SELECT * 改为精确列名；将 LIKE '%关键词%' 改为前缀匹配 LIKE '关键词%' 或引入 ES 全文检索；将 OR 条件改写为 UNION ALL；子查询改写为 JOIN。组合查询条件分析后，按过滤性从高到低建立联合索引 idx_status_create_time_staff（status, create_time, staff_id），覆盖 80% 的查询场景。

数据层：使用 pt-online-schema-change（Percona Toolkit）无锁添加联合索引，避免 DDL 锁表。对历史数据按时间做 RANGE 分区（PARTITION BY RANGE (TO_DAYS(create_time))，每月一个分区），查询带上时间范围条件触发分区裁剪。对 3 年前的冷数据迁移至归档表，主表数据量降至 2000 万。

• 1. 联合索引的字段顺序如何确定？为什么把 status 放在最前面？
  遵循"最左前缀 + 区分度从高到低 + 等值优先范围在后"原则。status 区分度虽然中等（5 个枚举值），但所有查询都带 status 等值条件，放在最左保证索引可用性。create_time 是范围查询必须放最后，否则后续字段无法走索引。
• 2. EXPLAIN 中的 key_len 如何用来判断索引使用情况？
  key_len 表示索引中使用的字节数，可用于判断联合索引使用了几个字段。例如 idx(status_int, create_time, staff_id) 中 status 为 int(4字节) + create_time 为 datetime(5字节) + staff_id 为 bigint(8字节)。key_len=4 表示仅用了 status，key_len=9 表示用了前两个字段。
• 3. pt-online-schema-change 和 gh-ost 无锁 DDL 的原理差异是什么？
  pt-osc 基于触发器（INSERT/UPDATE/DELETE 触发器同步增量），对原表有写放大影响，高并发下可能引发锁竞争。gh-ost 基于 binlog 解析回放，无触发器，通过控制 binlog 消费速率实现流量自适应，对主库侵入更小，但要求 binlog_format=ROW。
• 4. 什么情况下该用 ES 而不是继续优化 MySQL 索引？
  当查询条件组合超过 5 种以上变体、需要全文检索、需要多字段排序聚合、且 MySQL 联合索引无法覆盖大部分查询场景时，应引入 ES。通过 Canal 监听 binlog 异步同步到 ES，MySQL 作为存储权威源，ES 作为查询加速层，写入延迟控制在秒级。

• 索引滥用：为每种查询组合都建索引，导致索引数量达 10+ 个，写入性能严重下降（每个索引都需维护）。规避：定期用 sys.schema_unused_indexes 清理无用索引，单表索引控制在 5 个以内，优先用联合索引覆盖多场景。
• 隐式类型转换导致索引失效：字段为 varchar 但传入 int 参数，MySQL 隐式转换后索引失效变全表扫描。规避：MyBatis 中确保参数类型与字段类型一致，使用 #{param} 而非 ${param}。
• 深分页直接 OFFSET：LIMIT 1000000, 20 实际扫描 100 万行后丢弃，性能随页码线性恶化。规避：强制游标分页，或使用延迟关联子查询（SELECT id FROM ... LIMIT N,20 再 JOIN 取详情）。
• 大表直接 ALTER：8000 万数据表直接 ALTER TABLE ADD INDEX，可能导致数小时锁表。规避：必须使用 pt-osc 或 gh-ost 在线 DDL 工具，并设置负载阈值自动暂停。
• 忽略 EXPLAIN 的 rows 估算：仅看是否走了索引就认为优化完成，但 rows 仍显示百万级扫描。规避：必须确认 rows 接近实际返回行数，Extra 中不应出现 Using filesort / Using temporary。

某社交电商订单系统采用 MySQL 一主三从架构，读写分离后从库承载 80% 读流量。大促期间主从延迟从日常的 200ms 飙升至 3-15 秒，导致用户下单后立即刷新订单列表偶现"订单不存在"（写入主库后从库尚未同步）。日均订单 300 万，峰值写入 TPS 8000，读 QPS 30000。用户投诉率上升 200%，客服工单量翻倍。当前为异步复制（async replication），binlog_format=ROW，GTID 已开启。

1. 写后读一致性：用户写入后立即读取（下单→查看订单），从库延迟导致读取到旧数据。2. 大事务导致延迟堆积：批量导入、大促结算等大事务产生大量 binlog，从库单线程回放速度跟不上主库并行写入。3. 从库负载不均：3 个从库中 1 个承载统计报表查询导致 CPU 飙升，进一步加剧延迟。4. 半同步降级风险：半同步复制在从库超时后会降级为异步，高负载下降级频繁。

从"延迟根因 → 一致性保障 → 复制优化 → 架构兜底"四层分析。根因排查：通过 SHOW SLAVE STATUS 查看 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running，区分网络延迟（IO 线程）和回放延迟（SQL 线程）。一致性保障按场景分级：强一致场景走主库、弱一致场景走从库 + 缓存兜底。复制优化：MySQL 5.7+ 并行复制（基于组提交 group commit 的 logical clock），8.0 基于 WRITESET 的更细粒度并行。架构兜底：引入 Redis 缓存写入后的数据，设置短暂 TTL 作为延迟窗口的缓冲。

接入层：在应用层实现"写后读强制主库"策略——写操作完成后，将当前请求的 ThreadLocal 标记为"强制主库"，后续 N 秒内（默认 3 秒，覆盖平均延迟窗口）该用户的读请求路由到主库。使用 ShardingSphere 的读写分离 + HintManager 实现强制路由。同时引入从库健康检查，延迟超过阈值（如 5 秒）的从库自动从路由池中摘除。

应用层：引入 Redis 作为"延迟缓冲层"——写入主库后同步写入 Redis（TTL=10s），读请求优先查 Redis，未命中再查从库。配合本地缓存（Caffeine，TTL=2s）进一步降低从库压力。对订单列表场景，写入后立即将最新订单 ID 列表缓存到 Redis，确保用户刷新能看到最新数据。

数据层：升级为半同步复制（8.4 起 rpl_semi_sync_source_wait_for_replica_count=1；旧名 rpl_semi_sync_master_wait_slave_count 写法有误且在 MySQL 9.5 已随旧插件移除；超时 3 秒降级异步）。开启并行复制（8.0.26+ 统一 replica_* 新名）：replica_parallel_workers=16，replica_preserve_commit_order=ON；binlog_transaction_dependency_tracking=WRITESET 仅 8.0 可设（8.4 起该变量已移除，依赖跟踪内建）；slave_parallel_type 自 MySQL 9.5 起已移除，无需再配。拆分大事务为小批次（每 500 行提交一次），避免单事务 binlog 过大导致回放阻塞。统计报表查询迁移到独立分析型从库（或 TiDB），隔离影响。

• 1. 半同步复制降级为异步后如何感知和告警？
  监控 Rpl_semi_sync_master_status 状态变量，从 ON 变为 OFF 即触发降级告警。同时监控 Rpl_semi_sync_master_no_tx（未走半同步的事务数），突增说明降级频繁。结合 Prometheus + Grafana 告警，降级持续超过 1 分钟触发电话告警。
• 2. MySQL 并行复制中 LOGICAL_CLOCK 和 WRITESET 模式有什么区别？
  LOGICAL_CLOCK（5.7+）基于组提交粒度并行，同一组提交的事务可并行回放，并行度受组提交大小影响。WRITESET（8.0）基于行级冲突检测，修改不同行的事务均可并行，粒度更细，并行度更高，但需要 binlog_transaction_dependency_history_size 控制依赖追踪窗口。
• 3. 强制主库方案在高并发下如何避免主库被打垮？
  控制强制主库的时间窗口（3 秒而非更长），仅对写后立即读的场景生效。引入主库连接池限流（HikariCP maximumPoolSize），超限降级为从库 + 重试。对非关键读（如统计报表）不做强制主库，仅列表/详情等用户敏感读走主库。
• 4. 如果从库延迟持续无法消除，架构层面该如何演进？
  短期：增加从库数量分散读压力，报表查询迁移到独立分析库。中期：引入 TiDB 等 NewSQL（原生强一致读），或用 Canal + ES 构建 CQRS 读模型。长期：核心链路读写分离改为"写主库 + 读 ES/Redis"，彻底解耦读写。评估维度：一致性要求、成本、运维复杂度。

• 全量读走主库：为解决延迟将所有读请求切到主库，主库 CPU 打满导致写入也受影响。规避：仅写后短窗口内强制主库，其余走从库 + 缓存。
• 半同步超时设置过长：rpl_semi_sync_source_timeout（旧名 rpl_semi_sync_master_timeout）设置为 10 秒甚至更长，从库不可用时写入阻塞 10 秒。规避：超时设为 1-3 秒，降级后走异步保证可用性，同时告警人工介入修复从库。
• 并行复制 workers 设置过高：replica_parallel_workers（旧名 slave_parallel_workers）设为 32 甚至 64，CPU 上下文切换开销反而降低回放速度。规避：workers 数量建议为 CPU 核数的 1/2 到 1 倍，配合 benchmark 调优。
• 忽略大事务对复制的影响：批量导入 10 万行单事务，从库回放时单线程阻塞数分钟。规避：大事务拆分为每 500-1000 行提交一次，或使用 LOAD DATA 分批导入。
• 从库无负载隔离：报表统计查询和业务读共用从库，大查询阻塞回放线程。规避：从库分角色——业务读从库 + 报表分析从库（独立实例），统计类重查询走分析库。

某电商商品详情页系统，Redis 集群（6 主 6 从）缓存商品信息，QPS 峰值 5 万，缓存命中率日常 95%。线上连续发生三次故障：① 恶意爬虫大量请求不存在的商品 ID（ID=-1、随机 UUID），缓存和 DB 均未命中，DB 连接池打满服务不可用 15 分钟（缓存穿透）；② 热销爆款商品缓存过期瞬间，2 万并发请求同时打到 DB，DB CPU 飙至 100%（缓存击穿）；③ 凌晨缓存批量过期 + DB 重启恢复，大量请求涌入导致雪崩式故障 30 分钟（缓存雪崩）。

1. 穿透识别：区分正常请求和恶意/异常请求，不存在的数据不应穿透到 DB。2. 热点 key 保护：单个热点 key 过期瞬间，如何避免大量并发同时回源。3. 批量过期防控：大量 key 同时过期（如批量预热后设置相同 TTL），如何在过期时间维度打散。4. 兜底降级：极端情况下 DB 不可用时，如何保证服务可用性（返回降级数据而非完全不可用）。

三大问题本质都是"缓存未命中 → 请求穿透到 DB → DB 过载"。区分维度：穿透是查询不存在的数据（key 永远不会命中）；击穿是热点 key 过期瞬间高并发回源（单个 key）；雪崩是大量 key 同时过期（批量 key）。对应解法：穿透 → 布隆过滤器 + 空值缓存；击穿 → 互斥锁（分布式锁）+ 逻辑过期 + 热点预热；雪崩 → TTL 随机化 + 多级缓存 + 熔断降级。核心原则：减少回源并发、缩短回源时间、DB 不可用时兜底。

接入层：在应用入口引入请求合法性校验——商品 ID 格式校验（正整数、长度范围），非法 ID 直接拒绝。接入布隆过滤器（Redisson RBloomFilter，预计元素 1 亿，误判率 0.01%），所有请求先查布隆过滤器，不存在则直接返回空，不查缓存和 DB。布隆过滤器通过 Canal 监听 DB 变更异步更新。

应用层：缓存击穿采用双重保障——① 互斥锁：缓存未命中时用 Redis SETNX 获取分布式锁（TTL=10s），仅持锁线程回源 DB 重建缓存，其余线程等待 50ms 后重试缓存；② 逻辑过期：热点 key 不设置物理 TTL，value 中嵌入 expireAt 字段，过期后异步线程重建，期间返回旧数据（牺牲近似一致换可用）。缓存雪崩——TTL 加随机偏移（base TTL + random(0, 300s)），避免批量同时过期。

数据层：多级缓存架构——L1 本地缓存（Caffeine，TTL=60s，maxSize=10000）→ L2 Redis 集群（TTL=30min+随机）→ L3 DB。DB 层配置 HikariCP 连接池（maximumPoolSize=50）+ Sentinel 熔断（慢调用比例阈值 0.5，RT 500ms），DB 过载时熔断返回降级数据。空值缓存：DB 查询为空时缓存空标记（key:null，TTL=60s），防止同一不存在 key 反复穿透。

• 1. 布隆过滤器误判导致正常请求被拦截怎么办？
  布隆过滤器只存在假阳性（误判存在）不存在假阴性（误判不存在），即"说存在可能不存在，说不存在一定不存在"。误判率设为 0.01% 时，1 亿元素中约 1 万个误判，被拦截的都是不存在的 ID，不会漏掉真实商品。可通过增大哈希函数数量和位数组降低误判率。
• 2. 逻辑过期方案中，如何处理异步重建失败的情况？
  异步重建通过 MQ 发送到消费端，失败后进入重试队列（最多 3 次，指数退避）。超过重试次数写入死信队列告警。同时设置兜底定时任务，扫描逻辑过期超过 10 分钟的 key 强制同步重建。极端情况下旧数据可继续服务，保证可用性优先于一致性。
• 3. 多级缓存中本地缓存（Caffeine）的数据一致性如何保证？
  本地缓存适合读多写少的场景，一致性要求不高时设置短 TTL（60s）容忍短暂不一致。强一致场景通过 Redis Pub/Sub 广播失效消息，各实例收到后主动清除本地缓存。或采用 Redisson 的 Cache 接口（底层 RTopic 广播），实现集群级缓存失效同步。
• 4. 热点 key 如何提前发现并预热？
  通过 Redis 的 hotkeys 命令（LFU 模式）或 Sentinel/实时计算（Flink）统计访问频次 TopN。大促前对预测热点（运营标记、历史爆款）批量预热到缓存并设置长 TTL + 逻辑过期。运行时动态发现热点（QPS > 5000）自动升级为逻辑过期模式，防止过期击穿。

• 互斥锁无超时保护：持锁线程 DB 查询卡住（如慢查询），锁长时间不释放，所有等待线程超时后同时回源。规避：锁必须设自动释放 TTL（10s），DB 查询设 statement timeout（3s），持锁线程异常时锁自动过期。
• 空值缓存 TTL 过长：空值缓存设 30 分钟，期间该商品上架后仍返回空。规避：空值 TTL 设短（60s），或商品上架时主动删除空值缓存 key。
• 缓存预热批量设置相同 TTL：批量预热 10 万 key 全部 TTL=1800s，30 分钟后同时过期引发雪崩。规避：TTL = base + random(0, maxRandom)，打散过期时间。
• 布隆过滤器更新延迟：新增商品后 DB 已写入但布隆过滤器未更新，导致新商品查不到。规避：布隆过滤器更新必须与 DB 写入在同一事务后异步触发（MQ），并设短延迟（1-2s）兜底重查。
• 仅依赖缓存无降级：Redis 集群整体故障时应用完全不可用。规避：必须配置熔断降级（Sentinel/Resilience4j，Hystrix 已停止维护仅作演进对比），Redis 不可用时降级返回本地缓存或默认数据，而非全部穿透到 DB。

某内容平台日均产生 1 亿张小图片（平均 50KB）和 10 亿条日志文件，使用 HDFS 存储导致 NameNode 内存压力巨大（单文件 150 字节元数据 × 110 亿 = 1.6TB 元数据），且读取延迟高。要求迁移至对象存储架构，支持高并发上传下载、生命周期管理、跨区域复制、CDN 加速。

① NameNode 瓶颈：HDFS 不适合小文件，元数据内存占用与文件数成正比；② 存储成本：图片冷热差异大，需分层存储；③ 上传性能：高并发上传时带宽和连接数限制；④ 一致性：上传后立即可见 vs 最终一致性的选择；⑤ 安全：预签名 URL 过期策略、防盗链、图片鉴黄。

采用"对象存储 + 小文件合并 + CDN 加速 + 生命周期管理"四层架构：对象存储层使用阿里云 OSS/AWS S3 替代 HDFS，利用其水平扩展能力；合并层将日志小文件按 128MB 合并为 Parquet 后入湖；加速层热图片走 CDN，冷图片走 OSS 低频访问；治理层配置自动生命周期（30 天转低频，1 年归档）。

1. 对象存储选型：使用 OSS Standard 存储热图片（访问延迟 10-100ms），Infrequent Access 存储 30-90 天数据，Archive 存储历史备份；通过生命周期规则自动转换，降低 60% 存储成本。

2. 小文件合并：日志类小文件通过 Spark Streaming 每小时合并为 Parquet（128MB/文件）后存入 OSS；图片类小文件若需保留原始格式，使用 Tar/Gzip 打包（每包 1000 张）后上传，读取时通过 Range 请求解压单张。

3. CDN 加速：图片域名 CNAME 到 CDN，配置 7 天缓存；上传新图片时通过 CDN 刷新接口预热；防盗链配置 Referer 白名单 + URL 鉴权（A/B 两种模式）。

4. 预签名 URL：私有 Bucket 通过服务端生成带过期时间的预签名 URL（OSS 支持 3600s 有效期），客户端直接访问 OSS 不经过服务端，降低带宽成本。

• 追问1：对象存储的 ListObjects 接口在文件数过多时性能差，如何优化？
  避免频繁 ListObjects，通过数据库（如 MySQL/Etcd）维护文件元数据索引；或使用 OSS 的清单（Inventory）功能定期导出全量文件列表。
• 追问2：CDN 缓存刷新有延迟，图片更新后用户仍看到旧图怎么办？
  更新图片时同步修改文件名（如加版本号 v2），避免覆盖同名文件；CDN 配置较长的缓存时间，通过 URL 版本控制强制回源。
• 追问3：跨区域复制（CRR）的 RPO 能做到多少？
  OSS 跨区域复制为异步复制，RPO 通常为秒级到分钟级。对于强一致性要求的场景，需在应用层双写或采用同步复制策略。

• 直接用 HDFS 存储海量小文件：HDFS NameNode 内存与文件数成正比，百亿级小文件会导致 NameNode OOM。必须迁移到对象存储或进行小文件合并。
• 未配置生命周期规则：数据只增不减会导致存储成本指数级上升。必须配置分层生命周期，冷数据自动转低频/归档。
• 公网直接访问 OSS Bucket：公网传输费用高且不安全。应通过 CDN 或内网 VPC Endpoint 访问，私有文件使用预签名 URL。

某中型电商公司核心交易系统为 Java 单体应用（SpringBoot 2.1.3），代码量 42 万行，430 个 Controller，部署包 220MB。团队从 8 人扩张至 35 人后出现严重协作问题：代码合并冲突频发（日均 15+ 次），发布周期从周级拉长至月级（任何模块改动需全量回归测试），单次部署影响全站（支付 bug 导致商品搜索不可用）。线上故障频发（月均 4 次 P2 级故障），系统耦合严重：订单直接调用商品库表、支付模块依赖库存 Java 对象。日均订单 200 万，大促峰值 TPS 5000。

1. 领域边界划分：单体中模块边界模糊（订单直接查商品表、支付调库存 DAO），如何基于 DDD 正确划分限界上下文。2. 数据拆分：单体共享一个 MySQL 库（120+ 张表），拆分后跨服务的数据归属和迁移方案。3. 渐进式拆分：不能一次性重构（风险过高），如何绞杀者模式逐步拆分并灰度验证。4. 分布式事务：拆分后下单流程跨订单/库存/支付三服务，如何保证数据一致性。5. 团队组织对齐：康威定律——架构拆分需同步调整团队组织结构。

采用"领域建模 → 边界识别 → 依赖梳理 → 渐进拆分 → 数据解耦 → 治理保障"六步框架。领域建模：通过事件风暴（Event Storming）梳理业务流程，识别核心域（交易）、支撑域（商品、库存）、通用域（用户、支付）。边界识别：按限界上下文划分服务边界，遵循"高内聚低耦合"原则，同上下文的聚合归为一个服务。依赖梳理：分析现有代码调用关系（通过静态分析工具如 Structure101），识别数据库层面的隐式耦合。渐进拆分：采用绞杀者模式（Strangler Fig），优先拆分边界清晰、变更频繁的模块，通过 API 网关做新旧路由切换。

接入层：引入 Spring Cloud Gateway 作为统一 API 网关，初期网关后同时挂载单体应用和新拆微服务，通过路由规则灰度切换流量。对外 API 保持不变（网关屏蔽内部拆分细节），内部调用逐步从本地方法调用迁移为 Feign/RPC 远程调用。

应用层：分三阶段渐进拆分——第一阶段拆分商品服务（变更频率高、边界相对清晰），通过数据库视图 + API 代理实现单体与微服务双写过渡；第二阶段拆分库存服务和用户服务；第三阶段拆分支付服务（一致性要求最高，最后拆）。每个服务采用 DDD 分层架构（接口层/应用层/领域层/基础设施层），服务间通过 OpenFeign 声明式调用，配合 Sentinel 做熔断降级。

数据层：数据库拆分采用"先共享后独立"策略——初期微服务与单体共享数据库（通过不同的 schema 或表前缀隔离），验证服务边界正确后再物理拆库。数据迁移通过 Canal 监听 binlog 双写到新库，校验一致后切读。分布式事务采用 Seata AT 模式（核心交易链路）+ 本地消息表（异步通知场景）。最终拆分为：订单服务（核心库）、商品服务（商品库）、库存服务（库存库）、用户服务（用户库）、支付服务（支付库）。

• 1. DDD 中限界上下文如何具体识别？有哪些实践方法？
  通过事件风暴（Event Storming）工作坊，邀请产品/研发/测试共同梳理业务流程。识别领域事件（已发生的事实如"订单已创建"），按事件聚类找到聚合根和限界上下文边界。判断标准：同一上下文内的概念语义一致（无歧义）、变更节奏一致、可独立部署。例如"商品"在商品上下文中是展示信息，在库存上下文中是库存单位，概念不同应拆分。
• 2. 数据库共享期间，如何防止微服务直接查单体的表（绕过服务边界）？
  从代码规范和技术约束双管齐下：代码层面 MyBatis Mapper 只允许操作本服务的表前缀；数据库层面为每个微服务创建独立 DB 账号，仅授权对应 schema 的表权限（GRANT SELECT/INSERT ON product_db.* TO product_user）。通过 CI 流水线静态检查 SQL 中的表名是否越界。
• 3. Seata AT 模式的全局锁会不会成为性能瓶颈？如何优化？
  AT 模式在二阶段提交前持有全局锁（行级），高并发热点行（如秒杀库存）会产生锁竞争。优化：热点场景改用 Seata TCC 模式（Try-Confirm-Cancel 无全局锁）；或 AT + Redis 预扣减（Redis 原子扣减 + 异步同步 DB）；降低全局事务粒度，非核心操作移出全局事务用最终一致。
• 4. 拆分后服务间调用链路变长，如何保证整体可用性？
  每个远程调用必须配置超时（Feign connectTimeout=1s, readTimeout=3s）、熔断（Sentinel 慢调用比例熔断）、降级（Fallback 返回默认值或缓存数据）。引入链路追踪（SkyWalking）可视化调用链，设定 SLA（如 P99 < 500ms）。核心链路做异步化改造（MQ 解耦），将同步调用降至最小。
• 5. 如何评估微服务拆分的粒度是否合理？拆得太细有什么问题？
  评估维度：独立部署能力、团队自治（两个披萨团队）、故障隔离边界。拆得过细会导致：服务间网络调用开销占比过高、分布式事务复杂度爆炸、运维成本（监控/部署/排障）线性增长。建议从粗粒度开始（按领域拆 5-8 个服务），随团队规模和业务复杂度演进式细化。
• DDD 如何真正落地到拆分：限界上下文、聚合根、上下文映射分别起什么作用？
  三者是递进的拆分指引，比单纯"按业务拆"更可执行。① 限界上下文（Bounded Context）= 服务候选边界：语义一致、变更节奏一致、可独立部署的概念聚为一个上下文，对应一个微服务；跨上下文的概念若语义不同（如"商品"在商品域是展示信息、在库存域是库存单位）必须拆开，不能共享同一个模型。② 聚合根（Aggregate Root）= 事务与数据边界：把"必须在同一事务内保持一致"的对象划为一个聚合，仅暴露根实体，外部只能引用根 ID 而非聚合内部对象；一个聚合 = 一个事务 = 一组强一致表，这直接决定库表归属，避免跨服务事务。例如 Order 与 OrderItem 是一个聚合（Order 为根），Order 不直接持有另一个聚合的内部引用。③ 上下文映射（Context Mapping）= 服务间契约与集成方式：用模式描述上下文关系——Customer-Supplier（上下游约定）、Anticorruption Layer/ACL（防腐层，新旧系统/单体对接时翻译模型，防止老模型污染新服务）、Open Host Service/OHS + Published Language（对外发布稳定 API 与通用语言）、Separate Ways（两域无强关联就各自为政）。落地套路：事件风暴产出限界上下文 → 定义每个上下文内的聚合与根 → 用上下文映射确定服务间是 ACL 还是 OHS 集成，据此生成服务边界、库表归属与接口契约，避免"贫血模型 + 聚合泄漏到服务外"的典型反模式。

• 按技术层拆分而非业务领域：拆成"DAO 服务""Service 服务""Controller 服务"，导致每次业务变更需跨 3 个服务修改。规避：必须按业务领域（限界上下文）拆分，技术分层在服务内部。
• 数据库共享但未做访问隔离：微服务直接 JOIN 查询其他服务的表，数据耦合未真正解耦。规避：DB 账号权限隔离 + 代码静态检查，禁止跨服务表访问。
• 同步调用链路过长：下单流程串联调用 6+ 个微服务，任一服务故障导致整链失败。规避：核心链路同步调用不超过 3 跳，非核心操作用 MQ 异步化。
• 拆分后无灰度直接全量切换：新微服务未经线上验证直接承接全量流量，bug 导致全站故障。规避：绞杀者模式 + 网关灰度路由（1% → 10% → 50% → 100%），每阶段观察 24-48 小时。
• 忽视康威定律：架构拆成微服务但团队仍按职能（前端/后端/DBA）组织，跨团队协作成本不降反升。规避：按服务组建自治小团队（含前端+后端+测试），对服务全生命周期负责。

某互联网公司微服务体系包含 18 个微服务，客户端（APP/H5/小程序）共 50+ 个 API 入口。当前问题严重：① 鉴权逻辑散落在各服务中（有的用 JWT、有的用 Session、有的未鉴权），安全漏洞频发；② 无统一限流，大促期间单服务过载引发雪崩；③ 客户端需多次调用不同服务聚合数据（首页需 6 次 API 调用），延迟高（P99=1.2s）；④ 灰度发布靠手工 Nginx 配置，效率低且易出错；⑤ 外部合作伙伴接入需协议转换（HTTP → Dubbo/gRPC）。日均 API 调用量 2 亿次，峰值 QPS 8 万。

1. 统一鉴权：多种认证方式（JWT/OAuth2/API Key）统一收敛到网关，后端服务无需重复实现。2. 精细化限流：需支持多维度限流（全局/API 级别/用户级别/IP 级别），且限流规则可动态调整不停机。3. 请求路由与灰度：支持按 Header/参数/权重路由到不同版本，实现灰度发布和 A/B 测试。4. 协议转换：外部 HTTP 请求需转换为内部 Dubbo/gRPC 调用，屏蔽内部通信协议。5. 网关自身高可用：网关作为唯一入口是单点风险，必须支持水平扩展和无状态部署。

网关设计遵循"接入层 → 过滤链 → 路由层 → 协议转换层"分层架构。选型对比：Spring Cloud Gateway（基于 WebFlux + Reactor，异步非阻塞，适合 Java 技术栈）/ Kong（基于 OpenResty + Lua，性能极高但二次开发成本高）/ APISIX（基于 Nginx + etcd，动态配置热更新）。本场景选 Spring Cloud Gateway（与现有 Spring Cloud 技术栈统一），配合 Nacos 做服务发现和动态路由配置。过滤链采用责任链模式，按执行顺序分为 pre（鉴权/限流/日志）→ route（路由转发）→ post（响应处理/统计）。限流采用 Sentinel 网关流控规则，支持 QPS 和并发线程数双维度。

接入层：Spring Cloud Gateway 部署 4 节点（可水平扩展），前置 Nginx/LVS 做 LB + SSL 卸载。网关无状态设计，Session/JWT 信息存储在 Redis，任意节点均可处理任意请求。客户端请求统一经网关入口 /api/{service}/{path} 路由到后端微服务。

过滤链层：自定义 GlobalFilter 链，执行顺序：① TraceFilter（生成 TraceID 注入 Header，接入 SkyWalking）→ ② AuthFilter（统一鉴权：JWT 解析/OAuth2 Token 校验/API Key 验证，校验失败直接返回 401）→ ③ RateLimitFilter（Sentinel 限流：全局 8 万 QPS + 单 API 1 万 QPS + 单用户 100 QPS）→ ④ GrayFilter（灰度路由：按 Header X-Gray-Tag 或用户 ID Hash 决定路由版本）→ ⑤ LogFilter（记录访问日志 + 响应耗时，异步写入 Kafka 供 ELK 分析）。

路由与协议转换层：动态路由规则存储在 Nacos Config，修改后秒级生效无需重启。HTTP → Dubbo 协议转换通过自定义 GatewayFilter 实现（解析 HTTP 参数 → 构造 Dubbo RpcInvocation → 泛化调用 Dubbo 服务 → 转换返回结果为 JSON）。响应聚合通过网关的聚合接口（如 /api/home/aggregate）并行调用商品/推荐/广告/用户服务，使用 Mono.zip 合并响应，减少客户端 RTT。

• 1. 网关作为单点入口，自身高可用如何保障？
  多副本部署（至少 3 节点跨机房），前置 LVS/Nginx 做 LB + 健康检查，异常节点自动摘除。网关无状态设计（Session/JWT 信息存 Redis），支持随时水平扩容。配置 Nacos 做服务发现和配置中心，网关实例自动注册和感知。配合 K8s HPA 基于 CPU/QPS 自动伸缩。
• 2. 限流规则如何做到动态生效且不影响在途请求？
  使用 Sentinel 的 Nacos 数据源，限流规则存储在 Nacos Config，修改后 Sentinel 监听变更推送到各网关节点，秒级生效。新规则仅对后续请求生效，在途请求不受影响。规则变更通过 Dashboard 操作，记录审计日志，支持规则版本回滚。
• 3. HTTP → Dubbo 协议转换的性能损耗如何控制？
  使用 Dubbo 泛化调用（GenericService），避免网关引入服务接口 JAR 依赖。性能优化：开启 Dubbo 异步调用（CompletableFuture）、连接池复用（Dubbo 线程池 fixed 模式）、序列化优化（Hessian2 → Kryo/Protostuff）。监控协议转换耗时占比，超过 5ms 告警排查。
• 4. 网关层做响应聚合（BFF 模式）与客户端自行聚合各有什么优劣？
  网关聚合（BFF）优势：减少客户端网络 RTT（6 次→1 次）、后端服务无需暴露公网、聚合逻辑统一维护。劣势：网关逻辑变重、聚合接口与后端服务耦合。适用于客户端类型固定且聚合逻辑稳定的场景；若客户端聚合需求多变（如不同端不同聚合策略），建议按端拆分 BFF 层。

• 网关承载过多业务逻辑：在网关中写数据聚合、格式转换等重逻辑，网关从"路由网关"退化为"微型 BFF"，性能和维护性下降。规避：网关仅做鉴权/限流/路由/协议转换，业务聚合下沉到 BFF 服务或后端服务。
• 鉴权 Filter 中同步阻塞操作：在 WebFlux 异步模型中调用同步阻塞操作（如同步查 Redis/DB），阻塞 Reactor 线程导致吞吐量骤降。规避：使用 ReactiveRedisTemplate 或 Mono.fromCallable + subscribeOn(boundedElastic) 包装同步调用。
• 限流规则硬编码：限流阈值写死在代码中，大促前需改代码重新发布。规避：限流规则必须外置到配置中心（Nacos/Apollo），支持动态推送和热更新。
• 未做网关级超时控制：后端服务响应慢导致网关连接被占满，新请求无法接入。规避：网关必须配置全局超时（responseTimeout=5s）和单服务超时，超时后主动断开连接返回 504。
• 灰度路由未覆盖全链路：网关灰度路由到 v2，但后续 RPC 调用仍走 v1，灰度验证失效。规避：灰度标记必须通过 Header/RPC Attachment 全链路透传，配合全链路灰度方案（见 S18）。

某外卖平台订单消息处理系统，使用 Kafka 集群（3 Broker，topic=order-events，6 分区，副本因子 2）。消费者服务（4 实例）正常消费速度 2000 条/秒。大促期间订单消息生产速度飙升至 5000 条/秒，持续 2 小时后积压 2000 万条消息，消费延迟从毫级升至 2.5 小时。影响：骑手超时提醒延迟（用户已收到餐但 APP 仍显示"准备中"）、订单状态同步延迟导致客服无法及时处理退款。Kafka Lag 监控告警频繁，消费者服务 CPU 70%、JVM GC 频繁（Full GC 每 5 分钟一次）。

1. 消费速度无法跟上生产速度：4 实例 × 6 分区，单实例消费 1-2 分区，增加消费者实例受限于分区数（同一 group 内消费者数不能超过分区数）。2. 单条消息处理耗时长：每条消息涉及 DB 写入 + Redis 更新 + 下游 RPC 调用，平均 50ms/条，理论上限 20 条/秒/线程。3. 积压期间业务影响：延迟消息（骑手提醒、超时取消）积压后失去时效性。4. 消费者 GC 压力：大批量消息加载导致堆内存压力，Full GC 进一步拖慢消费速度形成恶性循环。

从"扩容消费能力 → 优化单条处理 → 积压应急处理 → 长期容量治理"四层应对。扩容维度：Kafka 分区数限制 → 消费者实例数上限 → 单实例线程数。单条优化：批量化（批量 DB 写入、批量 Redis Pipeline）、异步化（非核心操作异步化/延迟处理）。应急处理：跳过过期消息（时效性消息直接丢弃）、临时扩分区 + 消费者。容量治理：基于历史峰值做容量规划，建立 Lag 告警 + 自动扩容机制。核心公式：消费能力 = 消费者实例数 × 单实例线程数 × (1000 / 单条处理耗时ms)。

接入层：紧急扩容——将 order-events topic 分区数从 6 扩展到 24（Kafka 支持在线扩分区，但新分区仅接收新消息），同时将消费者实例从 4 扩到 12（每实例 2 分区），消费并行度提升 3 倍至 6000 条/秒，超过生产速度开始消化积压。若无法扩分区，采用"临时 Topic 转发"方案——原消费者快速拉取消息后转发到 24 分区的新 Topic，新消费者集群并行消费新 Topic。

应用层：批量化处理——消费者每次 poll 拉取 500 条消息（max.poll.records=500），批量写入 DB（MyBatis batch executor，每 500 条一次 commit）、批量更新 Redis（Pipeline 模式），单批处理耗时从 500×50ms=25s 降至 500ms（批量 DB 200ms + Redis Pipeline 100ms + RPC 并行 200ms）。非核心操作（通知推送、统计上报）异步化——发送到下游 Topic 或线程池异步处理，不阻塞主消费流程。JVM 调优：堆内存从 4G 升至 8G，G1GC（-XX:MaxGCPauseMillis=100），减少 Full GC。

数据层：过期消息跳过——对时效性消息（如骑手超时提醒），消费者拉取后判断消息年龄（当前时间 - 消息时间戳），超过 30 分钟的直接丢弃并发送告警，避免无效处理占用消费能力。积压监控：Kafka Lag Exporter 采集各分区 Lag 上报 Prometheus，Grafana 看板展示，Lag 超过 10 万触发告警，超过 100 万触发自动扩容（K8s HPA 或手动扩消费者实例）。

• 1. 扩分区后，已有消息的分区分布不变，新分区只接收新消息，积压如何消化？
  扩分区主要解决"新消息"的消费并行度。已有 6 分区的积压仍由原消费者消化，可通过临时增加原分区消费者线程数（单实例多线程消费同一分区）加速消化，或用"临时 Topic 转发"将原分区消息快速搬运到新 24 分区 Topic 并行消费。两种方案可组合使用。
• 2. 批量消费中部分消息处理失败（如 DB 唯一键冲突），如何处理不影响整批？
  采用"批内分批 + 局部重试"策略：500 条按 50 条子批次提交，子批次失败则对该 50 条逐条重试（定位具体失败消息）。仍失败的消息写入死信 Topic（DLT），主流程继续提交后续批次。死信消息由独立消费者做补偿处理（人工介入或自动修复后重放）。
• 3. 消费者 rebalance 期间消息堆积如何减少影响？
  rebalance 期间消费者无法消费，持续时间越长积压越多。优化：减少消费者上下线频率（优雅停机先通知 rebalance 再退出）；使用 Kafka 2.4+ 的 Sticky Assignor（粘性分配器）减少 rebalance 时的分区迁移；消费者使用 CooperativeStickyAssignor（增量 rebalance，仅变更涉及分区而非全量重分配）。
• 4. 如何建立常态化的积压预警和自动扩容机制？
  部署 Kafka Lag Exporter 采集 Lag 指标到 Prometheus，配置分级告警（Lag > 10万 P3 告警，> 50万 P2 告警，> 100万 P1 电话）。自动扩容：K8s 环境下配置 HPA 基于 Lag 自定义指标自动扩缩消费者 Pod（需部署 Kafka Prometheus Adapter 将 Lag 暴露为 K8s 自定义指标）。

• 消费者数超过分区数：部署 8 个消费者实例但 Topic 只有 6 分区，2 个消费者空闲浪费资源。规避：消费者实例数 ≤ 分区数，或通过临时 Topic 转发增加逻辑并行度。
• 自动提交 offset 在处理失败前提交：enable.auto.commit=true 处理未完成就提交了 offset，消息丢失。规避：关闭自动提交（enable.auto.commit=false），处理完成后手动 ack.acknowledge()。
• 单条消息同步调用下游 RPC：每条消息同步调通知服务（50ms），消费速度被 RPC 耗时限制。规避：非核心 RPC 异步化（发送到下游 Topic），或批量 RPC（一次通知多条消息）。
• 积压时盲目增加消费者线程：单分区多线程消费导致 offset 管理混乱，消息乱序，重复消费。规避：同一分区的消息需保证顺序时不能多线程消费；必须多线程时按 orderId 路由到固定线程（分区内 hash 分槽）。
• 忽略 GC 对消费速度的影响：大批量消息对象加载导致频繁 GC，GC 暂停期间消费线程停顿。规避：控制 max.poll.records 避免单批拉取过多，JVM 堆内存充足（8G+），使用 G1GC 控制暂停时间。

某金融科技公司核心交易链路包含 5 个微服务：网关 → 交易服务 → 风控服务 → 账务服务 → 通知服务。交易服务进行大规模重构（从同步调用改为事件驱动架构），需灰度验证 2% 流量验证稳定性后再逐步放量。挑战：灰度流量必须全链路路由到灰度版本（交易服务 v2 调用风控服务 v2 调用账务服务 v2），不能出现 v2 调 v1 的版本混乱。同时需支持秒级回滚（灰度发现问题立即切回全量 v1）。系统日均交易 500 万笔，涉及资金安全，灰度期间不能影响正常交易。技术栈：Spring Cloud + Nacos + OpenFeign + RocketMQ。

1. 全链路灰度路由：灰度流量经过 5 个服务的 RPC 调用链，每跳都必须路由到灰度版本，不能中途断链。2. 灰度标记透传：灰度标签（gray-tag=v2）需在 HTTP Header、RPC Attachment、MQ 消息中全链路透传，不能丢失。3. 灰度流量隔离：灰度版本与正式版本的数据隔离（DB/Redis/ES），灰度产生的数据不能污染正式环境。4. 秒级回滚能力：灰度发现问题需在 30 秒内切回全量 v1，不能依赖服务重新部署。5. 灰度效果可观测：需对比 v1/v2 的关键指标（RT、错误率、业务指标），实时判断灰度是否达标。

采用"流量染色 → 标签路由 → 数据隔离 → 可观测 → 回滚机制"五层框架。流量染色：在网关层根据规则（用户 ID Hash、地域、Header 标记）为请求打上灰度标签 X-Gray-Tag=v2。标签路由：基于服务发现元数据（Nacos metadata）实现标签匹配——v1 实例注册 metadata version=v1，v2 实例注册 version=v2，Feign 负载均衡器根据请求中的灰度标签优先选择对应版本实例。数据隔离：灰度流量使用独立的数据空间（灰度 DB schema 或灰度 Redis key 前缀）。可观测：全链路追踪（SkyWalking）按灰度标签分组对比指标。回滚：网关路由规则秒级切换（Nacos 动态配置），灰度实例缩容。

接入层（网关）：Spring Cloud Gateway 中实现灰度路由 Filter——根据请求特征（用户 ID Hash % 100 < 2 → 2% 灰度，或 Header X-Gray-Tag 强制指定）为请求打上灰度标签。标签注入到 HTTP Header（X-Gray-Tag=v2）并透传到下游所有 RPC 调用。灰度规则存储在 Nacos Config，支持动态调整灰度比例（2% → 10% → 50% → 100%）无需重启网关。回滚时将灰度规则设为 0%，秒级生效。

应用层（RPC 链路）：基于 Nacos 服务发现元数据实现标签路由——v1 实例注册时 metadata.tag=v1，v2 实例注册时 metadata.tag=v2。自定义 Spring Cloud LoadBalancer 策略 GrayLoadBalancer：从请求上下文（RequestContextHolder）获取灰度标签，优先选择 tag 匹配的实例，无匹配时降级到 v1（兜底策略）。Feign 拦截器自动将灰度标签注入到 RPC Header（透传）。RocketMQ 消息中携带灰度标签（消息 Property），灰度消费者仅消费带 v2 标签的消息。

数据层：灰度数据隔离采用"影子库 + 影子表"方案——灰度流量操作的 DB 表加灰度前缀（t_order_gray），Redis key 加灰度前缀（gray:order:xxx）。通过 MyBatis 拦截器自动根据当前请求的灰度标签切换表名/前缀。灰度验证通过后，影子表数据清理。若灰度版本与正式版本数据结构兼容，也可采用"共享数据 + 版本字段"方案（数据行增加 version 字段区分来源），减少数据迁移成本。

• 1. 灰度标签在 MQ 异步链路中如何透传？RocketMQ 消息消费后标签丢失怎么办？
  生产者在发送 MQ 消息时将灰度标签写入消息 Property（message.putUserProperty("gray-tag", "v2")）。消费者消费时从消息 Property 读取标签并重新设置到当前线程上下文（GrayContextHolder.setTag）。若消费端是多线程处理，需在提交线程池时通过 ThreadLocal 或 Runnable 包装器传递标签，防止线程切换导致标签丢失。
• 2. 灰度版本与正式版本数据库结构不同（v2 新增了字段），如何处理数据兼容？
  采用"前向兼容"策略：v2 的新增字段必须可为空（NULL 或默认值），v1 读写时忽略该字段。若 v2 修改了字段语义或类型，必须走影子表方案（独立表隔离），不能共享正式表。灰度验证通过后，通过 DDL 在正式表上添加新字段，再做数据回填，最后下线影子表。
• 3. 回滚时灰度实例上正在处理的请求怎么办？如何保证回滚不丢数据？
  回滚采用"先切流量再缩实例"策略：网关灰度规则设为 0% 后，新请求不再路由到 v2，但 v2 实例上在途请求继续处理完毕（优雅停机，等待最多 30 秒）。涉及资金的请求采用幂等设计，回滚后重试可由 v1 继续处理。v2 实例处理完在途请求后自动下线，确保不丢数据。
• 4. 灰度可观测性如何建设？如何自动判断灰度是否达标？
  SkyWalking 全链路追踪按灰度标签分组，对比 v1/v2 的 RT、错误率、吞吐量。Prometheus 采集业务指标（交易成功率、资金差异率）。自动判断规则：v2 错误率 > v1 错误率 × 1.5 或 RT P99 > v1 × 1.3 时自动触发告警并建议回滚。资金类指标任何异常立即自动回滚，不需人工确认。
• 5. 如果灰度链路中某个服务没有 v2 版本（未参与本次灰度），如何处理？
  GrayLoadBalancer 的兜底策略处理此场景：请求灰度标签为 v2 但某服务无 v2 实例时，自动降级路由到 v1 实例，保证请求链路不断。需在监控看板标注"灰度断链点"，便于识别哪些服务尚未灰度。对于要求严格全链路灰度的场景，通过配置中心标记该服务为"灰度必选"，无 v2 实例时直接拒绝请求返回降级响应。

• 灰度标签仅网关层生效：网关路由到 v2，但 Feign 调用下游时灰度标签丢失，下游仍走 v1，灰度验证失效。规避：必须实现 Feign 拦截器 + RequestContextHolder 全链路透传，MQ 场景通过消息 Property 传递，异步线程通过 ThreadLocal 传递。
• 灰度数据污染正式环境：灰度流量写入正式 DB 表和 Redis key，回滚后灰度产生的脏数据残留。规避：灰度数据必须走影子表/影子 key（加 gray 前缀），MyBatis 拦截器自动切换，回滚后一键清理影子数据。
• 回滚依赖服务重新部署：发现问题后通过下线 v2 实例回滚，耗时数分钟。规避：回滚必须通过网关路由规则切换（Nacos 动态配置，秒级生效），v2 实例保留不缩容，确认稳定后再清理。
• 灰度比例一次性调太高：直接从 2% 跳到 50%，隐藏问题集中爆发影响大量用户。规避：遵循 2% → 10% → 30% → 50% → 100% 渐进式放量，每阶段观察 2-4 小时，指标达标才进下一阶段。
• 未做灰度效果对比监控：灰度期间仅看 v2 自身指标，未与 v1 对比，问题未及时发现。规避：必须建设 v1/v2 指标对比看板（RT、错误率、业务成功率），设置自动告警阈值，异常时自动触发回滚流程。

某金融微服务平台 200+ 服务，需实现 mTLS 双向认证、金丝雀发布、全链路灰度、熔断限流，但业务代码侵入严重（每个服务集成 SDK 版本不一）。计划引入 Istio + Envoy Sidecar 实现零侵入治理，同时关注 Sidecar 资源占用、调试复杂度、与 Spring Cloud 的共存迁移。

① Sidecar 资源开销：每个 Pod 增加一个 Envoy 容器，内存和 CPU 消耗；② 调试复杂度：问题排查需跨应用和 Sidecar，网络路径变长；③ 与 Spring Cloud 共存：存量服务使用 Eureka/Ribbon，如何渐进迁移到 Istio；④ 启动时序：Sidecar 未就绪时应用容器已启动，导致流量异常；⑤ mTLS 性能：TLS 握手和加密解密增加延迟。

采用"控制面 Istio + 数据面 Envoy + 渐进式迁移"的 Service Mesh 架构：通过 Pod 自动注入 Sidecar 实现流量代理；利用 VirtualService 和 DestinationRule 实现流量管理；与 Spring Cloud 共存期采用双注册（Eureka + Istio ServiceEntry）；通过 EnvoyFilter 扩展自定义鉴权逻辑。

1. Sidecar 注入与资源限制：Namespace 级别开启自动注入（istio-injection=enabled），Envoy 容器限制内存 128MB、CPU 0.5 核；使用 Distroless 镜像减小攻击面和启动时间。

2. 流量管理：VirtualService 定义路由规则（按 Header 灰度、权重分流、超时重试）；DestinationRule 定义负载均衡策略（LEAST_CONN 替代 ROUND_ROBIN）和连接池限制。

3. 与 Spring Cloud 共存：存量服务继续注册到 Eureka，Istio 通过 ServiceEntry 将 Eureka 服务导入网格；新服务直接走 Kubernetes Service + Istio，逐步淘汰 Eureka。

4. 启动时序保障：配置 Pod PostStart 钩子，确保 Envoy 就绪后才启动应用容器；或启用 Kubernetes StartupProbe，将 Sidecar 就绪作为应用启动条件。

5. mTLS 优化：开启 TLS 会话复用（session resumption），减少重复握手；使用 RSA 证书（兼容性好）或 ECDSA 证书（性能更优）；Sidecar 间启用 HTTP/2 多路复用降低连接数。

• 追问1：Sidecar 模式 vs Sidecar-less（eBPF）如何选型？
  Sidecar 模式成熟度高、生态好、语言无关，但资源开销大；eBPF（如 Cilium Service Mesh）在内核层处理流量，零 Sidecar 开销，但要求内核 5.10+，且 L7 能力仍在发展中。建议存量用 Sidecar，新建集群试点 eBPF。
• 追问2：Envoy Sidecar 内存占用过高如何排查？
  Envoy 默认会为每个上游集群缓存大量连接和路由配置。可通过限制集群数量、关闭未使用的统计指标、调整 max_request_headers_kb 等参数优化；必要时使用 Wasm 扩展替代部分 Lua 脚本。
• 追问3：Istio 控制面宕机后，数据面 Envoy 还能正常工作吗？
  可以。Envoy 的配置是最终一致的，控制面推送配置后保存在 Envoy 本地内存。控制面短暂宕机不影响现有流量，但新 Pod 无法注入 Sidecar，配置变更也无法下发。建议 Istiod 至少 3 副本高可用部署。

• Sidecar 资源限制过低导致 OOM：Envoy OOM 后该 Pod 所有流量中断。必须根据实际连接数和路由规则合理设置 memory limit，并配置 HPA 自动扩容。
• 未配置 Pod Disruption Budget 导致升级时全量中断：Istio 升级或节点维护时，若同时驱逐大量 Pod 会导致服务不可用。必须为关键服务配置 PDB（minAvailable=50%）。
• 忽略 Sidecar 日志与监控：Sidecar 增加了网络跳数，必须采集 Envoy 的 access_log、cluster_stats，建设 Sidecar 专属的延迟和错误率监控大盘。

某微服务将开关、阈值、线程池核心参数都放在 Nacos，并给承载这些参数的 Bean 打了 @RefreshScope，期望配置变更秒级生效。一次运营大促前改了线程池 corePoolSize 与限流开关，调用 /actuator/refresh 后，监控陆续出现三类异常：① 同一台机器出现两个消费者实例在重复消费消息；② 应用线程数只涨不跌，几小时后 OOM 重启；③ 一个定时对账任务每分钟执行了两次。告警风暴，但接口 RT 反而正常，初判"配置没生效"却找不到旧值来源。

1. 双实例根因定位：旧 Bean 为何没被回收；2. 资源泄漏链路：旧线程池/连接为何未关闭；3. 懒加载时序：为何刷新后旧任务仍跑、新值何时才被读到；4. 根治而非止血：如何在保留热更新能力的同时消除新旧 Bean 共存。

按"作用域 → 引用链 → 资源生命周期"三维定位：①@RefreshScope 是自定义 Scope，刷新仅标记过期、下次访问才重建 target（懒加载）；②旧 Bean 是否被单例强引用——被单例 Service 注入持有的旧代理/旧实例不会 GC，造成双实例；③重资源是否交给 RefreshScope——线程池/连接池被刷新即重建，旧资源无关闭钩子则泄漏；④定时任务/线程是否持有旧引用——第一次拿到旧实例后永远读旧值。根因几乎都落在"@RefreshScope 误用于业务/资源 Bean"。

方案 A（首选，纯配置 POJO）：配置类只用 @ConfigurationProperties，Nacos 下自动 rebind 刷新字段，删掉 @RefreshScope；业务代码 @Autowired 后方法内实时 get，不缓存快照。无新旧双实例，彻底消除三类事故。

方案 B（重资源热更新）：线程池/连接池不交 @RefreshScope，改为监听 EnvironmentChangeEvent，在回调里先 shutdown() 旧资源再按新参数建新资源（详见 C10.26 实践）。

方案 C（@Value 必须热更新时）：只用 @Value 注入的开关才加 @RefreshScope，且绝不加在 Service/定时任务类上。

// 根治：纯配置 POJO，Nacos 自动 rebind，无 @RefreshScope
@Component
@ConfigurationProperties(prefix = "app.rule")
public class AppRuleProperties {
    private int corePoolSize;
    private boolean switchOn;
    // getter/setter（rebind 通过 setter 改字段）
}

// 业务侧：实时读取，绝不缓存快照
public void doBiz() {
    int n = appRuleProperties.getCorePoolSize(); // 每次拿最新值
    boolean on = appRuleProperties.isSwitchOn();
}

// 反例（三类事故根因）：@RefreshScope 管理重资源 + 单例持有旧引用
@RefreshScope
@Component
public class BadPool {
    @Value("${app.rule.corePoolSize}") private int n;
    private final Executor executor = Executors.newFixedThreadPool(n); // 刷新不重建，旧池泄漏
}

• 追问 1：如何快速确认是双实例还是缓存快照？线程堆栈搜同名业务线程/线程池是否出现两份；看是否存在两个 AppRuleProperties 实例（@RefreshScope 下会有新旧两个 target）。单例持有旧引用→双实例；仅字段旧值→快照。
• 追问 2：为什么 Nacos 下 @ConfigurationProperties 不用 @RefreshScope 也能热更新？Nacos 发 EnvironmentChangeEvent，ConfigurationPropertiesRebinder 重新绑定同一单例 Bean 的字段（改字段非新建对象），所以无需 @RefreshScope；而 @Value 固化不刷，才需 @RefreshScope。
• 追问 3：Spring Cloud Config 下同样代码为何不生效？原生 Config 无 Nacos 增强，@ConfigurationProperties 不自动 rebind，必须保留 @RefreshScope 或手动监听 ContextRefreshedEvent 刷新。

• 把 @RefreshScope 当银弹加在 Service / 定时任务 / Feign / Mapper 上：代理链错乱、切面失效、双实例。
• @Bean 方法上加 @RefreshScope 管理 RestTemplate/线程池：每次刷新重建，连接泄漏、OOM。
• @PostConstruct 里把配置值赋给成员变量：永久快照，热更新永远失效。
• 认为 Nacos 下 @ConfigurationProperties 也必须加 @RefreshScope：引入新旧双实例风险，收益为 0。
• 静态变量接配置：@RefreshScope 对 static 完全无效，永远旧值。

口诀："配置用 POJO、资源手动听、字段实时取、@RefreshScope 只救 @Value。"先判根因（双实例来自单例强引用旧 target、OOM 来自重资源未关闭、重复执行来自旧引用未更新），再按 Nacos rebind / 监听重建两路根治；与原理题 C10.21、规范题 C10.26 形成"场景 + 原理 + 规范"三视角。

某电商平台订单中心服务（4核8G x 8节点），日均订单量 120 万，大促期间峰值 QPS 8000。大促当晚 22:00 告警群集中爆发 java.lang.OutOfMemoryError: Java heap space，3 个节点相继重启，GC 日志显示 Full GC 后堆内存仅从 6.2G 回落到 5.8G（回收不足 7%），Old Gen 占用持续上升。JVM 启动参数为 -Xms6g -Xmx6g -XX:+UseG1GC -XX:MaxGCPauseMillis=200，应用使用 SpringBoot 2.1.3 + MyBatis + Redisson（存量 2.x 现场设定；排障方法同样适用于 Boot 3.x）。

1）生产环境无法随意重启，需在不影响线上交易的前提下抓取现场；2）堆 dump 文件高达 6G，下载与分析耗时，MAT 直接打开易 OOM；3）Full GC 频繁导致 STW 600ms+，接口超时率从 0.1% 飙升至 12%；4）泄漏对象可能是 ThreadLocal、大 List 缓存、未关闭资源等多种原因，需快速收敛定位路径。

采用 "现象→现象归因→证据收集→根因定位→修复验证" 五步法。第一步确认 OOM 类型（Heap / Metaspace / Direct Memory / Stack），通过 JVM 参数 -XX:+HeapDumpOnOutOfMemoryError 和 jcmd <pid> GC.heap_info 判断；第二步区分内存泄漏（Old Gen 单调递增不回收）vs 内存溢出（瞬时大对象，GC 后恢复），看 GC 曲线斜率；第三步用 Arthas 在线观察对象拓扑，确定是哪类对象主导 Retained Size；第四步通过 MAT Dominator Tree + GC Root 路径定位引用链；第五步修复后用 JFR（Java Flight Recorder）持续观测 24h 确认 Old Gen 稳定。

排查步骤（按时间顺序严格执行）：

Step 1 - 应急止血：立即摘除故障节点流量（Nginx upstream weight=0），保留 1 个未重启节点供排查。jps 确认 PID：jps -l

Step 2 - GC 日志分析：查看 -Xlog:gc* 或 -XX:+PrintGCDetails 输出，用 GCEasy（gceasy.io）上传分析，关注 Full GC 频率、Old Gen 回收率、对象晋升速率。

Step 3 - Arthas 在线诊断（不抓 dump 先看趋势）：
arthas-boot.jar → attach 到目标 PID
dashboard 看 GC 次数与堆各区占用
heapdump --live /tmp/heap.hprof 只 dump 存活对象（加 --live 触发一次 GC，过滤掉可回收对象，文件更小）

Step 4 - jmap 手动 dump（Arthas 不可用时）：
jmap -dump:format=b,file=/tmp/heap.hprof <pid>
注意：jmap 全量 dump 会 STW，务必先摘流；加 -F 强制 dump 仅在进程僵死时使用。

Step 5 - MAT 离线分析：用 MAT 打开 6G dump 需配置 MemoryAnalyzer.ini 的 -Xmx4g，使用 "Leak Suspects Report" 自动报告，再看 Dominator Tree 按 Retained Heap 排序，定位占比最大的对象。本例定位到 LocalCacheManager 内 ConcurrentHashMap 持有 83 万个 OrderContext 对象，Retained 4.1G。

Step 6 - 引用链追溯：MAT 中右键对象 → Merge Shortest Paths to GC Roots → exclude weak/soft references，发现缓存被静态变量 CacheHolder 引用，且缓存只有 put 没有 expire。

• 如果堆内存没问题但依然 OOM，可能是什么原因？
  排查 Direct Memory（堆外内存）和 Metaspace。Netty 的 ByteBuf 未 release、NIO 的 DirectByteBuffer 泄漏会触发 OutOfMemoryError: Direct buffer memory。用 -XX:MaxDirectMemorySize 限制，配合 NMT（jcmd <pid> VM.native_memory）定位。Metaspace OOM 多因动态类加载（如反射、CGLIB）未卸载，-XX:MaxMetaspaceSize 设上限并 dump class histogram 分析。
• 6G 的 dump 文件 MAT 打不开怎么办？
  方案一：MAT 配置 -Xmx4g 并开启 -XX:+UseG1GC，使用 "Leak Suspects Report" 而非全量解析。方案二：先用 jmap -histo:live <pid> 查看对象直方图，按对象数量排序快速定位可疑类。方案三：用 OQL（Object Query Language）在 MAT 中按类名查询特定对象，避免全量加载。方案四：jhat 虽已过时但可分页浏览。
• 如何在不重启的情况下实时监控内存泄漏趋势？
  用 Arthas 的 dashboard 持续观察 Old Gen 占用曲线，配合 logger 命令动态调整日志级别输出关键路径。更可靠的是接 Prometheus + Grafana，通过 JMX Exporter 采集 jvm_memory_bytes_used{area="heap"} 指标，设置 Old Gen 增长率告警（如 1 小时增长超 500MB 告警），在 OOM 前发现泄漏。
• ThreadLocal 导致的内存泄漏如何排查？
  MAT 中搜索 java.lang.ThreadLocal$ThreadLocalMap 对象，查看 Entry[] 数组中 value 的引用链。常见于线程池场景：线程复用但 ThreadLocal 未 remove，Entry 的 key（WeakReference）被回收但 value 强引用存在。修复：try-finally 中调用 ThreadLocal.remove()，或使用 TransmittableThreadLocal（阿里 TTL）在线程池场景自动清理。

• jmap -dump 未摘流量直接抓：生产环境全量 dump 会触发长达数秒的 STW，导致所有请求超时。务必先在网关层摘除该节点流量再执行，或使用 Arthas 的 heapdump --live 降低影响。
• 只看 Shallow Heap 不看 Retained Heap：Shallow Heap 是对象自身大小，Retained Heap 是对象被回收后能释放的总内存。定位泄漏必须按 Retained Heap 排序，否则会被 String、char[] 等"受害者"误导。
• 忽略了 -XX:+HeapDumpOnOutOfMemoryError 配置：未配置该参数时 OOM 不会自动 dump，现场丢失后无法复现。必须在启动参数中固定配置，并指定 dump 路径到独立磁盘，避免撑爆根分区。
• 修复后未做长时间验证：泄漏修复后只观察 1 小时就上线，掩盖了缓慢泄漏（每小时增长 50MB）。需用 JFR 或 Prometheus 持续观测 24-48 小时，确认 Old Gen 在多次 Full GC 后能回落到基线。

某支付平台核心交易服务（8核16G x 12节点），日均交易 500 万笔，峰值 TPS 3000。某日 14:30 监控告警 3 个节点 CPU 持续 100% 持续 8 分钟未恢复，接口 P99 从 50ms 飙到 8000ms，支付成功率从 99.99% 跌至 97%。应用使用 SpringBoot 2.1.3 + Dubbo + Redis（存量 2.x 现场设定；排障方法同样适用于 Boot 3.x），JVM 参数 -Xms8g -Xmx8g -XX:+UseG1GC，线程池配置 corePoolSize=200, maxPoolSize=400。

1）CPU 100% 原因多样：业务代码死循环、频繁 Full GC（GC 线程占用）、正则回溯爆炸、序列化热点、锁自旋；2）8 核机器需区分是单线程跑满（1 核 100%）还是多线程竞争（8 核都 100%），排查路径完全不同；3）高 CPU 下 jstack 可能无法响应，需要技巧获取线程栈；4）12 个节点需快速判断是共性问题（代码 bug）还是单点问题（数据倾斜）。

使用 "系统级→进程级→线程级→代码级" 四层下钻法。系统级用 top/atop 看整机 CPU、load average、是否 sys% 过高（上下文切换）；进程级用 top -Hp <pid> 看 Java 进程内各线程 CPU 占比，区分是 GC 线程还是业务线程；线程级用 jstack 抓取线程栈，将十进制线程 ID 转十六进制后在栈中 grep 定位；代码级分析该线程的调用栈，定位具体方法。同时并行检查 GC 日志排除 GC 导致的 CPU 飙升（Full GC 频率 > 1次/秒即可拉满 CPU）。

排查步骤（经典 top → jstack 三步法）：

Step 1 - 定位 Java 进程：
top -c 按 CPU 排序，找到 java 进程 PID（如 28456），确认 CPU 100% 是该进程导致。

Step 2 - 定位高 CPU 线程：
top -Hp 28456（-H 显示线程，-p 指定进程）
按 CPU 列排序，记录 CPU 最高的线程 PID，如 28511，CPU 占用 95%。

Step 3 - 线程 ID 转十六进制：
printf "%x\n" 28511 → 输出 6f5f
注意：jstack 中 nid 是十六进制，需转换。

Step 4 - jstack 定位代码：
jstack 28456 > /tmp/thread.dump
grep "nid=0x6f5f" -A 30 /tmp/thread.dump
查看该线程的调用栈，定位到 PaymentService.checkRisk() 方法中一个 while 循环。
建议连续 jstack 三次（间隔 2 秒），对比栈是否变化，判断是死循环（栈不变）还是慢方法（栈变化）。

Step 5 - Arthas 在线诊断（更高效）：
arthas-boot.jar → thread -n 5 直接列出 CPU 占比最高的 5 个线程及堆栈
thread 28511 查看指定线程详情
profiler start → 运行 30 秒 → profiler stop --format html 生成火焰图

Step 6 - 排查 GC 因素（必须并行）：
jstat -gcutil 28456 1000 5 每秒打印 1 次共 5 次
若 FGC 列持续增长且 GCT 列占比高，说明 CPU 被 GC 消耗，需转 OOM 排查路径。

• CPU 100% 但 jstack 显示线程都在 WAITING，怎么回事？
  这是典型的 GC 导致 CPU 飙升。GC 线程（Gang Worker）不显示在 jstack 的业务线程中，但 top -Hp 能看到 "VM Thread" 或 "G1 GC Thread" 占用高。用 jstat -gcutil 确认 FGC 频率，转 OOM/内存排查路径。另一个可能是 JIT 编译（C2 CompilerThread）在持续编译热点代码，通常启动后短时间内会自行回落。
• top 显示 sys% 很高（超过 30%）是什么原因？
  sys% 高表示内核态 CPU 消耗，常见原因：1）线程数过多导致上下文切换（用 vmstat 1 看 cs 列，超过 10 万/秒异常）；2）大量系统调用如频繁的 network I/O 或 disk I/O；3）锁竞争导致的 futex 系统调用。排查用 pidstat -t -p <pid> 1 查看各线程上下文切换次数，定位后减少线程数或优化锁粒度。
• 连续三次 jstack 栈完全一样就一定是死循环吗？
  不一定。也可能是线程卡在 native 方法（如 SocketRead0）或等待锁。需结合线程状态判断：RUNNABLE 且栈指向业务代码 → 死循环或 CPU 密集计算；BLOCKED → 锁竞争；WAITING → 正常等待。死循环的典型特征是 RUNNABLE 状态且栈顶是 Java 业务方法（非 JDK 等待方法），多次抓取栈帧一致。
• 如何建立 CPU 异常的常态化监控？
  多维度监控：1）系统级用 node_exporter 采集 CPU 使用率、load average、上下文切换次数；2）JVM 级用 JMX Exporter 采集线程数、GC 频率；3）告警策略：CPU > 80% 持续 3 分钟触发 P2，load > 核数 * 2 触发 P1；4）自动诊断：告警时触发脚本自动 jstack + jstat 存档，保留现场供后续分析。

• jstack 只抓一次就下结论：单次 jstack 是某个瞬间的快照，可能刚好抓到线程在等待 IO 的瞬间。必须连续抓 3 次以上间隔 2-5 秒，对比堆栈变化趋势，才能区分死循环、慢方法还是正常等待。
• 线程 ID 忘记转十六进制：top -Hp 显示的是十进制线程 ID，jstack 中 nid 是十六进制。忘记 printf "%x" 转换会导致 grep 不到对应线程。经验：nid=0x 开头，十进制最大不过几万，十六进制一般 3-4 位。
• 忽略了 GC 导致的 CPU 飙升：只看业务线程堆栈，没并行检查 jstat -gcutil。如果 Full GC 每秒 2 次以上，GC 线程会吃满 CPU 但 jstack 业务线程看起来都正常。排查 CPU 问题时必须同时跑 jstat。
• Arthas profiler 在生产长时间运行：async-profiler/profiler start 采样有开销（虽低但非零），生产环境建议限制在 30-60 秒。长时间运行 profiler 自身会贡献 CPU 和内存，且生成火焰图文件巨大。

某电商商品详情页接口 /api/product/{id}，日均 PV 3000 万，大促峰值 QPS 15000。当前 P99 响应时间 200ms，产品要求优化到 20ms 以内。接口内部逻辑：查商品基础信息（MySQL，15ms）→ 查价格促销（MySQL，25ms）→ 查库存（Redis，5ms）→ 查评价摘要（MySQL，40ms）→ 查推荐商品（RPC，50ms）→ 查标签属性（MySQL，30ms）→ 组装返回（35ms），总计约 200ms（串行调用）。MySQL 单表 2000 万行，Druid 连接池 maxActive=20。

1）6 个数据源调用全部串行，总耗时为各阶段之和；2）MySQL 查询有 4 个慢 SQL，评价表（5000 万行）全表扫描；3）大促 QPS 15000 下连接池只有 20 个连接，排队等待加剧延迟；4）缓存命中率仅 30%（按商品 ID 粒度缓存，促销价格频繁变动导致频繁失效）；5）推荐商品 RPC 依赖下游服务，偶发超时拖垮整体。

采用 "测量→分析→优化→验证"（MAOV）循环。测量用 SkyWalking/Arthas trace 命令画出调用链耗时分布，找到 Top3 耗时点；分析每个耗时点的瓶颈类型——IO 等待型（DB/RPC）、CPU 计算型（序列化/大对象组装）、锁竞争型；优化按 "缓存 > 并发 > 批量 > 索引 > 连接池 > 序列化" 优先级实施；验证用 JMeter 压测确认 P99 达标且无功能回归。核心原则：减少串行 IO 次数（N+1 → 1）、缩短单次 IO 延迟（索引/缓存）、并行化无依赖调用（CompletableFuture）。

分层优化方案（按收益排序）：

优化 1 - 多级缓存（收益 60%）：引入 Caffeine（本地 L1）+ Redis（分布式 L2）二级缓存。商品基础信息、标签属性变更频率低，缓存 TTL 10 分钟，命中率可达 95%+。价格促销单独缓存，TTL 1 分钟。缓存 Key 用 product:{id}:info 格式，采用 "读时填充 + 写时失效" 策略。

优化 2 - 并行化（收益 50%）：将 6 个串行调用改为并行。无依赖的调用用 CompletableFuture.supplyAsync() 并行执行：商品基础信息先行（后续依赖它），然后价格、库存、评价、标签、推荐并行。理论耗时从 200ms 降至 max(15ms, 50ms) + 35ms ≈ 85ms。

优化 3 - 批量查询与 SQL 优化（收益 30ms）：评价摘要表加 (product_id, is_deleted, created_at) 联合索引，避免全表扫描；评价查询从查全量改为 SELECT COUNT + AVG 聚合查询；推荐商品 RPC 改为批量接口一次性返回。

优化 4 - 连接池调优（收益 10ms）：Druid maxActive 从 20 调到 50，配合 HikariCP（性能更优）maxPoolSize=50, minIdle=20。超时时间 notimeout=3000ms，避免连接被慢 SQL 占用。

优化 5 - 异步化非核心链路（收益 15ms）：评价摘要、推荐商品改为异步加载（接口先返回核心数据，前端二次 AJAX 拉取），或用 MQ 异步写入浏览记录。

• 缓存和数据库一致性怎么保证？
  采用 "先更新 DB，再删除缓存"（Cache Aside）策略。延迟双删：更新 DB 后先删一次缓存，异步延迟 500ms 再删一次，规避并发读写导致的脏读。对一致性要求极高的字段（如价格），用 binlog 订阅（Canal）异步更新缓存，保证最终一致。避免先删缓存再更新 DB，因为并发下另一个请求会把旧数据回填。
• CompletableFuture 并行后线程池怎么配置？
  不要用默认的 ForkJoinPool.commonPool()，它会与其他 CompletableFuture 共享且并行度受 CPU 核数限制。应自定义线程池：corePoolSize = CPU 核数 * 2，maxPoolSize = CPU 核数 * 4，队列用 LinkedBlockingQueue(200)，拒绝策略用 CallerRunsPolicy（背压降级）。注意线程池要隔离，商品详情的线程池不能被其他业务共用，避免互相拖垮。
• 缓存穿透和击穿如何处理？
  穿透（查不存在的 key）：对查询结果为 null 的也缓存短 TTL（30秒），或用布隆过滤器（Redisson RBloomFilter）前置拦截。击穿（热点 key 过期瞬间大量请求穿透）：用 Caffeine 的 refreshAfterWrite 异步刷新，或加分布式锁（Redisson tryLock）只放一个请求查 DB 回填缓存，其他请求等待。雪崩（大量 key 同时过期）：TTL 加随机偏移（如 10min ± 2min）。
• 如何验证优化效果且不遗漏回归问题？
  分三步验证：1）单接口压测，JMeter 模拟 15000 QPS 持续 5 分钟，确认 P99 < 20ms、错误率 < 0.01%；2）全链路压测，在预发环境接入下游依赖，验证并行调用不会因下游超时引发雪崩；3）灰度发布，10% 流量灰度 24 小时，监控 SkyWalking 链路耗时分布与缓存命中率，确认无功能回归后全量。

• 缓存粒度过大导致频繁失效：将整个 ProductDetailVO 作为一个缓存对象，任何一个子字段变更（如库存）都导致整缓存失效。应按字段拆分缓存 Key，基础信息、价格、库存各自独立缓存，变更高频的字段单独管理 TTL。
• CompletableFuture 用了默认线程池：supplyAsync 不传 executor 时使用 ForkJoinPool.commonPool()，高并发下与其他任务争抢线程导致阻塞。必须传入独立配置的线程池，且不同业务隔离。
• 并行化后没有超时降级：allOf().get() 不设超时，一旦某个下游 RPC 卡住，整个接口被拖死。必须设置合理超时（如 50ms）并用 getNow(defaultValue) 降级返回默认值。
• 索引加了但没看执行计划：加了索引就以为优化生效，实际可能因为索引选择性差、隐式类型转换、函数包裹列导致索引失效。必须 EXPLAIN 确认 type=ref/range 且 rows 扫描行数大幅下降。

某 O2O 平台订单消息链路：订单服务 → RocketMQ → 消费者（库存扣减、积分发放、通知推送），日均消息量 2000 万条，大促峰值 5 万 TPS。曾出现三类故障：1）MQ 宕机切换期间丢失约 2 万条订单消息，导致库存不扣减；2）消费者重启时重复消费，积分多发 3 倍；3）大促消息积压 800 万条，积压 2 小时才消费完。需设计全链路可靠性方案。

1）消息丢失发生在三个环节——生产者发送失败、Broker 刷盘丢失、消费者异步处理异常，需全链路保障；2）消息重复不可避免（网络重试、消费者 ACK 丢失），必须业务层幂等；3）订单状态变更有顺序要求（待支付→已支付→已发货），乱序会导致状态机错乱；4）大促突发流量下，消费速度跟不上生产速度，积压导致业务延迟，需动态扩容与降级策略。

按消息生命周期分三段保障：生产端（不丢）、Broker 端（不丢不乱）、消费端（不丢不重复）。生产端用 "本地消息表 + 定时补偿" 或事务消息保证消息一定到 Broker；Broker 端配置同步刷盘 + 主从同步复制保证持久化，用 MessageQueueSelector 保证同一订单消息路由到同一 Queue 实现分区顺序；消费端用 "幂等表 + 手动 ACK" 保证精确一次处理（Exactly-Once 语义）。积压治理用 "扩消费者 + 批量消费 + 降级非核心链路" 组合拳。

一、防丢失（生产 + Broker + 消费三段式）

生产端：RocketMQ 事务消息（半消息 → 本地事务 → commit/rollback），或本地消息表方案——订单写 DB 时同事务写 message_outbox 表，定时任务扫描发送，发送成功后标记已发送。

Broker 端：配置 flushDiskType=SYNC_FLUSH（同步刷盘）、brokerRole=SYNC_MASTER（主从同步复制），牺牲少量性能换可靠性。

消费端：关闭自动 ACK，业务处理成功后手动 CONSUME_SUCCESS；失败返回 RECONSUME_LATER 进入重试队列，重试 16 次后进入死信队列（DLQ）人工处理。

二、防重复（幂等设计）

消费者维护幂等表（Redis SETNX + DB 唯一索引双保险）：消息体携带 bizId（订单号+操作类型），消费前检查幂等表是否已处理，已处理直接跳过。

三、保顺序（分区顺序）

同一订单的消息用 orderId % queueSize 作为路由 key，确保同一订单消息进同一 Queue，消费者单线程消费该 Queue，保证局部顺序。

四、治积压（三层降级）

第一层：动态扩容消费者节点（K8s HPA 基于 lag 指标自动扩容）；第二层：批量消费（consumeMessageBatchMaxSize=50）+ 并发消费（consumeThreadMax=64）；第三层：降级非核心消息（通知推送暂停消费，优先保障库存扣减）。

• 事务消息的半消息回查机制原理是什么？
  生产者发送半消息到 Broker（此时消费者不可见），执行本地事务后发送 commit/rollback。若 Broker 超时未收到二次确认（默认 60 秒），主动回调生产者的 checkLocalTransaction 方法回查本地事务状态。生产者需实现回查逻辑——查本地 DB 中订单是否创建成功，返回 COMMIT / ROLLBACK / UNKNOWN。回查有次数上限（默认 15 次），超时后默认 ROLLBACK。
• 幂等表数据持续增长怎么清理？
  按业务场景设置保留策略：Redis 幂等 Key 设 TTL（如 24 小时），覆盖消息最大重试周期即可。DB 幂等表按 created_at 分区，保留 7-30 天后归档或删除。注意：清理前确认该 bizId 不会再有重试消息到达（RocketMQ 默认重试 16 次约 4.6 小时，Kafka 消费者重启一般不会重试 7 天前的消息）。
• 顺序消费时某个消息卡住，后面的消息怎么办？
  顺序消费下，同一 Queue 的消息必须串行处理，前一条未 ACK 后面不会消费。若某消息处理卡住，会触发 Broker 的消费超时检测（默认 5 分钟），超时后 Broker 主动将该消息重投到其他消费者。但如果是死循环导致一直不 ACK，会阻塞整个 Queue。解决方案：消费端设置处理超时（如 30 秒），超时后记录日志并跳过（返回 SUCCESS），将问题消息转人工处理，不阻塞后续消息。
• 积压 800 万条如何快速清积压？
  三步应急：1）立即扩容消费者节点（HPA 或手动扩 Pod），注意顺序消费场景下扩容无效（Queue 数固定），需先增加 Topic 的 Queue 数量再扩消费者；2）临时改为批量消费（batch=50）+ 提高并发线程数（64）；3）若积压严重且非核心链路，临时跳过通知类消息只消费库存类。根本治理：评估常态 TPS 与峰值 TPS，按峰值 1.5 倍规划消费者数量，设置积压告警阈值（lag > 10 万告警）。

• 幂等校验在业务处理之前删除标记：先删幂等标记再执行业务，若业务执行到一半异常，标记已删，重试时会重复执行。正确做法：业务成功后才确认（保留标记），业务异常时删除标记允许重试，或用消息状态机（PROCESSING → SUCCESS）管理。
• 顺序消费全局排序而非分区排序：误以为要保证所有消息全局有序，导致只能单 Queue 单消费者，吞吐极低。实际只需保证同一业务 Key（如同一订单）的消息有序，用 hashKey 路由到同一 Queue 即可，不同订单可并行。
• 消费者自动 ACK 但业务异步处理：开启自动 ACK 后消息取出即标记消费成功，但业务逻辑在异步线程执行，若异步失败消息已丢失。必须手动 ACK：业务处理完成后才返回 SUCCESS，或用同步消费模式。
• 忽略死信队列监控：重试耗尽的消息进入 DLQ 后无人处理，导致业务静默失败。必须监控 DLQ 消息数量并配置告警，定期消费 DLQ 消息做人工补偿或告警通知运营。

某电商平台大促前需验证系统能否承载 10 倍日常流量，但生产环境压测存在数据污染、资金风险、下游第三方限流等问题。要求设计一套全链路压测体系，支持流量隔离、影子库表、mock 下游、动态降压，并输出准确的容量水位报告。

① 流量隔离：压测流量如何与真实流量区分，避免污染生产数据；② 影子存储：压测产生的订单、支付记录写入哪里；③ 下游保护：第三方物流、支付通道无法承受压测流量；④ 模型真实性：压测请求分布是否与真实用户行为一致；⑤ 容量换算：压测结果如何推导线上真实容量。

采用"流量染色 -> 影子隔离 -> Mock 兜底 -> 梯度加压 -> 容量建模"五步压测法：通过网关层识别压测标记（如 Header x-stress-test=1），路由到影子库表；对无法承受压测的下游使用 MockServer 或本地缓存兜底；使用 Gatling 录制真实流量并放大；最终通过 Little's Law 和排队论模型换算容量。

1. 流量染色：压测请求携带统一标记（HTTP Header x-stress-test=1 或特定 Token），网关层识别后写入 ThreadLocal，后续所有服务透传该标记；MQ 消息增加 stress 属性，消费端根据标记路由到影子 Topic。

2. 影子存储：数据库通过ShardingSphere/Mycat 配置影子规则（stress_ 前缀表），压测 SQL 自动路由到影子表；Redis 使用独立 DB Index（如 DB 1），压测结束后一键清空。

3. Mock 下游：对于第三方支付、物流等外部接口，Dubbo/Spring Cloud 路由层识别压测标记后转发到 Mock 服务，返回固定成功响应；内部下游通过 Sentinel 限流保护，超出阈值自动降级。

4. 梯度加压：从 1× 日常流量开始，每 10 分钟增加 1×，观察 RT、错误率、CPU、内存曲线；当出现错误率 > 0.1% 或 RT 翻倍时停止加压，当前流量即为容量上限。

5. 容量建模：记录各流量水位下的资源利用率，建立线性回归模型；推导日常 3× 流量所需机器数 = (3 × 峰值 QPS × 目标 RT) / (单核处理能力 × 目标 CPU 利用率)。

• 追问1：压测流量模型与真实流量差异大，如何校准？
  通过生产日志抽样分析用户行为分布（浏览 80%、搜索 15%、下单 5%），使用 Gatling 的 feeder 按该比例构造请求；大促时结合历史数据调整秒杀、抢购等突发流量模型。
• 追问2：影子表结构与生产表如何保持同步？
  通过 CI/CD 流水线，生产表结构变更（DDL）自动同步到影子库；或使用 Online DDL 工具（gh-ost）同时作用于生产库和影子库。
• 追问3：压测结果显示容量不足，但无法立即扩容怎么办？
  优先做降级预案：关闭非核心功能（如推荐、评论）、降级复杂查询为简单查询、增加缓存预热、限流非核心接口。通过"减耗"而非"增容"度过峰值。

• 压测流量未彻底隔离导致生产数据污染：曾发生压测订单进入真实履约流程导致发货。必须在网关层、消息层、存储层全链路识别压测标记，任何漏点都可能导致污染。
• 忽略下游第三方的限流和费用：压测时调用第三方支付接口可能触发风控封禁或产生高额手续费。必须提前通知合作方或使用 Mock 替代。
• 一次性加压到极限导致系统雪崩：应梯度加压并设置自动熔断，一旦错误率超过阈值立即停止，避免压垮生产环境。

某电商中台 120+ 微服务，线程池用法三派并存：① 直接 new ThreadPoolExecutor 后业务里 pool.execute(r)（原生侵入）；② Spring ThreadPoolTaskExecutor + @Async("beanName")；③ 上 DynamicTP/外置调参，但仍单池混跑。大促翻车：共享池 HOL 拖死下单；有人 @RefreshScope 重建池泄漏；另有代码绕过 Spring 直接 execute，MDC/TraceId/安全上下文丢失导致排障与权限错乱。平台要求把Spring 框架池 vs 自定义原生池、以及动态调参池 × 快慢双池一次讲清。

1）Spring TaskExecutor/ThreadPoolTaskExecutor 与 JDK ThreadPoolExecutor#execute 的能力边界与侵入成本；2）何时必须下沉原生、何时应留在 Spring 抽象；3）动态调参与双池是替代还是互补；4）原地热更新 vs 重建泄漏；5）上下文传递（MDC/Trace/Security）在 execute 路径如何补齐；6）VT 下 Spring 开关与自定义池如何共存。

先分清载体形态，再谈治理方案。

对比 A · Spring 框架线程池（ThreadPoolTaskExecutor / AsyncTaskExecutor、@EnableAsync、TaskDecorator）：Spring 生命周期（initialize/shutdown）、与 @Async/@Scheduled 集成、可用 TaskDecorator 统一包装上下文；底层仍是 ThreadPoolExecutor。默认坑：未定制时 SimpleAsyncTaskExecutor 可能「每任务新线程」；不指定 executor 的 @Async 易落到错误默认池。适合业务异步、要容器托管与低侵入声明式调用。

对比 B · 自定义线程池 + 原生 execute：直接持有 ThreadPoolExecutor，参数/拒绝/队列完全可控，易接 DynamicTP 原地 set*。但侵入高——调用点散落 execute/submit，难统一装饰器；MDC/Trace/租户需手写 Runnable 包装或 TTL；若不注册为 Spring Bean，优雅停机与指标易漏。适合中间件、回调密集型、要绕过 Spring 代理开销或非 Spring 模块。

推荐折中：平台用原生 TPE（或 DynamicTP）创建快慢池 → 包装成 Spring TaskExecutor Bean 暴露；业务优先 @Async("fastExecutor") / 注入 TaskExecutor；仅框架内核保留原生 execute，并强制装饰器。

治理两维（与载体正交）：① 外置动态调参池——配置中心 + 原地 set* + 审计回滚，解决运营闭环，不消 HOL；② 快慢双池架构——fast/slow 物理隔离 + 路由，解决队头阻塞。推荐：Spring Bean 暴露的双池 × 每池动态调参。

共同红线：禁 Executors 快捷工厂与无界队列；命名 ThreadFactory；拒绝可观测；与连接池联合预算（G03.07）。对齐 C04、G03、S02.04、S04.06。

A. Spring 路径（业务默认）：定义 ThreadPoolTaskExecutor（或包装 DynamicTP）Bean 名 fastExecutor/slowExecutor；设 TaskDecorator 传递 MDC/Trace；业务 @Async("fastExecutor") 或注入 AsyncTaskExecutor。CI 禁止无指定执行器的 @Async。

B. 原生 execute 路径（受限）：仅中间件/SDK；统一 PoolFacade.execute(poolId, r) 内做装饰与指标；禁止业务直接持有 TPE 引用四处 execute。

C. 动态调参：监听配置 → 对底层 TPE 原地 setCore/setMax；禁 @RefreshScope 重建；调幅上限 + 审计 + 与下游配额校验。

D. 双池：Fast 小队列拒绝可感；Slow 更大有界队列；压测验收打爆 Slow 时 Fast P99 仍达标。

E. VT：spring.threads.virtual.enabled 管框架默认执行器；自定义快慢池是否切 VT 要单独评估，慢下游仍要信号量/有界池背压。

• 为什么不推荐业务到处 pool.execute？
  调用点侵入、上下文易丢、难以统一拒绝与限流策略，回归成本高。业务用 Spring TaskExecutor/@Async；原生 execute 收口到门面。
• ThreadPoolTaskExecutor 和直接 TPE 性能差在哪？
  热点路径包装一层可忽略；差异主要在功能（生命周期、Decorator、与 Spring 集成）。不要为微优化在业务层改回裸 execute。
• 只有动态调参、不拆双池，把 queue 调很大行吗？
  不行。只推迟拒绝，HOL 仍在。调参不能替代拓扑隔离。
• @EnableAsync 不指定 executor 会怎样？
  易落到默认 SimpleAsyncTaskExecutor（新线程模型）或非预期 Bean，容量不可控。必须显式 bean 名并进 CI。
• 开启 spring.threads.virtual.enabled 后自定义双池还要吗？
  框架默认执行器可能切 VT，但自定义 Bean 不会自动变；慢下游仍要档位限流/双池思想。VT 不取消背压。
• 如何验收？
  打爆 Slow 时 Fast P99 达标；断 MDC 传递用例（execute 路径）必须失败于门面单测；调参前后曲线与审计可查。

• 业务满屏 execute：丢 Trace/权限上下文，排障灾难。
• @Async 无指定池 / 默认 SimpleAsync：线程爆炸或误用公共池。
• 用动态调参掩盖单池混跑：旋钮掩盖 HOL。
• 热更新重建池：@RefreshScope 泄漏（S04.06）。
• 双池名、单实例；Fast 队列过大；Discard 静默丢。
• VT 取消限流：打穿连接池。

某 SaaS 平台 API 网关（Spring Cloud Gateway），日均请求量 5 亿次，峰值 QPS 8 万，平均每个请求需调用 3-5 个下游微服务（IO 密集型）。当前基于 Reactor WebFlux + Netty 的响应式编程模型，开发复杂度高、调试困难、排障链路追踪可读性差。团队希望迁移到 Java 21 虚拟线程（JEP 444）+ Spring Boot 3.2 的同步编程模型，降低开发心智负担的同时保持或提升吞吐量。当前平台线程池配置：HTTP 请求处理 200 线程，RPC 调用池 500 线程，高峰期线程数 800+，上下文切换开销显著。

1）虚拟线程不适合所有场景——CPU 密集型任务不适合；JDK 21–23 在 synchronized 持锁阻塞时会 pin，JDK 24+ 该问题基本消除（native 仍可能 pin）；2）ThreadLocal 在虚拟线程下因线程数暴增（百万级）导致内存膨胀，需迁移到 ScopedValue；3）现有代码大量使用 CompletableFuture + 共享 ForkJoinPool，迁移后线程模型变化可能引发难以发现的并发 bug；4）第三方库（如 MyBatis、HikariCP）内部使用 synchronized 需评估兼容性；5）结构化并发（StructuredTaskScope）尚处预览阶段，生产可用性需验证。

虚拟线程的核心原理是 "用户态调度 + IO 时让出载体内（载体线程）"。平台线程（OS 线程）是载体，虚拟线程在 IO 阻塞时自动 unmount 从载体线程卸载，载体线程去执行其他虚拟线程，从而用少量载体线程（默认 = CPU 核数）调度海量虚拟线程。关键约束：pinning 使载体线程被独占。版本线（真源 C04.09）：JDK 21–23 在 synchronized 内阻塞会 pin；JDK 24+（JEP 491）几乎消除 synchronized pinning，native/JNI 仍可能 pin。迁移评估：1）按 JDK 版本选诊断工具并定位热点；2）JDK 21–23 热点 synchronized 可改 ReentrantLock，JDK 24+ 按功能需求改锁；3）ThreadLocal 大对象评估 ScopedValue；4）IO 密集启用 VT，CPU 密集仍用平台线程池。

迁移分四阶段推进：

阶段一 - 评估与兼容性改造：用 JFR jdk.VirtualThreadPinned 与 jcmd <pid> Thread.dump_to_file 分析钉住。HikariCP 升 5.1+。JDK 21–23 可加 -Djdk.tracePinnedThreads=full|short 定位热点 synchronized，并评估改 ReentrantLock；JDK 24+ 该属性已移除，以 JFR/线程转储为准，不必仅为 pinning 全量改锁。MyBatis 等第三方同步块按压测热点治理。

阶段二 - 网关层启用虚拟线程：Spring Boot 3.2 配置 spring.threads.virtual.enabled=true，Tomcat/Netty 自动使用虚拟线程处理 HTTP 请求。网关的下游 RPC 调用（Dubbo/Feign）在虚拟线程中阻塞等待响应，不再占用平台线程。

阶段三 - 结构化并发改造：用 StructuredTaskScope 替代 CompletableFuture，实现父子任务生命周期绑定——父任务取消时所有子任务自动取消，避免线程泄漏。

阶段四 - 渐进灰度与监控：按路由灰度 10% → 50% → 100%，监控载体线程数（应稳定在 CPU 核数附近）、虚拟线程数（可达数万）、GC 频率（虚拟线程对象在 Young Gen，需关注 GC 压力）、P99 延迟。

• 虚拟线程什么场景下会退化为平台线程（pinning）？如何检测？
  JDK 21–23：synchronized 内阻塞或 native/JNI 期间可能 pin。JDK 24+（JEP 491）：synchronized 几乎不再 pin，剩余多为 native/FFI。检测：21–23 可用 -Djdk.tracePinnedThreads=full|short；24+ 该属性移除，改用 JFR jdk.VirtualThreadPinned + Thread.dump_to_file。完整对照见 C04.09。
• 虚拟线程下 ThreadLocal 为什么会有内存问题？怎么替代？
  平台线程几百个，ThreadLocal 数据量可控。虚拟线程可达百万级，每个都有独立的 ThreadLocal Map，若存大对象（如 UserContext 2KB），百万虚拟线程 = 2GB 内存。替代方案：用 ScopedValue（JEP 446，不可变且绑定作用域，方法调用栈结束自动释放），或显式传递参数而非 ThreadLocal 隐式传递。必须用 ThreadLocal 的场景，用 ThreadLocal.ofInitialValue 并在 finally 中 remove。
• 虚拟线程 vs 响应式编程，如何选型？
  虚拟线程适用：IO 密集型、同步编程心智更易接受、团队对响应式掌握不足、调试可读性要求高。响应式适用：需要背压控制的流式处理（如 SSE/WebSocket 数据流）、CPU 与 IO 混合且需精细调度、已有 Reactor 生态沉淀。两者不互斥：网关层可用虚拟线程，流式处理模块仍用响应式。Spring Boot 3.2 支持混用：spring.threads.virtual.enabled=true 时 MVC 用虚拟线程，WebFlux 仍用 Reactor。
• 迁移过程中如何做兼容性回退？
  通过配置开关控制：spring.threads.virtual.enabled 设为条件配置（@ConditionalOnProperty），按环境变量切换虚拟线程/平台线程。灰度策略：先在预发环境全量虚拟线程压测，生产按路由灰度（10% 流量走虚拟线程节点），对比 P99、吞吐量、GC、错误率。准备回退方案：一旦异常，修改配置重启即可回退到平台线程，无需改代码。关键：迁移期间保持两套线程模型代码兼容，避免硬编码线程池。

• 对 CPU 密集型任务用虚拟线程：虚拟线程优势在 IO 阻塞时让出载体线程。CPU 密集型任务（加密、压缩、排序）不阻塞 IO，虚拟线程不会 unmount，反而因调度开销比平台线程更慢。CPU 密集型应继续用固定大小平台线程池（Executors.newFixedThreadPool），仅 IO 密集型用虚拟线程。
• 未按 JDK 版本排查 pinning：JDK 21–23 在启用 VT 前须用 tracePinnedThreads/JFR 定位热点 synchronized；JDK 24+ 勿再依赖已移除的 tracePinnedThreads，改用 JFR，且不要机械“凡 synchronized 必换锁”。
• 虚拟线程池未限制数量导致资源耗尽：虽然虚拟线程轻量，但不限制数量可能导致 DB 连接池耗尽——10 万虚拟线程同时请求 HikariCP（maxPoolSize=50），9 万+ 线程阻塞在 getConnection。需用 Semaphore 限制并发 IO 调用数，或虚拟线程池配合信号量限流。
• 结构化并发 API 在正式版被移除/变更：StructuredTaskScope 截至 JDK 25 仍为 Preview 特性（JEP 505 第五次预览），API 仍在迭代。生产环境需封装抽象隔离 API 变化，或等正式转正后再全面使用。过渡期可用 CompletableFuture + 自定义超时管理替代。

某 AI 客服平台日均调用大模型 200 万次（GPT-4o / Claude / 通义千问 / 文心一言多供应商），峰值 QPS 500。大模型 API 存在三类不稳定：1）超时频繁——P99 延迟 15 秒，偶发 30 秒超时；2）限流/过载——各供应商返回 429/529 错误，高峰期 20% 请求被拒；3）成本控制——GPT-4o 单次调用成本 ¥0.15，日均 30 万元，需智能路由降低成本。业务要求：SLA 可用性 99.9%，P99 < 8 秒，失败请求自动降级到缓存回复或小模型。

1）大模型 API 延迟高且波动大（2-30 秒），传统 HTTP 重试策略（3 次重试）会放大延迟到分钟级；2）多供应商 API 格式不统一（OpenAI format vs Anthropic format vs 百度 format），需统一抽象层；3）流式响应（SSE）中断后无法简单重试，需特殊处理；4）限流维度复杂——按供应商 RPM/TPM 限制、按用户配额限制、按 token 数限制；5）缓存命中率低——相似问题表述不同（"怎么退货" vs "退货流程是什么"），精确匹配缓存无效，需语义缓存。

采用 "网关模式 + 熔断器模式 + 回退链" 架构。网关层统一封装多供应商 API，对外暴露统一接口；熔断器（Resilience4j CircuitBreaker）监控各供应商健康度，错误率超阈值时自动熔断切换；回退链定义降级策略：主模型（GPT-4o）→ 备模型（Claude）→ 小模型（GPT-4o-mini）→ 语义缓存命中 → 兜底话术。限流采用令牌桶（Redis + Lua）多维度限流。语义缓存用 Embedding 向量化请求，余弦相似度 > 0.95 时命中缓存。

一、统一 LLM 抽象层：定义 ChatClient 接口，各供应商实现（OpenAIClient、ClaudeClient、QwenClient），通过策略模式动态路由。请求/响应统一为内部 ChatRequest/ChatResponse 模型，屏蔽各供应商差异。

二、多模型智能路由：路由策略按优先级：1）成本优先——简单问题路由到小模型（token 数 < 200 用 GPT-4o-mini）；2）质量优先——复杂问题路由到 GPT-4o；3）健康度优先——熔断的供应商自动跳过。路由规则用配置中心动态调整。

三、重试与超时策略：非流式请求用指数退避重试（1s → 2s → 4s，最多 3 次），总超时 8 秒。流式请求（SSE）首 token 超时 3 秒重试，已收到 token 后中断不重试（避免重复输出）。429 错误读取 Retry-After 头精确等待。

四、熔断与降级链：Resilience4j 熔断器配置 failureRateThreshold=50%（10 次中 5 次失败触发熔断），waitDurationInOpenState=30 秒。降级链：GPT-4o → Claude → Qwen-Max → GPT-4o-mini → 语义缓存 → 兜底话术。

五、语义缓存：请求先经 Embedding 模型转向量，在 Milvus 中搜索相似度 > 0.95 的历史问答，命中则直接返回。TTL 24 小时，降低 30%+ 调用量。

• 流式响应（SSE）中断后如何处理？
  流式输出已开始（收到首个 token）后中断，不能简单重试——重试会从头输出导致重复。处理策略：1）记录已输出的 token 序列，重试时在 system prompt 中提示"从XX处续写"，但效果不稳定；2）更实际的方案是缓存已输出部分 + 补一句"回答生成中断，这是部分结果"，降级到小模型补全结尾；3）前端检测 SSE 断开后展示已收到的部分内容并给用户重试按钮。
• 语义缓存的相似度阈值怎么定？误命中怎么办？
  阈值需根据业务场景调优：客服场景推荐 0.92-0.95（偏保守避免误命中），知识问答可放宽到 0.88。误命中风险：相似问题实际答案不同（"如何退款" vs "如何拒绝退款"）。防护措施：1）对带否定词、数字参数的请求跳过缓存；2）缓存返回时标记"cached"，前端可选择是否重新生成；3）定期人工抽检缓存命中率与准确率，动态调整阈值。
• 如何实现按 token 数限流？
  大模型按 token 计费，需 TPM（Tokens Per Minute）限流。难点：请求前不知道精确 token 数。方案：1）请求前用 tokenizer（如 tiktoken）预估 input token 数，预扣减令牌桶配额；2）响应返回后用实际 output token 数修正（补扣或退还）；3）令牌桶用 Redis + Lua 脚本实现原子扣减，key 格式 rate:tpm:{userId}:{model}:{minute}。超额时返回 429 并提示等待时长。
• 多供应商的 prompt 格式不统一怎么处理？
  在抽象层做 prompt 适配转换：定义内部统一的 ChatMessage（role + content），各 ChatClient 实现中转换为供应商格式——OpenAI 用 messages 数组，Claude 用 system + messages 分离，百度用 messages 但 role 枚举不同。system prompt 的注入位置也不同（OpenAI 在 messages 中 role=system，Claude 单独 system 字段）。建议封装 PromptConverter 统一处理，新增供应商只实现 converter 接口。

• 重试放大延迟与成本：大模型请求本就慢（5-15 秒），重试 3 次可能累计 45 秒。必须设置总超时上限（如 8 秒），用 TimeLimiter 在超时后立即降级，而非等所有重试完成。同时重试只针对可恢复错误（429/503），不重试 400（请求格式错误）。
• 熔断器未按供应商隔离：用一个全局熔断器，GPT-4o 故障导致整个网关熔断。必须每个供应商独立熔断器（CircuitBreaker 注册表按 model name 隔离），GPT-4o 熔断不影响 Claude 调用。
• 语义缓存存储膨胀：每个缓存项需存储 Embedding 向量（1536 维 float），百万条缓存约 6GB。需设置缓存 TTL（24 小时）+ 最大条数（10 万条）+ LRU 淘汰。低频问题不缓存（近 7 天只出现 1 次的问题不值得缓存）。
• 限流只按 RPM 忽略 TPM：只限制每分钟请求数，但一个请求可能消耗 8000 token（长输入），导致 TPM 超额被供应商封禁。必须同时限 RPM 和 TPM，token 数预估用 tokenizer 预计算。

某大型企业内部知识库系统，沉淀文档 50 万篇（PDF/Word/Confluence/邮件，总计 200GB 文本），需构建 RAG（Retrieval-Augmented Generation）问答系统，员工通过自然语言提问获取精准答案。当前痛点：传统关键词搜索召回率低（35%），大模型直接回答存在幻觉且不知道企业内部知识。目标：召回率 > 85%，答案准确率 > 90%，单次问答 P95 < 5 秒，支持 500 并发。技术栈：Spring Boot 3 + Spring AI + Milvus + Redis + PostgreSQL。

1）文档分块（Chunking）策略直接影响召回质量——太大包含噪声、太小丢失上下文，表格/代码/长文需不同分块策略；2）Embedding 模型选择与成本——50 万文档全量 Embedding 约 1.5 亿 token，需选择性价比模型且支持中文；3）混合检索（向量 + 关键词）的融合排序——纯向量检索对专有名词/编号召回差，需结合 BM25 关键词检索；4）上下文组装与 Prompt 工程——检索到 N 个 chunk 后如何组装给 LLM，避免上下文超限和噪声干扰；5）知识更新——文档变更后需增量更新向量索引，不能全量重建。

RAG 架构分为离线索引和在线检索两阶段。离线阶段：文档解析 → 清洗 → 分块 → Embedding → 存入向量数据库。在线阶段：用户提问 → Query 改写 → 向量检索 + BM25 检索 → 融合排序（RRF）→ 上下文组装 → LLM 生成 → 引用标注。核心指标：召回率（Recall@K）、精确率（Precision@K）、答案准确率。检索增强的关键不在 LLM 而在检索质量——"Garbage In Garbage Out"，检索到错误上下文比不检索更危险。因此需引入 Reranker（重排序模型）对初筛结果精排。

一、文档处理与分块（离线）

解析：Apache Tika 统一解析 PDF/Word/HTML，提取纯文本与元数据（标题、页码、作者）。

分块策略（按文档类型差异化）：长文本用递归字符分块（chunkSize=500, overlap=50）；表格用行级分块保留结构；代码按函数/类分块。分块时保留元数据（docId, chunkIndex, source）用于溯源。

二、Embedding 与向量存储

Embedding 模型选 BGE-large-zh-v1.5（中文效果好，1024 维，开源可私有化部署）。50 万文档约 300 万 chunk，全量 Embedding 用批量接口（batch=64）并行处理，耗时约 4 小时。向量存入 Milvus，创建 HNSW 索引（M=16, efConstruction=256），平衡召回率与查询速度。

三、混合检索与重排序（在线）

用户提问后并行执行：1）向量检索（Milvus topK=20，余弦相似度）；2）BM25 关键词检索（Elasticsearch topK=20）。用 RRF（Reciprocal Rank Fusion）融合两路结果，再用 BGE-reranker 重排序取 top5。

四、上下文组装与生成

将 top5 chunk 按相关度排序拼接，控制总 token < 4000。Prompt 模板：System="基于以下知识回答问题，若知识中无答案请说明'知识库中未找到相关信息'，禁止编造。"[上下文] + [问题]。

五、增量更新

文档变更时通过 CDC（Change Data Capture）或文件监听触发增量 Embedding，按 docId 删除旧向量再插入新向量。Milvus 支持 upsert 操作。

• 如何评估 RAG 系统的检索质量？
  构建评估数据集：人工标注 500 个典型问题及其对应的标准答案文档（ground truth）。检索评估指标：Recall@K（前 K 个结果中是否包含标准答案）、MRR（Mean Reciprocal Rank，标准答案的排名倒数）。生成评估指标： Faithfulness（答案是否忠于检索内容，用 LLM-as-Judge 评估）、Answer Relevancy（答案与问题的相关性）。工具用 RAGAS 或 TruLens 框架自动化评估，定期回归。
• 文档中的表格和图片如何处理？
  表格：解析为 Markdown 表格格式再分块，保留表头作为每个 chunk 的前缀（如"以下是XX表的第N行"），确保每个 chunk 自包含可理解。图片：用多模态模型（GPT-4o）生成图片描述文本再 Embedding；或用 OCR 提取文字。表格+图片混合内容：抽取结构化数据存 PostgreSQL，向量索引指向结构化记录，检索时 join 查询返回完整信息。
• Query 改写为什么重要？怎么实现？
  用户提问往往口语化、模糊或包含指代（"那个流程的第三步是什么"），直接检索效果差。改写策略：1）指代消解——结合对话历史补全指代对象；2）同义扩展——"退货"扩展为"退货 退款 售后 返回商品"；3）Query 分解——复杂问题拆为多个子问题分别检索。实现用小模型（GPT-4o-mini）做 Query 改写，prompt 指示"将用户问题改写为更适合检索的关键词形式"。
• Milvus 和 Elasticsearch 向量检索如何选型？
  Milvus：专为向量设计，HNSW/IVF 索引性能优，支持十亿级向量，但运维复杂。Elasticsearch 8.x：支持 kNN 向量检索（HNSW），同时支持 BM25 关键词检索，可在一个引擎内做混合检索减少架构复杂度。选型建议：文档量 < 100 万且需混合检索选 ES；纯向量检索且规模大选 Milvus；中小规模且团队熟悉 ES 选 ES 8.x，避免引入新组件。

• 分块大小一刀切：所有文档用相同的 500 字符分块，导致表格被截断、代码被切碎。必须按文档类型差异化分块，表格用行级、代码用函数级、长文用递归分块带 overlap。
• 只做向量检索忽略关键词检索：纯向量检索对专有名词、编号、代码召回率低。如查询"ISO-27001 认证"，向量可能召回"信息安全管理体系"但不命中"ISO-27001"精确匹配。必须用 BM25 + 向量混合检索，RRF 融合。
• 上下文组装未做去重和截断：检索到的多个 chunk 内容重叠，组装后上下文冗余且超 token 限制。需按相似度去重（Jaccard > 0.8 视为重复），按 token 数截断保留 top-K，优先放相关度高的。
• 忽略 LLM 幻觉防护：Prompt 中未明确要求"无答案时说明"，LLM 可能基于检索内容部分编造。Prompt 必须包含"若资料中没有答案请说明'知识库中未找到'"，并设置 temperature=0 降低随机性。

某物流平台将 20 个 SpringBoot 微服务从传统 VM 部署迁移到 Kubernetes 集群（3 Master + 10 Worker，每节点 16核64G）。服务规模：日均订单 800 万，峰值 QPS 12000，核心服务（订单/调度/计费）要求 99.95% 可用性。迁移痛点：1）JVM 堆内存设 4G 但容器 limit 6G，偶发 OOMKilled；2）Pod 启动慢（60 秒）被 Liveness 探针杀掉循环重启；3）大促流量突增时 HPA 扩容不及时导致请求堆积；4）多环境配置（dev/staging/prod）管理混乱。

1）JVM 与容器内存协调——JVM 不感知 cgroup limit 导致 OOMKilled，需正确配置容器感知参数；2）探针配置不当——启动慢被 Liveness 杀、假活被 Readiness 放行；3）HPA 弹性滞后——CPU 阈值触发到 Pod Ready 需 2-3 分钟，突发流量来不及扩容；4）优雅上下线——Pod 缩容时正在处理的请求被中断，需 graceful shutdown；5）配置与密钥管理——数据库密码、API Key 不能打进镜像，需 ConfigMap + Secret 动态注入。

遵循 "容器适配 → 健康保障 → 弹性伸缩 → 配置外置" 四层设计。容器适配层：JVM 参数容器化（-XX:+UseContainerSupport，JDK 8u191+ 默认开启，-XX:MaxRAMPercentage=75.0 让 JVM 按容器 limit 自动算堆大小）。健康保障层：Startup Probe（慢启动保护，failureThreshold * periodSeconds 覆盖启动时间）、Liveness Probe（存活检测，失败重启）、Readiness Probe（就绪检测，失败摘流）。弹性伸缩层：HPA 基于 CPU/内存/自定义指标（QPS）自动扩缩容，配合 Cluster Autoscaler 自动加节点。配置外置层：ConfigMap 存非敏感配置，Secret 存密钥，配合 Spring Cloud Kubernetes 或外部配置中心（Nacos）动态刷新。

一、Docker 镜像优化

基础镜像用 eclipse-temurin:21-jre-alpine（~180MB，比完整 Debian 镜像小 70%）。多阶段构建：第一阶段 Maven 编译，第二阶段只拷贝 jar 到 JRE 镜像。镜像分层优化：依赖 jar 与应用 jar 分层 COPY，利用 Docker 缓存加速构建。

二、JVM 容器化参数

-XX:+UseContainerSupport（默认开启）-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0。留 25% 给非堆内存（Metaspace、线程栈、Direct Memory）。避免 -Xms -Xmx 硬编码，让 JVM 按容器 limit 自适应。

三、探针配置（三探针分离）

Startup Probe：httpGet /actuator/health/liveness，periodSeconds=10, failureThreshold=12（最多等 120 秒启动）。Liveness Probe：/actuator/health/liveness，periodSeconds=10, failureThreshold=3。Readiness Probe：/actuator/health/readiness，periodSeconds=5, failureThreshold=3。

四、HPA 弹性伸缩

基于 CPU（阈值 70%）+ 自定义指标（QPS，每 Pod 承载 2000 QPS）。minReplicas=3（保证高可用），maxReplicas=20。配合 PodPreset 设置 priorityClass 保证核心服务优先调度。预扩容：大促前定时 HPA 或手动 scale 提前扩容。

五、优雅上下线

下线：Pod 收到 SIGTERM → Spring Boot graceful shutdown（server.shutdown=graceful, timeout=30s）→ Readiness 失效摘流 → 处理完在途请求 → 退出。上线：Readiness 通过后 K8s Endpoint 更新，流量渐进接入。

• 容器 OOMKilled 和 JVM OOM 有什么区别？如何区分？
  JVM OOM 是堆内内存不足，抛 OutOfMemoryError，进程可能存活（取决于 -XX:+ExitOnOutOfMemoryError 配置）。OOMKilled 是容器内存超 cgroup limit 被内核 OOM Killer 杀死（exit code 137），JVM 来不及抛异常。区分方式：kubectl describe pod 看 Last State 的 Reason，OOMKilled 显示 "OOMKilled"；JVM OOM 在应用日志有 java.lang.OutOfMemoryError。解决：OOMKilled 调大容器 limit 或调小 -XX:MaxRAMPercentage；JVM OOM 排查内存泄漏。
• HPA 扩容滞后怎么解决？
  三管齐下：1）缩短扩容触发周期——HPA 默认 15 秒采样，可调 --horizontal-pod-autoscaler-sync-period=10s；2）预扩容——大促前定时 CronJob 手动 scale 或调整 minReplicas；3）预测式扩容——基于历史流量曲线用 KEDA 或自定义预测算法提前扩容。缩容需保守：默认缩容稳定窗口 5 分钟（--horizontal-pod-autoscaler-downscale-stabilization），避免流量波动导致频繁缩扩。
• 如何实现 Pod 的优雅下线不丢请求？
  完整链路：K8s 删除 Pod → 发送 SIGTERM → 同时从 Endpoints 摘除（有 ~5 秒传播延迟）→ preStop hook 执行 sleep 15 等待 Endpoints 更新 → Spring Boot graceful shutdown 处理在途请求（server.shutdown=graceful, spring.lifecycle.timeout-per-shutdown-phase=30s）→ 关闭。关键：preStop 的 sleep 时间要大于 Endpoints 传播延迟（kube-proxy/iptables 更新），否则 SIGTERM 后还有新请求进来但 Pod 已关闭接收。
• Java 21 在容器中有什么特殊优化？
  1）容器感知默认开启（-XX:+UseContainerSupport），JVM 自动按 cgroup limit 设置 MaxHeapSize；2）G1 GC 在容器环境表现优，Java 21 G1 支持 NUMA 感知；3）虚拟线程在容器中更友好——高并发下线程数不爆炸，Pod 内存可控；4）-XX:+UseStringDeduplication 减少字符串内存占用，适合内存受限的容器；5）CRaC（Coordinated Restore at Checkpoint）是 OpenJDK 项目/支持该机制的发行版能力（非 JDK 21 标准能力），可实现 Pod 秒级冷启动，需验证连接池与句柄的 restore 钩子。

• JVM 堆内存硬编码超过容器 limit：-Xmx4g 但容器 memory limit=4Gi，JVM 非堆内存（Metaspace、线程栈、Direct Buffer）无处安放，被 OOMKilled。正确做法：用 -XX:MaxRAMPercentage=75.0，留 25% 给非堆内存，不硬编码 -Xmx。
• Liveness 和 Readiness 用同一个端点：应用启动慢时 Liveness 检测失败导致 Pod 被杀循环重启。必须分离：Startup Probe 专门覆盖启动期（failureThreshold 大），Liveness 检测运行时存活，Readiness 检测是否能接流量。Spring Boot Actuator 分离 health/liveness 和 health/readiness 端点。
• 没有配置 preStop 导致请求丢失：Pod 收到 SIGTERM 立即关闭，但 K8s Endpoints 更新有延迟，期间仍有新请求路由到已关闭的 Pod。必须配 preStop: exec sleep 15，等待 Endpoints 摘除后再关闭。
• resources 只设 limits 不设 requests：不设 requests 时默认等于 limits，导致调度器认为 Pod 需要 4G 内存，节点资源利用率低。requests 是调度依据，limits 是上限。建议 requests=limits*0.5，提高节点装箱率。

某企业需构建内部知识库问答系统，涵盖 1000 万份技术文档、产品手册、会议记录。要求支持语义搜索（而非关键词匹配），并与大模型结合实现 RAG（检索增强生成），回答准确率 > 85%，响应延迟 < 2s。

① 文档切分：长文档如何切分为合适的 chunk，既保留上下文又控制向量长度；② Embedding 模型选择：通用模型 vs 领域微调模型的效果差异；③ 混合检索：向量相似度与关键词 BM25 如何融合；④ 结果重排序：向量召回的 TopK 不一定最相关，如何精排；⑤ 大模型幻觉：即使检索到相关内容，模型仍可能编造答案。

采用"Embedding + 向量索引 + 混合检索 + Rerank + LLM"的五层 RAG 架构：文档经 NLP 切分后送入 BGE Embedding 模型编码；向量存入 Milvus 构建 HNSW 索引；查询时并行执行向量检索（Milvus）和关键词检索（ES），结果融合后通过 Cross-Encoder 重排序；最终取 Top5 片段作为上下文送入大模型生成答案。

1. 文档切分策略：按段落切分（chunk_size=512, overlap=128），保留段落间语义连贯；对表格和代码块采用特殊切分规则（不跨表格切分）；为每个 chunk 附加文档标题和章节路径作为上下文。

2. Embedding 与向量存储：使用 BGE-large-zh 模型生成 1024 维向量；Milvus 创建 HNSW 索引（M=16, efConstruction=200），单集合支持 1000 万向量，查询延迟 < 50ms。

3. 混合检索：向量检索（Milvus，TopK=50）捕获语义相似性；关键词检索（ES，BM25，TopK=50）捕获精确匹配；使用 RRF（Reciprocal Rank Fusion）算法融合两个列表，综合排序。

4. 重排序与生成：融合后的 Top 20 结果送入 Cross-Encoder（如 bge-reranker）精排，取 Top 5 作为上下文；Prompt 采用"基于以下参考资料回答问题，若资料不足请回答不知道"的约束模板，降低幻觉。

• 追问1：Chunk 大小如何选择？过大或过小有什么影响？
  过大：包含多个主题，噪声增加，向量表示模糊；过小：丢失上下文，如"该技术"指代不明。建议 256-512 tokens，配合 20% overlap。
• 追问2：HNSW 的 M 和 efConstruction 参数如何调优？
  M 控制图连通度，越大召回率越高但内存占用越大（M=16 适合百万级，M=32 适合千万级）；efConstruction 越大索引质量越高但构建时间越长。建议根据数据量和延迟要求权衡。
• 追问3：RAG 中模型仍出现幻觉，如何进一步降低？
  一是增加约束 Prompt（如"仅基于参考资料回答"）；二是降低 temperature（0.1-0.3）；三是增加检索片段数（Top 5 -> Top 10）；四是引入答案与原文的相似度校验，低于阈值时拒绝回答。

• 仅用向量检索忽略关键词匹配：向量检索对专有名词和型号（如"iPhone 15 Pro Max"）效果差，必须结合 BM25 关键词检索做混合搜索。
• Embedding 模型与业务领域不匹配：通用模型对医疗、法律等专业术语理解不足。应在领域数据上微调 Embedding 模型（如 BGE fine-tune），或选用领域专用模型。
• 未做检索结果去重和冲突处理：多个检索片段可能矛盾（如不同版本的文档）。需在 Prompt 中显式标注来源版本，或加入冲突检测逻辑。

某交易中台 80+ 微服务仍在 Spring Boot 3.3.x / JDK 21。平台要求 2026 Q2 前完成 Spring Boot 4.0.0（2025-11-20 GA） 升级，并满足 K8s 滚动发布时 P95 就绪时间 < 8s（含探针）。部分核心链路已用虚拟线程；另有一批批处理服务冷启动 25s+，希望叠加 Leyden/CDS/AOT 压启动。要求给出迁移波次、兼容性矩阵、回滚与启动 SLO 验收。

① Boot 4 依赖与第三方 Starter 兼容窗口不一；② 测试金字塔（单测/Testcontainers/契约）须防「编译过、运行炸」；③ Native/AOT 与 Leyden/CDS 手段叠加时诊断变难；④ 启动 SLO 与功能回归抢同一发布窗口；⑤ 灰度与一键回滚必须可操作。

采用「基线锁定 → 波次升级 → 双轨验证 → 启动专项 → 灰度回滚」：先锁 JDK 与 Boot BOM；按风险波次（工具链 → 边缘服务 → 核心）；功能用 C06.14 测试策略；启动用 CDS/Leyden/AOT 分档（见 C06.13、C01.12）；发布用金丝雀 + 快速回滚包。

1. 基线：统一 Boot 4 BOM + 兼容 JDK（以团队认证矩阵为准，优先 21 LTS，评估 25）；第三方依赖建「红/黄/绿」清单，红灯阻断合入。

2. 波次：① 构建插件/父 POM；② 无流量/内部工具；③ 读写分离的边缘 API；④ 核心交易。每波保留 Boot 3 镜像 tag 可秒级回滚。

3. 回归矩阵：单测 + Testcontainers 关键路径 + 契约测试（消费方驱动）+ 冒烟拓扑；禁止只靠人工点点点。

4. 启动 SLO：基线测量（classload/Bean 初始化分段）；CDS 归档预热 → 评估 Leyden 训练（JEP 线以当前 JDK 为准）→ 仍不达标再上 AOT/Native 子集。目标：P95 < 8s Ready。

5. 发布：金丝雀 5%→20%→100%；观察错误率、P99、Ready 时长、pinning（若 VT）；失败自动回滚上一镜像。

• Boot 4 与 Boot 3 能否同集群混部？
  可以按服务混部，但同一服务双版本要用兼容 API/契约；共享库（序列化/消息 schema）必须向后兼容一个窗口。
• 启动变快但首次请求很慢怎么办？
  区分 Ready 与「业务预热」。探针通过后可再跑预热流量（缓存/连接池/JIT）；Leyden/CDS 主要帮 classload，不替代业务预热。
• 迁移期如何控制风险？
  特性开关 + 数据面兼容 + 镜像回滚；数据库 schema 变更仍走 Expand-Contract，不与框架大版本绑死同发。

• 把 Boot 4 仍写成「计划中」：4.0.0 已于 2025-11-20 GA，沟通与文档须更新（见 C06.13）。
• 只升父 POM 不跑契约：编译绿、运行期 Starter 冲突才爆。
• 启动优化与功能变更同列车：问题难归因；启动专项独立变更集。
• Native 一刀切：反射/动态代理重的服务先 CDS/Leyden，再评估 Native。

某头部电商平台日活用户 5000 万，日均订单量 3000 万单，双11 大促峰值下单 QPS 达 15 万，支付峰值 QPS 8 万。系统由商品、库存、订单、支付、营销（优惠券/满减）、物流、通知、积分等 20+ 微服务组成。核心指标要求：下单接口 P99 RT < 200ms，支付成功率 > 99.99%，库存超卖率 < 0.001%，全链路数据最终一致（对账差异 < 0.01%）。秒杀场景下热点 SKU 单品 QPS 可达 5 万，库存仅 1000 件，需在 10 秒内售罄且零超卖。

1. 高并发扣减热点库存的原子性与超卖防控，单 SKU 5 万 QPS 下 MySQL 行锁必然雪崩；2. 下单跨订单/库存/优惠券多服务的分布式事务一致性，核心链路不能强一致阻塞；3. 支付回调的幂等与超时补偿（支付通道回调可能重复/延迟/丢失）；4. 双11 零点洪峰的削峰填谷，DB 承载能力远低于入口 QPS；5. 全链路追踪与级联失败防控，任一服务不可用不能拖垮整条链路；6. 物流/积分等非核心链路的异步解耦与最终一致。

基于 CAP 与 BASE 理论权衡：核心交易链路（下单+扣库存）选择 CP 倾向的强一致预扣，非核心链路（物流/积分/通知）选择 AP 的最终一致异步化。分层架构：接入层（限流/路由）→ 应用层（业务编排）→ 数据层（存储/缓存）。关键设计原则：①同步最小化——只把"必须同步"的扣库存留在主链路，其余异步化；②幂等优先——所有外部入口（下单/支付回调）幂等；③补偿兜底——Saga + 本地消息表 + 定时对账三重保障；④削峰填谷——MQ 削峰 + 异步落库；⑤隔离熔断——Sentinel 限流熔断防级联失败。库存扣减采用"Redis 预扣 + 异步落库 + 兜底校验"三段式。

接入层：CDN 承接静态资源，Nginx + Spring Cloud Gateway 做流量入口，Sentinel 滑动窗口限流（下单接口单机 5000 QPS，超出快速失败），网关层做租户/UA 维度黑白名单与防刷（令牌桶 10 QPS/用户）。WAF 拦截恶意爬虫与刷单。同城双活单元化部署，按 uid 路由到对应单元，单元内自包含。

应用层：订单服务集群 200+ 实例，库存服务独立部署（物理隔离避免相互影响）。库存预扣走 Redis Cluster（Lua 原子脚本），订单创建走 RocketMQ 异步落库（消费者批量入库）。下单主链路：网关→订单服务→Redis 预扣库存→生成订单号→返回待支付，全程 < 50ms。支付成功后通过 MQ 驱动库存确认扣减、物流发货、积分发放。二级缓存：Caffeine 本地缓存（商品/用户基础信息）+ Redis 分布式缓存，命中率 > 95%。

数据层：MySQL 订单表按 user_id 分 1024 库 × 4 表，库存表按 sku_id 分库。Redis Cluster 16 分片存预扣库存。Elasticsearch 承担订单搜索。TiDB 兜底对账与历史数据归档。binlog 通过 Canal 同步到 ES 与数仓。

容灾方案：同城双活（A/B 机房各承载 50%，故障切换 RTO < 1min）+ 异地灾备（异步复制）。Redis 预扣失败降级为 DB 限流扣减（牺牲性能保一致）。MQ 集群三节点同步刷盘，宕机自动主从切换。全链路 Sentry + SkyWalking 监控，故障自愈（Resilience4j 熔断，Hystrix 已停止维护仅作演进对比）。

• 双11 零点洪峰 15 万 QPS，如何保证下单既不超卖又不超时？
  前置削峰：活动页静态化 + 答题/验证码错峰 + 预约排队令牌。库存预扣全走 Redis（Lua 原子，单实例 8 万 QPS），分片打散热点 SKU。订单异步落库（MQ 削峰，消费者按 DB 承载限速）。网关层 Sentinel 集群限流，超出快速失败引导重试。压测确认容量，预留 30% buffer。
• 支付服务整体宕机，已生成的待支付订单如何处理？
  订单保留待支付状态（设置 30min 超时）。降级方案：切换备用支付通道（多通道冗余）。超时未支付订单由定时任务扫描后执行库存回滚（释放 Redis 预扣 + MQ 驱动库存服务回滚 DB）。需保证回滚幂等，并通过本地消息表保证回滚消息必达。
• 跨服务数据不一致（如订单成功但库存未确认）如何发现与修复？
  三重保障：①实时对账——支付成功消息消费失败重试 + 死信告警；②准实时对账——Flink 实时比对订单/库存/支付三流，差异 > 阈值告警；③离线全量对账——T+1 跑全表核对，产出差异单人工/自动补偿。修复走 Saga 补偿事务，先核对状态机再决定正向补推或反向回滚。
• 如何设计库存回滚补偿，避免重复回滚或漏回滚？
  库存操作全部带订单号幂等键，回滚前先查状态机（已扣减→可回滚，已回滚→直接返回成功）。回滚动作 = Redis incr + DB update，二者通过事务消息保证最终一致。补偿任务定时扫描"超时未支付"订单触发回滚，并记录补偿日志便于审计。极端情况下提供人工干预入口（带审批流）。
• 大促前如何做容量评估与全链路压测，避免压垮生产？
  基于历史峰值倍数（双11≈日常 20 倍）预估各服务容量。全链路压测用影子库表 + 影子流量（标记压测流量隔离存储），从网关压到 DB。分阶梯加压，识别瓶颈点（DB 连接池/Redis 热点/MQ 堆积）。容量公式：所需实例数 = 峰值QPS / 单机容量 × 安全系数(1.5)。压测后产出容量水位与扩容预案。

• 库存扣减用 MySQL 行锁：高并发下热点行锁等待导致 RT 飙升雪崩。应改为 Redis 预扣 + 异步落库，DB 只做最终确认与对账。
• 支付回调未做幂等：支付通道可能重复回调，导致重复发货/重复发券。必须以支付单号为幂等键，前置 Redis 去重 + DB 唯一索引双保险。
• 消息队列消费失败直接丢弃：MQ 消费失败未重试或重试次数耗尽未进死信队列，导致数据丢失。必须配置重试 + 死信 + 人工补偿兜底。
• 分布式事务强求全局强一致却误用 Seata AT：下单全链路用 Seata AT 全局锁（AT 本质为最终一致，全局锁仅防脏写，无法提供线性强一致），高并发下性能崩溃。应区分核心/非核心链路，核心用 TCC/Saga，非核心用本地消息表最终一致。
• 限流只在网关单层配置：网关被绕过或单点故障则全盘失守。应多层限流：网关（集群）+ 应用（单机）+ 数据层（连接池/DB 限流），形成纵深防御。

某互联网银行风控系统承载反欺诈（交易实时拦截）、信用评分（授信决策）、反洗钱（AML）三大场景。日均交易 1.2 亿笔，贷款申请日均 50 万笔，大促/月末峰值交易 QPS 10 万。严格要求：在线风控决策端到端延迟 P99 < 100ms（否则阻断正常交易体验），欺诈误杀率 < 0.1%（避免误伤正常用户），欺诈漏报率 < 0.01%。数据源：用户画像（10 亿+标签）、设备指纹、交易流水（近 2 年）、关系图谱（5 亿节点/80 亿边）、外部黑名单（公安/征信/同业共享）。黑产对抗激烈，规则需以"天"为周期迭代。

1. 实时特征计算的多维多窗口聚合（近 1min/5min/1h/1d 的金额/频次/设备数等），延迟敏感；2. 规则引擎与 ML 模型的混合决策与冲突仲裁，规则要热更新不停机；3. 流批一体的特征口径一致性（离线训练与在线推理特征必须同源同口径，否则模型失效）；4. 100ms 内完成"特征获取+规则+模型+图谱查询"全链路，任一环节抖动即超时；5. 团伙欺诈识别需实时图查询（多跳邻居），传统图库查询耗时难达标；6. 模型可解释性（监管要求给出拒贷理由）。

架构选型采用 Kappa 流批一体（避免 Lambda 两套代码口径漂移），Flink 既做实时特征计算又做回溯重算。特征分层：实时特征（Flink 窗口聚合写 Redis，毫秒级）、近线特征（HBase 明细，秒级）、离线特征（Hive/Spark 批算，T+1）。决策编排采用"规则优先 + 模型并行 + 仲裁合并"模式：黑名单/限频等强规则命中直接拦截（毫秒级短路），复杂规则与模型并行计算，最终仲裁器合并决策。延迟控制采用 CompletableFuture 并行 + 超时降级（实时特征不可用降级离线特征，图谱超时跳过）。流处理 exactly-once 保证特征不重复。模型推理走 TF Serving/ONNX Runtime，特征入参通过特征平台统一服务化，杜绝口径分裂。

接入层：交易系统通过 API 网关调用风控前置服务，前置层做黑名单/限频/设备指纹快筛（Redis 命中即拦截，耗时 < 5ms），过滤 70% 明显欺诈。Kafka 接入全量交易事件流（保留 7 天用于特征回溯），分区按 uid 哈希保证同用户顺序。

应用层：决策引擎（自研 DSL + Drools 混合）编排规则与模型，规则支持热更新（配置中心推送，无需重启）。特征服务统一封装实时/近线/离线特征获取。Flink 集群（200 TM）实时计算滑窗聚合特征写入 Redis（TTL 24h）。模型推理服务（TF Serving GPU 集群）加载 XGBoost/深度模型，单次推理 < 20ms。关系图谱查询走 JanusGraph + HBase 后端，2 跳邻居查询 < 30ms（预计算热点子图缓存）。

数据层：HBase 存明细特征（按 uid+时间 rowkey），Redis Cluster 存实时聚合特征（命中率 > 95%），JanusGraph 存关系图谱，Hive/Spark 离线训练模型（每日产出新模型版本）。特征平台统一管理特征元数据（口径/版本/血缘），杜绝流批口径分裂。

容灾方案：决策服务多机房双活（A/B 各 50%），特征服务降级链：实时特征不可用→降级近线→降级离线→降级默认值。规则引擎熔断（模型超时跳过，仅用规则决策）。Flink Checkpoint 持久化到 HDFS，故障自动从最近 checkpoint 恢复。极端情况下风控"失败开放"（fail-open 放行交易 + 事后离线复核）或"失败关闭"（fail-close 拦截），按业务场景配置（大额 fail-close，小额 fail-open）。

• Flink 实时特征计算出现延迟抖动（如背压导致窗口延迟），如何保证风控决策时效？
  分层兜底：实时特征缓存到 Redis，决策时优先读缓存（容忍秒级延迟）；特征服务超时降级到近线/离线特征；关键特征配置 SLA 监控，背压告警自动扩容 Flink TM。极端延迟时切流到备链路（离线特征兜底决策），事后补跑实时特征修正。
• 新模型上线如何灰度发布与快速回滚，避免影响线上决策？
  影子流量验证：先让新模型接收线上流量旁路计算，对比老模型输出差异。灰度发布按 uid/地域分桶（如 1%→10%→100%），监控误杀率/漏报率指标。模型版本管理（Feature Store + Model Registry），一键回滚到上一版本。A/B 测试平台评估业务指标，回滚阈值自动化触发。
• 关系图谱多跳查询耗时 > 100ms，如何优化团伙欺诈识别？
  预计算热点子图：离线 Spark 计算高风险节点 2-3 跳邻居缓存到 Redis/JanusGraph 缓存层。查询走预计算结果而非实时遍历。图分区优化（按 uid 哈希分区减少跨分片）。对超大规模图用 GraphX/GraphScope 做离线社区发现，实时只查预标记团伙标签。引入向量化图检索加速。
• 规则与模型决策冲突（规则放行但模型判高风险）如何仲裁？
  定义仲裁策略：强规则（黑名单/限额）一票否决；普通规则与模型冲突时按业务场景配置——大额交易取严（任一高风险即拦截），小额取宽（模型分超阈值才拦截）。冲突案例入人工审核队列积累样本，定期复盘调整仲裁阈值。保留决策日志便于追溯与模型迭代。
• 黑产对抗升级（如更换设备/养号绕过规则），如何快速响应？
  规则引擎热更新（DSL 配置化，无需发版，分钟级生效）。建立攻防演练机制，安全团队每日分析新攻击模式快速上线对抗规则。模型周级迭代（自动特征工程 + 在线学习）。引入无监督学习（异常检测）发现未知攻击。与同业共享黑名单情报，前置拦截。

• 实时与离线特征口径不一致：Flink 实时算的"近1小时交易次数"与 Spark 离线算的口径不同（窗口边界/去重逻辑），导致模型训练与推理特征漂移。必须由特征平台统一管理口径，流批同源代码生成。
• 规则引擎硬编码：规则写死在 Java 代码里，每次调整需发版，无法应对快速变化。应采用 Drools/自研 DSL 配置化，支持热更新与版本回滚。
• 模型决策黑盒无解释性：深度模型直接输出拒绝，无法满足监管"告知拒贷理由"要求。需引入 SHAP/LIME 可解释性工具，或用规则代理模型生成解释。
• 特征服务单点无降级：特征服务故障导致整个风控链路超时雪崩。必须设计降级链（实时→近线→离线→默认值），并对超时做熔断隔离。
• 流处理 exactly-once 未保证：Flink 未正确配置 Checkpoint + 两阶段提交，特征重复累加导致误判。需开启 exactly-once，Kafka 事务写入，幂等 sink。

某社交直播平台同时在线用户 1500 万，日均推送消息量 30 亿条，主播开播/热门事件触发峰值推送 QPS 100 万，群消息单群成员可达 10 万。要求推送到达率 > 99%，在线消息端到端延迟 P99 < 1s，支持 App（iOS/Android）、Web、小程序多端。用户离线时需走厂商通道（APNs/FCM/华为/小米/OPPO/vivo）离线推送，离线消息保留 7 天可补拉。消息类型含 IM 私聊、群消息（有序）、系统通知、营销推送（限频防扰）。

1. 千万级 TCP 长连接的接入与保活，单机连接数上限与内存/线程瓶颈；2. 连接路由——用户分布在数百台接入机，发消息时需定位用户所在节点；3. 群消息扇出（10 万成员群）的扇出风暴与带宽爆炸；4. 峰值百万 QPS 的背压控制，防止推送系统反压上游；5. 离线消息存储与多端同步（按序号递增，不丢不重）；6. 多厂商通道的统一适配、回执与限频配额管理。

分层架构：接入层（长连接网关）→ 路由层（uid→节点映射）→ 逻辑层（消息存储/同步）→ 分发层（MQ 削峰 + 推送 Worker）→ 通道层（在线推/离线推适配）。核心设计原则：①推拉结合——在线用户走推送，离线用户消息落库 + 厂商通道通知，上线后拉取增量；②分层背压——每层限流，MQ 削峰隔离上下游；③连接路由用 Redis 存 uid→connId 映射，跨节点消息走 MQ 点对点而非全量广播；④群消息用"写扩散+读扩散"混合（小群写扩散，大群读扩散）；⑤消息序号机制保证多端有序与去重。容灾上接入节点无状态，客户端自动重连迁移。

接入层：Netty WebSocket 长连接网关集群（500 节点），单机承载 5 万连接（堆外内存 + Epoll），LVS/F5 四层负载 + 一致性哈希分片（uid 哈希到固定节点，减少路由漂移）。心跳保活：客户端 30s 心跳，服务端 90s 无心跳断开。连接迁移：节点宕机客户端指数退避重连，路由表自动更新。

路由层：Redis Cluster 存 uid→接入节点映射（route:uid → nodeId），TTL 5min（心跳续期）。跨节点消息：发送方查询目标 uid 所在节点，将推送任务投到目标节点的 MQ 队列（push.node.{nodeId}），目标节点消费后本地直推，避免全量广播。群消息：先查群成员在线分布，按节点聚合批量投递（减少 RPC 次数）。

应用层：RocketMQ 承接推送任务（topic 按消息类型分），推送 Worker 消费分发。令牌桶限流背压（单 Worker 1万 QPS），消费不过载则反压上游。营销推送单独 topic + 全局频控（用户日限 3 条）。消息存储：在线消息走 Redis（最近 100 条），全量消息走 HBase（按 uid+时间 rowkey，7 天 TTL）。

数据层：HBase 存离线消息（按 uid 分区），Redis 存在线消息热数据与路由表，MySQL 存推送回执与配额。多端同步基于递增序号（sequence），客户端上报已收最大序号，服务端按序号差量推送。

容灾方案：接入节点宕机客户端自动重连（路由表 5s 内更新）。推送降级：在线推失败（3 次）转离线厂商推送。MQ 集群三节点，单节点故障自动转移。多厂商通道互备（主推 APNs 失败转 FCM）。全链路监控推送到达率，低于阈值告警。

• 单机要支撑 10 万长连接，如何优化 Netty 的内存与线程模型？
  用 Epoll 原生 transport 替代 NIO，零拷贝 + 边缘触发。堆外内存（DirectByteBuffer）存连接缓冲区，避免 GC 压力。EventLoop 数 = CPU 核数 × 2，单线程串行处理多连接。连接对象轻量化（< 1KB），用 Netty 对象池复用。调优 SO_BACKLOG、TCP_NODELAY、写缓冲水位高低水位线。JVM 堆外内存监控防泄漏。
• 10 万人群消息的扇出风暴如何控制，避免带宽与 DB 瞬时打满？
  大群用读扩散（消息写一份到群信箱，成员拉取），小群用写扩散（直接写各成员收件箱）。分批异步投递：群消息按成员分片，MQ 削峰分批消费，控制并发。在线成员优先推、离线成员落库不推。设置群消息速率限制（如单群 10 条/秒）。监控扇出队列堆积，超阈值降级（合并通知）。
• 网络抖动导致大量客户端同时重连（惊群效应），如何应对？
  客户端指数退避 + 随机抖动（避免同步重连）。服务端接入层做重连限流（令牌桶），超出快速失败让客户端继续退避。网关层动态扩容应对重连洪峰。路由表更新异步化，避免重连风暴打爆 Redis。可设"重连冷却"——同一 uid 短时多次重连只保留最新连接。
• 离线用户消息堆积（如 7 天未上线累积上万条），上线拉取如何不拖垮系统？
  分页拉取 + 按序号增量同步，单次返回 100 条，客户端按需翻页。热数据走 Redis，冷数据走 HBase 分区扫描。拉取请求限流（单用户 QPS 限制）。大消息体（图片/视频）只推 URL，客户端按需下载。超期消息（>7 天）归档冷存储，不参与同步。
• 多厂商推送通道（APNs/FCM/厂商）限频各不相同，如何做配额管理？
  抽象统一 PushAdapter，各厂商实现适配。配额中心按厂商/应用维度管理 QPS 限额（Redis 滑窗计数）。超配额消息入延迟队列错峰发送。多通道互备：主通道超限自动切备用通道。回执监控送达率，低质量通道降权。营销推送全局频控（用户日限 3 条），防骚扰投诉。

• 连接路由用全量广播：发消息时向所有接入节点广播查找用户，节点数一多带宽与 CPU 爆炸。应改用 Redis 路由表点对点投递。
• 推送无背压导致雪崩：上游突发流量直接灌满推送 Worker，反压上游或 OOM。必须 MQ 削峰 + 令牌桶限流 + 消费速率可控。
• 离线消息无分页一次性拉取：用户堆积大量消息后上线，一次性拉取打爆网络与内存。必须分页 + 增量序号同步。
• WebSocket 心跳间隔配置不合理：心跳过频浪费带宽与电量（移动端），过疏连接被中间网关断开。移动端建议 30-60s，并配合弱网自适应。
• 多端消息无序号去重：多端并发拉取或重试导致消息乱序/重复。必须全局递增序号 + 客户端已收序号去重。

某核心交易系统因 Oracle 商业成本与扩展性瓶颈，需迁移到 MySQL 分库分表架构。涉及 50 张核心表、8 亿行数据（最大单表 3 亿行），日均写入 2000 万行、查询 5 亿次。业务要求迁移期间零停机（7×24 不间断），切流对用户无感知，且任意时刻可回滚。同时需改造应用代码：SQL 方言差异（Oracle 序列/存储过程/CONNECT BY/ROWNUM → MySQL 自增/程序逻辑）、事务语义（Oracle 读不阻塞 vs MySQL）、分片键路由。迁移窗口 3 个月，涉及 10+ 微服务协同。

1. 全量 + 增量数据同步的一致性，8 亿行全量迁移期间增量不停；2. 双写期间新老库数据校验与冲突处理（写成功/失败不一致）；3. 灰度切流策略与回滚机制——切到一半发现问题如何无损回退；4. SQL 方言差异的兼容（Oracle 特有语法/函数/隐式类型转换）；5. 分片键设计与跨片查询（如按 user_id 分片后按商户号查询）；6. 迁移过程可观测与异常兜底，任何阶段失败不能脏数据。

核心策略：双写 + CDC（变更数据捕获）+ 数据校验 + 灰度切流 + 可回滚。迁移分四阶段：①全量迁移（DataX/sqoop 离线搬历史数据，与增量 binlog 同步并行，通过时间戳位点对齐）；②双写期（应用双写新老库，CDC 同步兜底，影子流量校验）；③灰度切流（按 uid/租户/流量比例逐步切读写到新库，每档观察）；④收尾（停老库写，保留只读回滚能力 N 天）。关键设计：双写开关化（配置中心动态控制），写入策略保证幂等（业务唯一键兜底）；数据校验分实时对账（CDC 流比对）与离线全量比对（内容哈希）；灰度可逆——任一档异常立即回退上一档；分片键选高频查询字段（如 user_id），跨片查询走 ES 异步索引或广播表。回滚预案必须真实演练。

接入层：API 网关按灰度规则路由——按 uid 哈希/请求头/租户 ID 分流（如灰度比例 0%→1%→10%→50%→100%）。流量录制（录制生产流量回放到新库验证）。网关层灰度开关实时下发，无需发版。读流量切换支持单接口灰度（先切非核心读接口，再切写）。

应用层：数据访问层（DAL）封装双写路由，配置中心控制双写开关与读写比例。双写策略：新老库并行写，任一失败记录补偿日志（异步重试 + 告警）。读流量按灰度比例切新库，异常自动降级回老库。影子流量校验——灰度前用录制流量跑新库比对结果。SQL 方言通过 ORM（MyBatis）方言适配 + 代码改造（序列→雪花 ID，存储过程→Java 逻辑，CONNECT BY→递归查询/内存计算）。

数据层：全量迁移用 DataX（并发 50 通道，8 亿行约 12 小时），迁移期间 Canal/OGG 订阅老库 binlog 持续增量同步到新库（秒级延迟）。数据校验：实时对账（CDC 流比对增删改，差异告警）+ 离线全量比对（按主键分片抽样，内容哈希 MD5 比对，覆盖 100%）。分库分表按 user_id 分 64 库 × 16 表，跨片查询字段（如商户号）同步到 ES。

容灾方案：任意阶段可回滚——双写期保留老库写入，切读失败降级回老库；切写阶段保留老库双写 N 天，回滚只需关闭新库读写开关。数据不一致触发告警自动暂停灰度。全量迁移可重跑（幂等覆盖）。灰度切流每档观察 24h，关键指标（错误率/RT/对账差异）达标才进下一档。回滚演练上线前必做一次全流程回滚验证。

• 双写期间老库写入成功但新库写入失败（如新库主键冲突/超时），如何处理？
  记录补偿日志异步重试（幂等写入）。短期失败由补偿任务修复，超过阈值告警人工介入。若是系统性问题（如分片键冲突），暂停灰度排查。关键点：主库（决定业务正确性的库）必须成功，从库失败只记日志不阻断业务，最终通过对账+补偿收敛一致。
• 增量同步有延迟（CDC 落后 10 秒），灰度切流时读到新库旧数据怎么办？
  切流前确认 CDC 延迟 < 阈值（如 1s）才允许切。切流瞬间对延迟内的增量做"追读"——读新库 miss 时回退读老库兜底。分档切流降低风险（先切低频接口）。可设"读延迟保护"——读请求带版本号，新库数据版本低于预期则降级老库。切流后观察对账差异，无差异才全量切。
• 数据校验发现新老库部分数据不一致，如何快速定位与修复？
  分层定位：先比对行数，再按主键抽样比对字段，差异行用全字段 diff。常见原因：CDC 丢消息/双写失败/类型转换丢精度。修复策略：以业务正确库为准（切流前以老库为准，切流后以新库为准），脚本修复差异数据，修复后复校验。建立"差异修复 SOP"，差异量大于阈值暂停切流。
• 灰度切流到 50% 发现严重问题（如新库慢查询导致 RT 飙升），如何快速无损回滚？
  一键回滚开关：配置中心将灰度比例从 50% 调回 0%，读流量立即回老库，写流量回老库主写（新库停止双写或保留只读）。回滚后老库数据是最新（双写期老库一直写），无需数据回退。回滚动作 < 1 分钟生效。回滚后保留新库数据用于问题分析，修复后重新灰度。
• Oracle 的序列、存储过程、CONNECT BY 递归等方言在 MySQL 如何平滑迁移？
  序列→改用雪花 ID/号段模式（Leaf），分布式全局唯一。存储过程→下沉到 Java 业务层，逻辑显式化便于测试与扩展。CONNECT BY 递归→MySQL 8 递归 CTE（WITH RECURSIVE）或程序内递归/内存计算。ROWNUM→改 LIMIT + 程序分页。隐式类型转换→显式声明类型，避免数据漂移。建议先用工具（SQL Rewriter）自动转换，再人工 review 复杂逻辑。

• 双写非幂等导致重复数据：双写重试时主键未做幂等，新库产生重复行。必须用业务唯一键 + DB 唯一索引/ON DUPLICATE KEY UPDATE 保证幂等。
• 切流一刀切无灰度：直接 100% 切到新库，问题爆发无法挽回。必须分档灰度（1%→10%→50%→100%），每档观察指标，可随时回退。
• 数据校验只比对行数不比对内容：行数相同但字段值漂移（精度丢失/字符集乱码）漏检。必须按主键抽样做内容哈希比对，覆盖关键字段。
• 回滚预案未演练：纸面回滚方案上线时不敢执行或执行出错。上线前必须做一次全流程回滚演练，验证回滚时效与数据一致性。
• 时区/字符集/数值精度差异导致数据漂移：Oracle DATE 含秒、MySQL datetime 精度不同；NUMBER→DECIMAL 精度截断；字符集 GBK→UTF8 乱码。迁移前做类型映射矩阵 review，关键字段精度对齐。

某跨境电商平台服务 50+ 国家/地区，支持 20+ 语言，覆盖 B2C 和 B2B 两种模式。每个品牌（租户）可自定义页面、品类、价格策略。要求满足中国 PIPL、欧盟 GDPR、美国 CCPA 等数据合规要求，同时保证全球用户访问延迟 < 200ms。

① 数据驻留：中国用户数据不出境，欧盟数据不出欧；② 租户隔离：SaaS 模式下如何保证租户间数据隔离和性能隔离；③ 全球延迟：用户访问最近数据中心，但订单结算需集中处理；④ 多币种与税务：不同国家币种、税率、促销规则差异；⑤ 合规审计：跨境数据传输需通过安全评估并留痕。

采用"区域化部署 + 逻辑多租户 + 联邦结算"的全球化架构：区域层在亚太、欧洲、北美部署独立 K8s 集群，数据本地化存储；租户层通过 tenant_id 字段做行级隔离，核心表增加租户索引；结算层通过异步消息将区域订单汇聚到中心结算集群；合规层通过数据脱敏和审计日志满足各国法规。

1. 区域化部署：中国（阿里云北京）、欧盟（AWS法兰克福）、北美（AWS us-east-1）各部署独立集群；用户通过 GeoDNS 解析到最近区域，首次注册时绑定区域且不可变更。

2. 多租户隔离：共享数据库模式下所有业务表增加 tenant_id 字段，查询时强制带入 tenant_id；使用 MyBatis 插件自动注入租户条件，防止漏加导致数据泄露；核心租户可申请独立 Schema 或实例。

3. 全球订单流：区域集群处理浏览、加购、下单；支付成功后订单通过 Kafka MirrorMaker 跨区同步到中心结算集群，做统一对账、清分、税务申报；非敏感分析数据经脱敏后汇聚到全球数据湖。

4. 多币种与税务：价格体系以美元为基准，展示时按实时汇率转换；税费计算通过规则引擎（Drools）动态加载各国税率表；促销规则支持租户级自定义，通过配置中心热更新。

5. 合规治理：PII 数据（姓名、地址、电话）在落库前 AES-256 加密；审计日志记录所有数据访问（操作人、租户、时间、IP），日志 Hash 写入区块链防篡改；用户行使"被遗忘权"时触发跨区异步删除任务。

• 追问1：共享数据库模式下，如何防止某个租户的大查询影响其他租户（Noisy Neighbor）？
  一是 SQL 层限制单租户查询的扫描行数（如 MySQL 的 MAX_EXECUTION_TIME 和 sql_safe_updates）；二是为 VIP 租户分配独立只读副本；三是在应用层对按租户聚合的慢查询增加缓存。
• 追问2：跨区域数据同步的延迟对订单状态一致性有什么影响？
  区域间同步通常为异步（秒级延迟），订单状态在区域和中心可能存在短暂不一致。采用"本地优先可用"策略：用户看到的订单状态以区域为准，结算对账以中心为准，差异通过日终对账补偿。
• 追问3：GDPR 要求数据可携带权（Data Portability），如何导出跨系统的用户数据？
  构建数据主体权利编排引擎：通过事件驱动方式并行查询各系统（订单、浏览、客服、物流），聚合为标准化 JSON/CSV；敏感字段脱敏后导出；导出任务异步执行并通过邮件通知用户。

• 租户过滤条件漏加导致数据泄露：任何绕过 MyBatis 直接写 JDBC 或原生 SQL 的地方都可能漏加 tenant_id。应通过代码扫描工具强制检查所有 SQL 是否包含租户条件。
• 硬编码币种和税率：不同国家税率变化频繁（如 VAT 调整），硬编码需重新发版。应使用规则引擎或配置中心动态管理。
• 跨境数据传输未做合规评估：中国数据出境需通过网信办安全评估，欧盟数据传至美国需 SCC 条款。未评估直接传输面临巨额罚款。

某支付平台日交易额过亿，日均交易笔数千万级（峰值 QPS 数万），需保证支付链路最终一致性，T+1 对账准确率 99.99%。链路横跨订单、库存、账户、风控、通道等多个子系统，任一环节失败都可能导致"钱货两失"或"重复扣款"。要求在保证资金绝对安全（防重复支付、防超卖、防透支）的前提下，实现高并发收银与 T+1 全量对账，并支持清结算的 T+0/T+1 灵活选型。

① 支付链路跨服务一致性：创建订单→扣库存→扣余额→记流水需跨多个微服务原子完成；② 异常补偿与幂等：网络超时/重试导致的重复支付、掉单如何兜底；③ 对账系统设计：T+1 全量对账如何在亿级明细中找出差异并自动修复，准确率达 99.99%；④ 清结算架构：商户资金 T+1 结算与渠道 T+0 清算如何衔接；⑤ 资金安全：防重复支付、防超卖、防账户透支，任何一笔都不能错。

采用"分布式事务 + 本地消息表 + 定时对账"的三层保障体系：第一层实时保障用 Saga/TCC 分布式事务保证链路最终一致；第二层可靠投递用本地消息表 + MQ 保证跨服务消息不丢不重；第三层兜底校验用定时对账（全量 + 差异 + 实时三级）发现并修复前两层漏掉的异常。三层叠加实现"宁可慢对账，不可错一分钱"的资金安全底线。

1. 支付链路（Saga 编排式）：用 Saga 编排器顺序执行 CreateOrder→DeductStock→DeductBalance→RecordFlow→NotifyChannel，每步带补偿动作（CancelOrder→RestoreStock→RefundBalance→ReverseFlow）。短事务（如扣余额）用 TCC 强化一致性，长链路用 Saga 保证最终一致。

2. 幂等设计（Token + 分布式锁 + 状态机）：收银台下发一次性 Token，支付请求带 Token 校验防重复提交；Redis 分布式锁防并发重复扣款；订单状态机（INIT→PAYING→PAID→FAILED）用乐观锁 CAS 推进，非法状态转移直接拒绝。

3. 对账系统（三级体系）：① 全量对账——T+1 拉取平台流水与渠道/银行账单逐笔比对；② 差异对账——对全量对账筛出的长款/短款做二次核验；③ 实时对账——支付成功即时与通道回执比对，秒级发现异常。

4. 清结算：日终批处理按商户维度汇总待结算金额，T+1 批量出款；对 VIP 商户走实时清算（T+0），通过垫资账户 + 风控额度控制敞口。

5. 异常处理：补偿队列（本地消息表驱动）自动重试失败步骤，重试耗尽转人工兜底工单，所有资金动作留痕可审计。

• 追问1：支付掉单（用户已付款但订单仍 INIT/PAYING）如何处理？
  掉单根因是支付通道异步回调丢失或本服务宕机。处理三段式：① 主动查询——支付超时（如 30s）后定时任务调用通道"查单接口"主动核对订单状态；② 状态推进——查到已支付则补推状态机至 PAID 并补偿下游，查到未支付则触发关单/退款；③ 兜底对账——T+1 全量对账再核对一遍，确保无遗漏。核心是"不要依赖回调，主动查单兜底"。
• 追问2：对账发现差异后的自动修复流程？
  差异分长款（平台有流水、渠道无）和短款（渠道有、平台无）。流程：① 差异落表进入待处理队列；② 自动核验——拉取通道原始凭证二次比对，排除时间窗、批次切分导致的假差异；③ 确认差异后按类型自动修复——长款触发冲正/挂账，短款触发补单/人工确认；④ 修复后回写对账结果并标记闭环。无法自动修复的转人工工单，所有修复动作可审计可回溯。
• 追问3：清结算 T+0 与 T+1 如何选型？
  T+1 是默认方案：渠道 T+1 清算后商户 T+1 结算，平台零垫资、零敞口，适合中小商户。T+0（实时清算）适合 VIP/大商户的资金周转需求，但平台需垫资，存在渠道违约风险，必须配垫资账户 + 风控额度 + 商户资质审核。选型权衡三要素：商户资金周转诉求、平台垫资成本与风控能力、渠道清算节奏。通常 T+0 限量开放给优质商户，T+1 兜底大众。

• 忽略网络超时导致的重复支付：只防用户重复点击（前端禁用按钮），不防网络超时重试。支付请求超时后客户端重试，服务端若不做幂等就会重复扣款。必须 Token + 状态机 + 分布式锁三重防护。
• 对账只做总账不做明细：只对"平台总额 = 渠道总额"就认为无误，但总账相等不代表每笔一致（可能 A 多 B 少恰好抵消）。必须逐笔明细对账，再辅以总额校验作为快速预筛。
• 幂等只做 Token 不做状态机校验：Token 仅防同一请求重复提交，但回调、查单、重试都可能绕过 Token 携带。状态机 CAS（INIT→PAYING→PAID）才是兜底，非法状态转移一律拒绝，确保一笔订单只会被成功支付一次。

电商交易日均创单 800 万，未支付订单需在 30 分钟后自动关闭并回补库存与优惠券。峰值创单 QPS 2 万，延时任务堆积可达千万级。要求：关单幂等、库存不超卖不丢回补、时钟回拨不误关、可对账可补跑。

① 延时驱动选型（Redis ZSET / MQ 延时 / 时间轮）与精度；② 关单与支付回调竞态；③ 库存回补与优惠券回滚的一致性；④ 分片扫描与执行器扩缩不漏单；⑤ 补跑与对账。

采用"状态机权威 + 延时触发可重复 + 副作用幂等"：订单状态机（CREATED→PAID/CLOSED）用 CAS/乐观锁；延时消息只负责唤醒；关单事务内做库存回补（或本地消息表异步），重复唤醒因状态已终态而空操作。驱动层见 C11.22。

1. 触发：创单时写入 Redis ZSET（score=expireAt）或投递 RocketMQ 延时消息；分钟级精度足够，不必时间轮。

2. 关单：UPDATE orders SET status='CLOSED' WHERE id=? AND status='CREATED'，影响行=0 则退出（已支付或已关闭）。

3. 回补：同事务或 Outbox 发库存回补事件；库存侧按 orderId 幂等。

4. 分片：ZSET 按 hash 分 16/32 槽，多消费者抢槽；扩缩容后补偿扫描近 2 个窗口。

5. 对账：日终比对"应关未关 / 已关未回补"，自动补跑 + 告警。

• 支付回调与关单并发谁赢？
  状态机 CAS：支付成功把 CREATED→PAID；关单只接受 CREATED→CLOSED。两者互斥，后到者失败即安全。
• 时钟回拨导致提前关单？
  expireAt 用业务库写入的绝对时间；扫描用 DB/Redis 服务端时间；检测到回拨则暂停自动关并告警。

• 先删 ZSET 再关单：进程崩溃会漏关；应先关单成功再清理触发器，或依赖幂等可重复触发。
• 回补无幂等：重复关单导致库存多回。库存流水按 orderId 唯一。
• 单 ZSET 热点：千万成员集中一个 key，改分片。