第十部分：大型企业系统综合架构设计（第 86～100 题）
「第四阶段专家级系统设计」。聚焦千万级用户、百万 QPS、金融级、全球多活、超大规模系统的端到端架构设计。每题需给出：业务规模→顶层架构→关键技术决策→数据/一致性→高可用/容灾→成本与演进。
第 86 题：千万用户电商平台端到端架构 电商
- 1. 顶层分层？2. 流量怎么收敛到 DB？3. 订单/库存/支付怎么协同？4. 数据规模怎么分？5. 大促怎么保？
第一步：分析。电商=「读多写少 + 峰值尖刺」，核心是分层削峰 + 缓存 + 异步 + 分库分表。
第二步：核心挑战。50 万 QPS 峰值、1 亿 SKU 查询、3000 万订单写、跨域一致。
第三步：整体架构。接入层（CDN/WAF/Gateway 限流）→ 应用层（商品/订单/库存/营销/支付微服务）→ 数据层（Redis 集群 + MySQL 分库分表 32×64 + ES 搜索）→ 异步层（RocketMQ 削峰 + 事务消息）→ 履约（仓储/物流）。
第四步：技术选型。Spring Cloud Alibaba + Redis Cluster + ShardingSphere + RocketMQ + ES + K8s。
第五步：一致性。下单用事务消息（Q69）；库存 Lua 防超卖（Q1）；订单/库存最终一致对账。
第六步：高可用。多 AZ 部署 + 单元化 + 限流降级 + 多级缓存。
第七步：性能优化。缓存命中率 ≥99%、DB 承压 <2 万 TPS、P99 <500ms。
流量收敛：50 万 QPS 经 CDN(静态)+Gateway(限流)+Redis(读)+MQ(写) 多层削峰，最终落到 MySQL 约 2 万 TPS。分库分表：订单/库存按 user_id 分片（Q43），1 亿 SKU 商品走 ES+缓存。协同：下单链路靠事务消息+Lua 预扣保证不超卖不丢单。
// 下单链路: 事务消息+库存Lua预扣(见Q1/Q69) // 商品查询: ES + Redis 多级(见Q51/Q58) // 分片: ShardingSphere user_id % 32 库, % 64 表
追问 1：跨机房？单元化（Q26），单元内闭环，跨单元异步同步。
追问 2：热点 SKU？库存分段（Q5）+ 本地缓存售罄标记。
追问 3：大促成本？弹性扩容 + 热点数据预扩容，平时缩容。
追问 4：对账？订单/库存/支付每日对账（Q29），超卖=0。
追问 5：容量模型？压测定拐点→算实例与分片数+余量。
- ❌ 50 万 QPS 直写 DB——崩。正确：多层削峰。
- ❌ 单库 1 亿 SKU——慢。正确：ES+分片。
- ❌ 无对账——资损。正确：每日对账。
第 87 题：金融级支付系统架构 支付
- 1. 资金怎么守恒？2. 强一致 vs 最终一致？3. 对账怎么做？4. 容灾？5. 防重防刷？
第一步：分析。支付第一原则是资金安全：不丢、不重、不超、可追溯。一致性与可靠性优先于性能。
第二步：核心挑战。资金守恒、零差错、RPO=0、对账、防重。
第三步：整体架构。支付核心（账户/清结算/对账微服务）+ TCC/事务消息保证资金守恒（Q16）+ 同步复制（RPO=0，Q50）+ 实时对账（每笔流水）+ 日终总分对账（Q29）+ 风控（Q14）+ 幂等（Q17）。
第四步：选型。Seata TCC + RocketMQ 事务消息 + MySQL MGR（同步）+ 对账平台 + 风控引擎。
第五步：一致性。账户变更强一致（TCC/本地事务），跨行异步最终一致+对账兜底。
第六步：高可用。同城双活+异地灾备，RPO=0/RTO<30s。
第七步：优化。热点账户拆子账户；对账自动化。
资金守恒：借贷必平衡，每笔流水记录「谁减谁加」。TCC 冻结-确认-补偿保证跨账户一致。对账是最后防线：实时比流水，日终比总额与三方，差错自动挂账人工。RPO=0：同城同步复制（Q50）。防重：全局流水号幂等（Q17），同笔只处理一次。
// 账户TCC(冻结-确认) try { accountSvc.freeze(from, to, amt); } // 冻结 confirm { accountSvc.transfer(from, to, amt); } // 确认 cancel { accountSvc.unfreeze(from, to, amt); } // 补偿 // 幂等: 全局流水号唯一索引(见Q17)
追问 1：跨行不一致？异步最终一致 + 日终对账 + 差错处理流程。
追问 2：热点账户？拆子账户/按金额分段，余额异步汇总。
追问 3：RPO=0 代价？同步复制降写吞吐，金融值得；异地异步 RPO 秒级。
追问 4：差错怎么处理？实时告警+挂账+人工调账，差错率趋零。
追问 5：性能 vs 安全？安全绝对优先，性能靠分片/异步提升，不牺牲一致。
- ❌ 为性能牺牲一致——资损。正确：资金优先。
- ❌ 无对账——差错未知。正确：实时+日终。
- ❌ 无幂等——重复记账。正确：流水号幂等。
第 88 题：物流与履约系统架构 物流
- 1. 运单状态机？2. 轨迹数据怎么存？3. 实时追踪？4. 高吞吐写入？5. 网点协同？
第一步：分析。物流=「状态流转 + 海量轨迹写 + 实时查」。核心是状态机防乱序 + 时序存储 + 削峰。
第二步：核心挑战。5 亿状态变更、20 万 GPS/s、状态一致、实时追踪。
第三步：整体架构。运单服务（状态机，Q64）+ Kafka 接状态变更（削峰）+ 轨迹写时序库（TDengine/InfluxDB 或 HBase）+ 实时查（Redis 缓存最新状态 + ES 历史）+ 网点协同（事件驱动）。
第四步：选型。Kafka + 状态机 + TDengine/HBase（轨迹）+ Redis（最新态）+ ES。
第五步：一致性。状态机拒绝非法跃迁；轨迹按运单有序。
第六步：高可用。Kafka 削峰 + 多副本时序库 + 限流。
第七步：优化。轨迹批量写 + 冷热分离（近期热、历史冷）。
状态机：已揽收→运输中→派送中→签收，非法跃迁（如签收→运输中）拒绝，保证业务正确。轨迹存储：GPS 时序数据量大、append-only，用时序库（TDengine）批量写，成本远低于关系库。实时追踪：最新状态放 Redis（热），历史轨迹 ES/时序库（冷）。
// 状态机校验 if (!waybill.canTransit(toStatus)) throw new IllegalState(); waybill.transit(toStatus); // GPS 批量写时序库 kafkaTemplate.send("gps", point); // 消费端批量落 TDengine
追问 1：轨迹查询慢？近期 Redis、历史时序库按运单分区，索引优化。
追问 2：状态乱序？状态机 + 版本号/时间戳，旧状态不覆盖新。
追问 3：GPS 存储成本？时序库高压缩 + 冷数据归档对象存储。
追问 4：网点协同？事件驱动，状态变更广播各系统。
追问 5：实时性？Kafka 近实时 + Redis 最新态，秒级可见。
- ❌ 轨迹存 MySQL——成本爆炸。正确：时序库。
- ❌ 无状态机——乱序。正确：状态机。
- ❌ 直写 DB——扛不住。正确：Kafka 削峰。
第 89 题：医疗信息系统（HIS）架构 医疗
- 1. 一致性要求？2. 病历存储？3. 合规与隐私？4. 高可用？5. 老系统整合？
第一步：分析。医疗=「强一致 + 高可靠 + 严合规 + 数据主权」。性能让位于正确与安全。
第二步：核心挑战。病历一致、PB 存储、合规、容灾、老系统。
第三步：整体架构。核心业务（挂号/医嘱/收费）强一致（本地事务+主从同步）+ 病历存储（对象存储+数据库元数据，版本化）+ 合规（私有云/院内、审计日志、加密、脱敏）+ 高可用（双活、RPO≈0）+ 集成（HL7/FHIR 对接老系统）。
第四步：选型。MySQL MGR（强一致）+ 对象存储（病历文件）+ ES（检索）+ 私有 K8s + 审计。
第五步：一致性。诊疗数据强一致；病历版本化防覆盖。
第六步：高可用。同城双活 + 异地灾备，RPO 近 0。
第七步：优化。冷热分离（近期病历热、历史归档）；影像 PACS 独立存储。
强一致：诊疗/收费不能最终一致（错账误治），用本地事务+同步复制。病历存储：大文件（影像/PDF）走对象存储，数据库只存元数据+版本链，支持回溯。合规：数据不出院（私有云）、全量审计、敏感字段加密脱敏、等保三级。集成：HL7/FHIR 标准对接 PACS/LIS 等老系统。
// 病历版本化 void saveRecord(Record r){ r.version = next(); objectStore.put(r.file); // 对象存储 metaMapper.insert(r); // 元数据+版本链 } // 审计: 所有诊疗操作落审计表(不可改)
追问 1：病历丢？对象存储多副本 + 异地备份；强一致主从。
追问 2：隐私合规？字段级加密 + 脱敏 + 最小授权 + 审计。
追问 3：老系统集成？HL7/FHIR 适配层，消息总线解耦。
追问 4：PACS 影像？独立对象存储 + CDN 院内加速。
追问 5：容灾？同城双活 + 异地灾备，RPO 近 0（诊疗数据不丢）。
- ❌ 诊疗用最终一致——误治。正确：强一致。
- ❌ 病历无版本——覆盖丢失。正确：版本化。
- ❌ 忽视合规——违规。正确：等保+加密+审计。
第 90 题：千万设备物联网（IoT）平台 IoT
- 1. 海量连接怎么接？2. 上报高吞吐？3. 指令实时下发？4. 设备认证？5. 时序数据？
第一步：分析。IoT=「海量长连接 + 高吞吐上行 + 低延迟下行 + 时序存储」。核心是连接层与消息管道。
第二步：核心挑战。1000 万长连接、50 万/s 上报、毫秒指令、设备安全。
第三步：整体架构。接入层（EMQX/MQTT 集群，百万连接/节点）+ 消息管道（Kafka 削峰）+ 规则引擎（过滤/转发）+ 时序存储（TDengine，50 万/s 批量写）+ 指令服务（MQTT 下行推送）+ 设备认证（证书/Token）。
第四步：选型。EMQX（MQTT）+ Kafka + TDengine + Redis（设备状态）+ K8s。
第五步：一致性。上报至少一次 + 幂等；指令精确一次（带 seq）。
第六步：高可用。MQTT 集群多节点 + Kafka 多副本 + 限流防风暴。
第七步：优化。连接分组 + 批量上报 + 边缘计算前置。
MQTT：轻量发布/订阅，适合弱网卡设备，EMQX 单集群支持千万连接。上报削峰：Kafka 缓冲 50 万/s，下游批量写时序库。指令下行：MQTT 推送（长连接）毫秒级，比轮询省。设备认证：每个设备证书/Token，防伪造接入。
// EMQX 规则引擎转发到 Kafka // 设备上报 topic: device/{id}/up // 指令下发: mqttTemplate.publish("device/"+id+"/down", cmd) // 时序批量写(消费Kafka) tdengine.batchInsert(points); // 50万/s
追问 1：连接数超单集群？EMQX 横向扩 + 连接按 region 分片。
追问 2：设备离线指令？指令队列 + 设备上线拉取（QoS 1/2）。
追问 3：上报重复？消息带 seq + 幂等去重。
追问 4：存储成本？时序库高压缩 + 冷数据归档。
追问 5：安全？TLS + 设备证书 + 权限（只能发自己 topic）。
- ❌ 用 HTTP 轮询——连接/功耗爆炸。正确：MQTT 长连接。
- ❌ 直写 DB——扛不住。正确：Kafka+时序库。
- ❌ 无设备认证——伪造。正确：证书/Token。
第 91 题：短视频与内容分发架构 短视频
- 1. 上传转码流程？2. CDN 分发？3. 推荐 feed？4. 存储成本？5. 热点视频？
第一步：分析。短视频=「写少读多（巨文件）+ 转码计算 + CDN 分发 + 推荐」。核心是存储/带宽成本与分发效率。
第二步：核心挑战。转码计算、CDN 带宽、海量存储、实时推荐。
第三步：整体架构。上传（客户端→对象存储直传）→ 转码（异步：消息触发转码集群，多清晰度）→ 分发（CDN 边缘缓存热点视频）→ 推荐（特征+召回+排序服务，ES/向量）+ 元数据库（MySQL+Redis）。
第四步：选型。对象存储（OSS/S3）+ 转码集群（FFmpeg/K8s）+ CDN + Kafka + 推荐服务。
第五步：一致性。转码完成再可播放（状态标记）；元数据最终一致。
第六步：高可用。CDN 多厂商 + 转码重试 + 降级（原画）。
第七步：优化。边缘转码/预热、冷热存储、带宽成本治理。
直传对象存储：客户端直传避免服务端带宽瓶颈，签名 URL 防篡改（Q30）。异步转码：多清晰度（480/720/1080）由消息触发转码集群，完成后标记可播。CDN：视频巨文件靠 CDN 边缘缓存降源站带宽，热点视频命中率高。推荐：b>召回（协同/向量）+ 排序（模型），feed 流分页游标。
// 签名URL直传(对象存储) String url = oss.signUpload(key, expire=300); // 客户端直传 // 转码触发 kafkaTemplate.send("transcode", new TranscodeTask(videoId));
追问 1：转码慢？转码集群弹性扩容 + 优先级队列（热门先转）。
追问 2：CDN 成本？冷热分层 + 多 CDN 比价 + 边缘缓存优化。
追问 3：推荐实时？特征实时更新 + 近线召回 + 在线排序。
追问 4：存储成本？对象存储低频/归档层 + 生命周期转冷。
追问 5：播放卡顿？多清晰度自适应 + CDN 预热热点。
- ❌ 服务端转发上传——带宽崩。正确：直传。
- ❌ 不转码原画——带宽贵。正确：多清晰度。
- ❌ 无 CDN——源站扛不住。正确：边缘分发。
第 92 题：社交 IM 与消息推送架构 IM
- 1. 长连接网关？2. 消息怎么路由到在线设备？3. 万人群？4. 离线消息？5. 已读/顺序？
第一步：分析。IM=「长连接维持 + 消息实时路由 + 多端同步 + 离线兜底」。核心是连接管理与消息扇出。
第二步：核心挑战。3000 万长连接、200 万/s、万人群扇出、端到端一致。
第三步：整体架构。接入网关（Netty WebSocket 集群，维护连接与设备映射）→ 消息服务（落库 + 分发）→ 路由（按用户在线节点推送，Redis 存连接位置）→ 群聊（扇出到群成员在线节点，批量）→ 离线（APNs/厂商推送 + 拉取）→ 多端同步（消息序号）。
第四步：选型。Netty 网关 + Kafka（消息总线）+ Redis（连接路由）+ 推拉结合。
第五步：一致性。消息序号保证端到端顺序与多端同步。
第六步：高可用。网关多节点 + Kafka 多副本 + 离线兜底。
第七步：优化。连接分组、群消息合并、推送限流。
连接路由：用户连接落在某网关节点，Redis 记录「uid→节点」，消息先查路由再推。万人群扇出：群消息一次写，扇出到所有在线成员节点（批量推送），避免逐条。推拉结合：在线推，离线走厂商推送 + 上线拉取。多端同步：消息全局序号，多端按序号对齐。
// 连接路由: 上线登记 redis.hset("route:"+uid, device, nodeIp); // 群消息扇出 List<String> nodes = groupOnlineNodes(groupId); nodes.forEach(n -> pushService.push(n, msg)); // 批量
追问 1：连接节点挂？连接断开客户端重连，路由更新；在途消息落库可重推。
追问 2：万人群卡？群消息异步扇出 + 限流 + 合并。
追问 3：消息丢失？落库 + 确认 + 拉取兜底，at-least-once+幂等。
追问 4：多端不同步？消息序号 + 多端按序拉取。
追问 5：延迟？内存路由 + 推送近实时，<200ms。
- ❌ 轮询拉消息——延迟/负载高。正确：长连接推。
- ❌ 群消息逐条发——慢。正确：扇出批量。
- ❌ 无路由表——不知推哪。正确：连接路由。
第 93 题：商品搜索平台架构 搜索
- 1. 为什么用 ES？2. 近实时更新？3. 分片与容量？4. 查询性能？5. 召回与排序？
第一步：分析。搜索=「海量文档 + 近实时索引 + 低延迟查询 + 相关性排序」。核心是索引与查询优化。
第二步：核心挑战。10 亿文档、P99<100ms、近实时、排序。
第三步：整体架构。数据源（DB/CDC）→ 索引构建（Canal→ES 近实时，或离线全量+增量）→ ES 集群（按商品分片、副本）→ 查询网关（聚合/分页/高亮）→ 排序（BM25 + 业务加权 + 向量召回）→ 缓存（热门 Query 结果 Redis）。
第四步：选型。Elasticsearch（10 亿分片）+ Canal（近实时）+ Redis（Query 缓存）+ 向量检索。
第五步：一致性。搜索近实时（秒级），接受短暂延迟；主数据以 DB 为准。
第六步：高可用。ES 多副本 + 多可用区 + 查询限流。
第七步：优化。分片数（每分片 20~50G）、Query 缓存、聚合下推。
近实时：Canal 订阅 binlog 增量建/更新索引，1 分钟内可见（refresh_interval 调小）。分片：10 亿文档按商品 hash 分片，每分片 20~50G 最佳，过多分片元数据开销大。性能：Query 缓存（Redis）扛热点，深翻页用 search_after（游标）。排序：BM25 + 业务加权（销量/信用）+ 向量召回（语义）。
// Canal 同步到 ES(近实时) // 查询: 高亮+排序 SearchRequest r = new SearchRequest("item"); r.source(QueryBuilders.matchQuery("title", kw) .highlighter(HighlightBuilder.create()))； // 深翻页: search_after(游标)
追问 1：索引重建慢？别名切换（alias）+ 滚动重建，零停机。
追问 2：深翻页慢？search_after 游标，禁用 from/size 深翻。
追问 3：相关性差？BM25 + 业务加权 + 向量语义召回混合。
追问 4：ES 压力大？Query 缓存 + 读写分离（副本查）。
追问 5：数据不一致？近实时可接受；全量校验定时修复。
- ❌ DB LIKE 搜索——慢。正确：ES。
- ❌ from/size 深翻——慢。正确：search_after。
- ❌ 不近实时——上新不可搜。正确：CDC。
第 94 题：广告投放与 RTB 实时竞价 广告
- 1. 延迟怎么压到 50ms？2. 召回怎么快？3. 出价模型？4. 高吞吐？5. 反作弊？
第一步：分析。RTB=「极短延迟 + 高吞吐 + 实时决策」。核心是预算内完成召回排序，超时即弃。
第二步：核心挑战。50ms 预算、100 万 QPS、模型推理延迟、反作弊。
第三步：整体架构。竞价网关（限 50ms 超时）→ 召回（本地缓存广告+倒排，Redis/内存）→ 排序（轻量模型/规则，内存特征）→ 出价（预算控制）→ 反作弊（实时规则，Q14）→ 计费（异步对账）。特征与模型前置加载内存，避免远程调用。
第四步：选型。内存特征 + Redis + 本地模型推理 + Kafka（计费/日志）+ 限流。
第五步：一致性。计费最终一致（异步对账）；竞价实时但可超时丢弃。
第六步：高可用。超时降级（返回默认/不竞）+ 多机房就近。
第七步：优化。特征本地化、模型轻量化、并行召回。
延迟预算：全程 50ms 内，任何远程调用都危险，故特征/模型/广告全内存化。并行召回：多路召回（上下文/用户/广告主）并行，取最优。超时即弃：超 50ms 不返回，保系统不被慢请求拖垮。计费异步：竞价实时、计费最终一致（对账防漏）。
// 竞价超时控制(50ms) CompletableFuture<Bid> f = bid(uctx); Bid b = f.get(50, MILLISECONDS); // 超时即弃 // 并行召回 List<Ad> ads = invokeAll(recallCtxt, recallA, recallB, recallC);
追问 1：模型推理慢？轻量模型/规则前置内存，或用 GPU 批处理推理。
追问 2：计费漏？竞价日志异步落库 + 对账，保证最终一致。
追问 3：突发流量？限流 + 超时降级 + 弹性扩容。
追问 4：反作弊？实时规则+设备指纹（Q14），作弊请求不竞。
追问 5：预算控制？广告主实时预算扣减（Redis），超预算不出价。
- ❌ 竞价内远程调用——超 50ms。正确：全内存化。
- ❌ 不超时控制——拖垮。正确：预算即弃。
- ❌ 计费同步——慢。正确：异步对账。
第 95 题：风控与反欺诈实时决策 风控
- 1. 实时特征怎么算？2. 规则引擎？3. 模型怎么接？4. 延迟 <20ms？5. 误杀？
第一步：分析。风控=「实时特征 + 规则/模型决策 + 低延迟 + 可解释」。核心是特征实时性与决策速度。
第二步：核心挑战。30 万 QPS、<20ms、5000 规则、误杀控制。
第三步：整体架构。事件接入（Kafka）→ 实时特征（Flink 计算滑窗特征写 Redis/特征库）→ 决策（规则引擎+模型并行，本地特征）+ 决策结果（放行/挑战/拦截）+ 离线（样本/模型训练）。特征与规则前置，决策内存化。
第四步：选型。Flink（实时特征）+ Redis（特征库）+ 规则引擎（自研/Drools）+ 模型服务 + Kafka。
第五步：一致性。决策不写业务数据；结果异步入样本库。
第六步：高可用。fail-open（低风险）/ fail-close（高风险）+ 多级降级。
第七步：优化。特征本地缓存、规则编译、模型轻量化。
实时特征：Flink 算近 5 分钟行为（频次/金额）写 Redis，决策时直接读，免实时计算。决策内存化：规则编译 + 模型本地推理，<20ms。fail 策略：低风险 fail-open（放行+监控），高风险 fail-close（拦截）。误杀：分级（挑战中间态）+ 灰度 + 申诉，监控误杀率。
// Flink 滑窗特征 keyed.window(SlidingEventTimeWindows.of(5min, 1min)) .aggregate(freqAgg) → redis.set(featureKey, v); // 决策: 规则+模型并行 Score s = ruleEngine.evaluate(ctx).combine(model.score(ctx));
追问 1：特征延迟？Flink 近实时（秒级），决策读 Redis 内存，<20ms。
追问 2：规则 5000 慢？规则分组 + 编译 + 短路（高危先判）。
追问 3：模型重？轻量模型本地推理，重任离线批。
追问 4：误杀？挑战中间态 + 灰度 + 申诉 + 误杀率监控。
追问 5：对抗升级？样本回流→模型迭代→规则更新闭环。
- ❌ 决策内算特征——超 20ms。正确：Flink 预计算。
- ❌ 一刀切拦截——误杀。正确：分级挑战。
- ❌ 无闭环——对抗失效。正确：样本回流。
第 96 题：网约车派单调度架构 调度
- 1. 附近司机怎么找？2. 派单决策？3. 实时位置？4. 高并发派单？5. 调度公平性？
第一步：分析。派单=「地理检索 + 实时状态 + 决策算法 + 低延迟」。核心是地理索引与匹配效率。
第二步：核心挑战。100 万司机位置、<1s 派单、地理半径、公平性。
第三步：整体架构。位置服务（司机位置写 GeoHash/Redis GEO/PostGIS）→ 订单服务（生成订单）→ 派单引擎（按 GeoHash 圈选附近司机 + 排序/模型打分）→ 推送（司机端）+ 状态机（接单/取消）→ 结算。位置用 GeoHash 网格快速检索。
第四步：选型。Redis GEO/GeoHash + PostGIS + Kafka + 调度服务 + Flink（轨迹）。
第五步：一致性。司机位置最终一致（秒级）；订单状态机防重复派。
第六步：高可用。位置多副本 + 派单限流 + 超时重派。
第七步：优化。GeoHash 网格 + 司机热度 + 并行打分。
GeoHash：把经纬度编码为网格字符串，按前缀范围快速查附近司机，避免全量距离计算。派单决策：圈选后按距离/评分/司机负载打分，最优推送；<1s 内完成。状态机：防重复派单、重复接单。地理位置秒级更新即可（最终一致）。
// GeoHash 圈选附近司机 String gh = Geohash.encode(lat, lng, 6); // 网格 Set<String> drivers = redis.georadius(gh, 3km); // 3公里内 // 打分派单(并行) Driver best = scoreAndPick(drivers, order);
追问 1：网格边界司机漏？查相邻 8 网格合并，或 GeoHash 多精度。
追问 2：派单慢？GeoHash 预聚合 + 并行打分 + 限候选集。
追问 3：司机作弊（虚拟定位）？轨迹连续性校验 + 风控（Q14）。
追问 4：公平性？调度模型含司机负载/距离平衡，避免马太效应。
追问 5：高并发？派单限流 + Kafka 削峰 + 弹性扩容。
- ❌ 全量距离计算——慢。正确：GeoHash。
- ❌ 无状态机——重复派。正确：状态机。
- ❌ 位置强一致——没必要。正确：秒级最终一致。
第 97 题：供应链与库存中台架构 库存中台
- 1. 中台定位？2. 库存防超卖？3. 多端一致？4. 高并发扣减？5. 预占与释放？
第一步：分析。库存中台=「统一库存事实源 + 高性能扣减 + 多端一致 + 防超卖」。核心是库存语义统一。
第二步：核心挑战。2 亿变动/天、超卖=0、多端实时、高并发。
第三步：整体架构。库存中台（Redis 库存+DB 裁判，Lua 原子扣减，Q1）→ 预占/确认/释放状态机 → 多端（电商/门店）通过中台统一扣减 → CDC 同步各端视图 → 对账（日终，Q29）。热点 SKU 分段（Q5）。
第四步：选型。Redis Cluster（库存）+ MySQL（账本）+ RocketMQ（变动广播）+ CDC。
第五步：一致性。Redis 预扣 + DB 条件扣减裁判；多端最终一致 + 对账。
第六步：高可用。Redis 多副本 + 降级（DB 直扣限流）+ 单元化。
第七步：优化。分段库存 + 本地售罄标记 + 批量同步。
中台价值：避免各端各自记库存导致不一致。中台是唯一事实源，各端调中台扣减。防超卖：Redis Lua 原子预扣 + DB 条件扣减（Q1）。预占模型：下单预占、支付确认、超时释放，状态机保证不超卖不漏。多端一致：CDC 同步各端只读视图，对账兜底。
// 中台扣减(Lua原子, 见Q1) // 预占/确认/释放状态机 enum StockState { AVAILABLE, PRE_OCCUPIED, SOLD, RELEASED } // 多端视图: CDC 同步
追问 1：多端抢同一库存？中台统一扣减，Lua 原子，超卖=0。
追问 2：预占不释放？定时任务扫描超时预占释放回补。
追问 3：中台挂？降级各端本地限额 + 异步回补中台。
追问 4：库存视图延迟？CDC 秒级；关键扣减走中台实时。
追问 5：热点 SKU？分段（Q5）+ 本地售罄标记。
- ❌ 各端自记库存——不一致。正确：中台统一。
- ❌ 无预占——超卖。正确：预占模型。
- ❌ 无对账——差错未知。正确：日终对账。
第 98 题：多租户 SaaS 平台架构（扩展） SaaS
- 1. 隔离策略选型？2. 大租户独占？3. 弹性与计量？4. 升级发布？5. 成本模型？
第一步：分析。SaaS=「隔离 + 弹性 + 计量 + 低成本」。综合 Q39，采用混合隔离。
第二步：核心挑战。2 万租户、隔离、弹性、计量、成本。
第三步：整体架构。混合隔离（小租户共享库行级、大租户独立 schema/库，Q39）+ 租户路由（上下文透传 + 强制过滤，Q39）+ 弹性（K8s 按租户负载 + 大租户独立资源）+ 计量（用量采集计费）+ 灰度发布（按租户分批，Q35）+ 成本（共享池降本）。
第四步：选型。共享 MySQL + 独立库 + K8s + 配置中心 + 计量服务。
第五步：一致性。租户上下文全程透传，强制隔离防越权。
第六步：高可用。大租户独立资源防吵闹邻居；多副本。
第七步：优化。自动升降级隔离级别；冷热分离降本。
混合隔离：万级租户不能全独立（成本爆炸），小租户共享行级隔离，大租户独占（Q39）。自动升降级：达阈值自动迁独立库。按租户灰度：新版本先给小租户/白名单，再全量，错误半径小。成本：共享池为主，大租户按需独占，计量驱动计费。
// 租户路由 + 强制过滤(见Q39 MyBatis拦截器) // 按租户灰度: 配置中心白名单控制新版本租户范围 // 计量: 用量采集定时汇总 → 账单
追问 1：租户数据迁移？在线迁移（Q45）+ 双写校验，按租户批次。
追问 2：合规出境？租户级区域路由，独立库落指定 Region。
追问 3：成本怎么算？按资源占用（CPU/存储/请求）计量，大租户独占计费。
追问 4：升级影响其他租户？按租户灰度 + 兼容式迁移（Q35）。
追问 5：吵闹邻居？大租户独占 + 共享池配额隔离（Q39）。
- ❌ 全独立库——成本爆炸。正确：混合隔离。
- ❌ 全量发布——影响大。正确：按租户灰度。
- ❌ 无计量——无法计费。正确：用量采集。
第 99 题：全球多活与异地容灾架构 多活
- 1. 多活 vs 主备？2. 数据怎么跨区同步？3. 单元化？4. 脑裂？5. 合规？
第一步：分析。多活=「各 Region 独立读写 + 异步同步 + 故障切换」。核心是单元化与冲突处理（Q26）。
第二步：核心挑战。RTO/RPO、跨区同步、脑裂、合规、冲突。
第三步：整体架构。单元化（按用户归属 Region，单元内闭环，Q26）+ 跨区异步同步（DRC，用户跨区访问路由最近）+ 故障切换（DNS/网关切流，RTO<5min）+ 防脑裂（fencing，Q50）+ 合规（数据本地化，不出境）。冲突用版本/业务规则解决。
第四步：选型。单元化 + DRC（如 Otter/Canal 跨区）+ GSLB（就近路由）+ 多活管控。
第五步：一致性。单元内强一致，跨区最终一致 + 冲突解决。
第六步：高可用。多 Region 独立，故障切换 + fencing 防脑裂。
第七步：优化。单元封闭降跨区流量；热点全局数据特殊处理。
单元化：用户数据归属某 Region，读写闭环，跨区仅同步（降延迟与耦合）。多活 vs 主备：主备切流慢、备资源闲置；多活各 Region 都用，故障切换快。脑裂：网络分区时两 Region 都写，需 fencing（杀旧主写）防冲突。合规：数据不出境，跨区同步需脱敏/授权。
// 单元路由: 用户归属Region Region r = userRegionMap.get(uid % 3); // 单元封闭 // 跨区同步: Canal/Otter DRC 异步 // 故障切换: 多活管控切流 + fencing 旧主
追问 1：跨区写冲突？单元封闭避免；必要跨区用全局锁/版本解决。
追问 2：RPO<1min 难？异步同步有窗口，关键数据用同步复制（同 Region 内）。
追问 3：脑裂数据错？fencing + 冲突检测 + 对账修复。
追问 4：合规？数据本地化，跨区仅同步必要/脱敏。
追问 5：成本？多 Region 资源翻倍，按业务重要性选多活范围。
- ❌ 跨区强一致写——延迟高。正确：单元化+异步。
- ❌ 无 fencing——脑裂冲突。正确：fencing。
- ❌ 忽视合规——违规。正确：数据本地化。
第 100 题：AI 大模型应用平台架构 AI平台
- 1. 统一网关？2. 推理调度？3. 成本怎么控？4. 限流降级？5. 缓存与流式？
第一步：分析。AI 平台=「统一接入 + 模型路由 + 推理调度 + 成本治理 + 可靠性」。核心是屏蔽多模型差异与降本。
第二步：核心挑战。10 万并发、<2s、成本、限流、多模型。
第三步：整体架构。统一网关（协议归一、鉴权、限流）→ 模型路由（按任务/成本选模型：简单任务用小模型）→ 推理调度（GPU 池化、批处理、队列削峰）→ 流式返回（SSE）→ 缓存（相似 Query 结果缓存，RAG 降重复）→ 成本（用量计量+配额）。故障降级（大模型不可用切小模型/兜底）。
第四步：选型。网关（Spring Cloud Gateway）+ 模型路由 + GPU 推理服务（vLLM/Triton）+ Redis（缓存/限流）+ Kafka（队列）+ 计量。
第五步：一致性。推理结果缓存需版本化（模型/提示变更失效）。
第六步：高可用。多模型冗余 + 降级（小模型兜底）+ 限流防 GPU 打满。
第七步：优化。批处理（continuous batching）、量化、缓存命中降本。
统一网关：屏蔽 OpenAI/国产模型协议差异，业务无感切换。模型路由：简单任务（分类/抽取）用小模型降本，复杂任务用大模型保质量。GPU 调度：continuous batching 提升吞吐，队列削峰防 OOM。缓存：相似 Query 结果缓存（语义哈希）大幅降本。降级：大模型超时/限流切小模型或兜底话术，保可用。
// 模型路由: 简单任务走小模型 Model m = task.complex() ? BIG : SMALL; // 流式返回(SSE) response.setContentType("text/event-stream"); model.stream(prompt).subscribe(tok -> write(tok)); // 逐 token // 限流: 按租户 GPU 配额
追问 1：GPU 成本高？小模型路由 + 缓存 + 量化 + 批处理，降本数倍。
追问 2：推理超时？降级小模型/兜底 + 流式避免长连接超时。
追问 3：多模型故障？路由冗余 + 自动切模型 + 限流保护。
追问 4：缓存一致性？结果按模型版本+提示哈希失效，避免旧结果。
追问 5：并发 10 万？队列削峰 + GPU 池化 + 弹性扩容（按负载）。
- ❌ 直连单一模型——无冗余/贵。正确：网关+路由。
- ❌ 无缓存——重复推理烧钱。正确：结果缓存。
- ❌ 无降级——大模型挂即崩。正确：小模型兜底。