文章目录五、分布式、平台与稳定性405040. 下单同时扣库存、建订单、发券分布式事务怎么选具体示例41. 定时任务实例宕机后不能丢如何设计分布式调度具体示例42. Redis 分布式锁怎样才相对可靠何时不该用具体示例43. 分布式 ID 如何唯一、趋势递增并处理时钟回拨具体示例44. 设计大文件/视频上传与异步转码系统。具体示例45. 设计每秒百万条的日志采集与检索系统。具体示例46. 设计搜索联想/自动补全要求 50ms 内返回。具体示例47. 高风险功能如何做配置中心、灰度发布和安全回滚具体示例48. 核心服务如何做同城双机房或异地多活具体示例49. RPC 超时后该不该重试如何避免重试风暴具体示例50. 线上大面积报错Oncall 如何止血、定位并复盘具体示例五、分布式、平台与稳定性405040. 下单同时扣库存、建订单、发券分布式事务怎么选先缩事务。同库操作优先本地事务库存预占和订单创建是核心发券、通知等派生动作可通过 Outbox 最终一致。不要一上来选择 2PC。跨服务。使用 Saga/TCC每个参与者提供 Try/Confirm/Cancel 或正向动作与补偿协调器持久化状态并重试。所有阶段携带 global_tx_id 幂等超时由扫描任务继续推进。不可补偿。券已使用、通知已送达等动作不能简单“回滚”需要业务状态和人工处理路径。补偿也会失败因此要有重试上限、隔离队列和对账。选择依据。2PC 适合少参与者、延迟可接受且基础设施成熟的强一致场景Saga 可用性更好但会暴露中间状态。高质量答案应明确一致性价值而不是背协议名词。具体示例具体设定。用户下单后要扣库存、建订单、赠送优惠券发券失败不应让库存长期占用。落地例子。库存预占和订单创建作为核心流程订单服务写订单和 outbox库存服务 Try 预占支付成功 Confirm超时 Cancel。发券作为订阅订单已支付事件的最终一致动作失败进入重试和补偿不阻塞下单事务。面试可讲。先缩小强一致边界。库存和订单需要较强一致通知/发券通常可以最终一致。不要一上来 2PC把所有副作用绑死。分布式事务比较常用的方案使用MQ 本地事务表41. 定时任务实例宕机后不能丢如何设计分布式调度持久化。任务保存 next_trigger_time、payload_ref、status、version、retry_count调度器按时间索引扫描。领取任务时写 owner 与 lease_expire_time执行者续租宕机后租约过期可被重新领取。分层。远期任务留在数据库/延迟队列近未来任务加载到时间轮避免每毫秒扫描大表。任务按 shard 分配所有权扩容时迁移 shard。语义。系统提供至少一次执行业务以 task_id 幂等。状态条件更新防止两个实例同时完成失败指数退避超过阈值转人工。长任务必须续租并限制最大运行时间。异常。处理时钟漂移、迟到、重复、调度惊群和批量同一时刻到期。仅用进程内 Cron 无法覆盖重启和多实例。具体示例具体设定。订单 30 分钟未支付要自动关闭调度实例可能重启。落地例子。任务表存task_id, next_trigger_time, owner, lease_expire, status, version。实例领取任务时条件更新 owner 和租约执行成功后状态改 DONE。实例宕机后租约过期其他实例可重新领取。关闭订单用task_id/order_id幂等。面试可讲。分布式调度一般提供至少一次执行所以业务必须幂等。进程内 Cron 无法覆盖重启、多实例和任务迁移。42. Redis 分布式锁怎样才相对可靠何时不该用正确姿势。SET key token NX PX ttl释放用 Lua 校验 token 再删除。长临界区受控续租并设置最大持有时间获取失败随机退避。业务本身仍需幂等。Fencing Token。客户端可能因 GC 暂停超过 TTL醒来后继续写。锁服务每次发放递增 fencing token下游只接受更大 token才能拒绝旧持有者。限制。Redis 主从切换可能在锁未复制时产生双持有者极强一致使用共识锁服务。账户余额、库存等优先用数据库唯一约束和条件更新不要把锁当数据正确性的唯一防线。临界区不要包含不可控远程慢调用。具体示例具体设定。多实例同时刷新同一个热点商品缓存只允许一个实例回源 DB。落地例子。使用SET lock:product:123 token NX PX 3000释放时 Lua 校验 token 再删。若刷新超过 3 秒要么受控续租要么返回旧值不让旧持有者无限写。对库存扣减这种强正确场景仍用 DB 条件更新不把 Redis 锁当唯一防线。面试可讲。Redis 锁适合降低重复工作不适合作为资金/库存正确性的唯一保证。要讲 token、TTL、Lua 释放和 fencing token。43. 分布式 ID 如何唯一、趋势递增并处理时钟回拨Snowflake。64 位拆为时间戳、机房/节点、同毫秒序列节点号通过租约分配防止重复。计算位数能支撑的年限、节点数和每毫秒吞吐。回拨。小幅回拨等待大幅回拨切逻辑时钟、备用节点号或停止生成并告警。必须避免两个进程拿同一节点号。趋势递增不等于严格连续也不应把连续性作为业务正确性。号段。需要更强单调性时数据库一次分配一段服务本地递增并双缓冲预取数据库压力是每个号段一次。外部展示 ID 可再编码或加随机扰动防止暴露业务规模。具体示例具体设定。订单 ID 要全局唯一、趋势递增支持 1000 台机器每台每毫秒最多 4096 个。落地例子。Snowflake 拆成时间戳 机房/机器号 毫秒内序列。机器号由注册中心租约分配防止两个进程拿同一 worker_id。时钟回拨 5ms 内等待超过阈值切逻辑时钟或停止发号告警。面试可讲。趋势递增不是严格连续。ID 方案要回答位数容量、worker_id 分配、时钟回拨和暴露业务规模的问题。44. 设计大文件/视频上传与异步转码系统。上传。客户端先申请 upload_id 和分片签名直接分片上传对象存储服务端不代理大流量。每片带序号、大小和 checksum支持并发、断点续传与幂等 Complete。处理。合并完成写媒体记录和 Outbox转码任务进入 MQWorker 按资源需求调度输出多码率文件、封面和元数据。任务状态机记录阶段、attempt 和产物版本失败可从最近阶段重试。分发。CDN 回源对象存储播放地址鉴权与防盗链。新旧转码版本用 manifest 原子切换原文件按合规策略保留或清理。安全。上传前后做类型、病毒、内容安全和配额检查用户声明的 MIME 不可信。追问需覆盖超大分片、重复 Complete、转码长尾和热点视频缓存。具体示例具体设定。用户上传 2GB 视频网络中断后要续传上传完生成 480p/720p/1080p。落地例子。客户端先申请upload_id和分片签名直接上传 TOS/S3。每片带part_no和 checksumComplete 时服务校验所有分片并写media(statusUPLOADED)随后 outbox 发转码任务。转码产物写 manifest完成后原子切换play_manifest_version。面试可讲。服务端不代理大文件流量只负责签名、状态和任务编排。转码是长任务要有阶段状态、重试、产物版本和内容安全检查。45. 设计每秒百万条的日志采集与检索系统。容量。先算带宽1KB/条、100 万条/秒约 1GB/s 原始流量必须批量压缩、分区和分层存储。检索、告警、审计的时效与保留期不同。链路。Agent 本地批量、压缩并落盘缓冲接入层无状态把日志写持久 MQ下游分为实时解析告警、近期检索索引、长期对象存储。按服务/租户分区并设置配额坏格式进入隔离流。可靠性。批次有 sequence/checksumAgent 根据 ACK 清本地 WAL消费者使用 offset 和幂等批次。背压时优先保留审计和错误日志对 debug 日志采样或丢弃。成本。在线索引只保留近期高价值字段原文压缩存冷层查询旧数据触发异步回载。日志系统自身要限制自日志避免反馈风暴。具体示例具体设定。每条日志平均 1KB100 万条/s 就是约 1GB/s 原始流量。落地例子。Agent 本地批量压缩失败时写 WAL接入层写 Kafka/Pulsar下游分三路实时告警、近 7 天检索索引、长期对象存储。租户配额限制 debug 日志故障时优先保留 error 和审计日志。面试可讲。日志系统首先是流量和成本问题。要讲批量、压缩、背压、分层存储、采样和坏日志隔离而不是只说 ELK。46. 设计搜索联想/自动补全要求 50ms 内返回。数据结构。静态词典可用 Trie/FST每个前缀节点保存 Top K 候选避免请求时遍历整个子树。候选分数综合搜索频率、点击率、新鲜度和个性化。更新。离线构建全量版本流式统计热词做增量 overlay新版本在内存中加载完成后原子切换。拼写纠错和同义词归一化在候选召回前完成但要限制组合爆炸。部署。数据按语言/前缀分片热点前缀多副本服务本地内存查询远程只取个性化特征并设严格预算。返回前做敏感词、地域和权限过滤。为什么。50ms 目标决定主路径不能依赖复杂数据库查询。预计算 Top K 是典型用空间换低延迟追问要讨论版本内存峰值、冷启动和空前缀热点。具体示例具体设定。用户输入“bei”50ms 内返回“北京天气、北京地铁、北京大学”等 10 个候选。落地例子。离线构建 Trie/FST每个前缀节点预存 Top 20 候选和分数。热词增量用 overlay 覆盖主词典服务本地内存查询个性化特征最多花 10ms超时就返回非个性化结果。面试可讲。50ms 决定不能请求时扫数据库或遍历整棵树。候选要预计算线上只是前缀查找、轻量重排和敏感词过滤。47. 高风险功能如何做配置中心、灰度发布和安全回滚解耦。代码发布、配置开启、数据变更分开。Feature Flag 默认关闭按内部用户、单机房、1%、5%、20% 放量稳定用户键分桶避免来回跳组。配置。配置带 schema、版本、owner、审批、有效期和变更审计客户端本地缓存最后正确版本配置中心故障时使用安全默认。推送通知后客户端仍按版本拉取防止漏事件。护栏。每阶段观察错误率、P99、CPU、依赖水位和业务指标超过阈值自动关开关。数据库采用 expand-contract先加兼容结构、再切读写、最后删除旧结构。回滚。回滚代码不等于回滚数据。不可逆写入必须提前设计补偿或双格式兼容。任何自动发布都要有单一总开关和明确操作人。具体示例具体设定。新推荐算法可能影响首页点击率要从内部用户逐步放到全量。落地例子。Feature Flagnew_feed_rank默认关按hash(user_id) % 10000稳定分桶内部用户、1%、5%、20%、50%、100%。每档观察错误率、P99、点击率和投诉异常自动关总开关。配置带 schema、owner、审批和版本。面试可讲。发布、配置、数据变更要解耦。回滚代码不等于回滚数据所以不可逆写入要提前设计兼容和补偿。48. 核心服务如何做同城双机房或异地多活目标。先定义 RTO、RPO、故障域和一致性。多活不仅是服务两份还需要数据、MQ、配置、密钥、限流和第三方依赖形成完整单元。架构。无状态服务跨机房部署并就近路由用户或租户有 home region写请求回归属单元减少双写冲突。强一致小数据用共识复制普通数据主写异步复制派生索引通过事件同步。versioned async replicationGlobal TrafficRegion A CellRegion B CellService/Cache/DB/MQService/Cache/DB/MQControl Plane Quorum切换。多信号故障检测 防抖分阶段切流使用仲裁和 fencing 防脑裂。切流前确认目标端数据水位恢复后限速回切。定期做断网、依赖失败和整机房演练验证真实 RTO/RPO。追问。DNS 缓存和长连接使切流不瞬时异步复制意味着 RPO 非零。不要用“加一个异地机房”掩盖数据冲突。具体示例具体设定。订单服务要求 RTO 5 分钟、RPO 30 秒用户按归属地分配 home region。落地例子。用户uid888归属 Region A写请求路由回 ARegion B 有异步复制副本。A 故障时控制面确认复制水位后把这批用户切到 B并 fencing 旧 A避免恢复瞬间双写。派生索引用事件在两地同步。面试可讲。多活不是服务部署两份还包括 DB、MQ、缓存、配置、限流和第三方依赖。异步复制 RPO 非零要明确故障切换时可能丢多少数据。49. RPC 超时后该不该重试如何避免重试风暴分类。只对幂等读或带幂等键的写重试参数错误、权限错误和明确限流通常不重试。超时状态未知的写操作先查业务结果。策略。有限次数、指数退避 jitter每次尝试受端到端 Deadline 约束。定义重试预算例如额外流量不超过正常流量 5%只在一层统一重试避免三层各重试三次产生 27 倍放大。保护。下游错误持续升高时熔断半开小流量探测并发隔离、有界队列和取消传播避免过期请求继续占资源。服务端读取 Deadline来不及完成就尽早拒绝。为什么。重试只适合瞬时故障不是过载恢复方案。没有预算和退避的重试会让系统在最脆弱时承受更多流量。具体示例具体设定。A 调 B 超时 200msB 实际已经处理成功但响应丢了上层网关、A、SDK 都配置 3 次重试。落地例子。写接口必须带request_id超时后先查业务结果或用同一幂等键重试。全链路只允许一层重试总 deadline 500ms最多 2 次指数退避加 jitter并设置重试预算例如额外流量不超过 5%。面试可讲。重试适合瞬时故障不适合下游过载。没有预算和退避时三层各重试三次会把流量放大到 27 倍。50. 线上大面积报错Oncall 如何止血、定位并复盘前 5 分钟。确认用户影响、错误率、地域和开始时间宣布事故等级指定指挥、操作和记录角色。检查最近发布、配置与依赖变更建立共享时间线。先止血。优先执行可逆动作关开关、回滚、限流、降级、切流、摘除异常实例。每个操作记录时间、预期、结果和回退方式。不能为了找根因而让用户继续受损。定位。从 RED 指标与 Trace 找故障 Span再检查线程池、连接池、GC、网络、DB、Redis 和下游。按版本、机房、实例、调用方、参数对比。保留日志、慢查询和核心 dump避免反复重启破坏现场。复盘。重建因果链与防线失效链为什么发生、为什么未被阻止、为什么未更早发现、为什么恢复慢。行动项必须有 owner、截止时间和验证方式例如自动降级、容量测试、依赖隔离与演练避免只写“加强监控”。具体示例具体设定。22:05 开始支付成功率从 99.9% 掉到 80%影响全部用户。落地例子。前 5 分钟先定级、建时间线、查最近发布、配置和依赖变更如果 22:00 刚发版支付服务先灰度回滚或关新开关止血。定位时按版本、机房、错误码、下游 Span 对比保留日志和慢查询。复盘行动项写 owner 和截止时间例如“支付依赖超时自动降级7 月 20 日前完成演练”。面试可讲。Oncall 答案要先止血再定位再复盘。不要为了找根因让用户继续受损也不要复盘只写“加强监控”要有可验证的防线改进。
