系统架构设计师高频考点练习题

团队为HTTP请求耗时指标增加标签，候选标签有service、route、status_code、user_id和trace_id。为了控制指标系统的时间序列规模，最不适合作为该指标标签组合的是（）。

某服务按连续30天窗口考核可用性SLO，目标为99.9%。暂不考虑统计口径差异，按时间计算，该窗口对应的错误预算约为（）。

订单系统在两个地域双活。地域A将收货地址改为新地址，几乎同时地域B将配送方式改为加急，但两个地域都覆盖写入整条订单记录。数据库采用Last-Writer-Wins解决冲突。下列判断正确的是（）。

订单事件流包含“创建、支付、发货、退款”。系统要求同一订单的事件按产生顺序消费，但不同订单可以并行处理。采用分区消息系统时，最合适的设计是（）。

订单系统需要把数据库字段 customer_name 改为 buyer_name。发布期间新旧两个版本的应用会同时运行。为了尽量避免停机和版本不兼容，最合理的步骤是（）。

平台每天产生海量Trace，只能保存少部分。团队希望尽量保留出现错误、延迟超过3秒或经过关键支付服务的完整链路，而普通成功请求只抽取少量。较适合的采样方式是（）。

架构师比较两种缓存写策略：方案甲在更新缓存时同步写入后端数据库，后端成功后才返回；方案乙先更新缓存并快速返回，再异步批量写入后端。两者分别更接近（）。

库存消费者处理消息M100成功并提交数据库，但在向消息队列确认前进程崩溃。队列随后重新投递M100。要避免库存再次扣减，较合理的设计是（）。

某接口使用令牌桶限流：桶容量为20个令牌，每个请求消耗1个令牌，补充速率为每秒5个。系统空闲足够长时间后，某一瞬间同时到达30个请求。忽略处理耗时，立即最多可放行（）。

客户端要求订单请求在2秒内返回。网关处理已耗时300毫秒，订单服务又耗时400毫秒，随后准备调用库存服务。为了避免下游完成时结果已对客户端无用，较合理的做法是（）。

一个大型多租户平台共享同一套应用和数据库资源。某个租户的异常流量耗尽公共连接池，导致所有租户同时不可用。若目标是把类似故障限制在一小部分租户内，较合适的架构方向是（）。

多个系统消费OrderCreated事件。生产者准备新增promotionCode字段，但部分旧消费者暂时无法同步升级。已知旧消费者能够忽略未知可选字段，较稳妥的演进方式是（）。

系统采用CQRS，写模型提交订单地址修改后，通过事件异步更新读模型。用户收到“修改成功”提示后立即刷新，却从读模型看到旧地址。既保留异步投影，又改善该用户读己之写体验的合理办法是（）。

进程P1取得分布式锁后发生长时间暂停，锁租约过期；P2随后取得新锁并完成写入。此时P1恢复，仍按旧任务继续向存储写数据。为了让存储端识别并拒绝P1的陈旧写入，较合适的机制是（）。

促销开始时，一个访问量极高的商品详情缓存刚好过期。数千个请求同时发现缓存未命中并查询数据库，数据库负载瞬间升高。较合理的核心治理方式是（）。

客户端提交支付请求后未收到响应，于是用相同业务参数重试。为避免服务端重复扣款，较合理的幂等设计是（）。

某下游服务连续超时后，调用端熔断器暂时快速失败，不再把请求发往下游。等待预设时间后，熔断器只允许少量请求试探服务是否恢复。此时处于（）。

某系统有两台可相互接管的应用节点，每台可用性均为0.95；只要其中一台正常，应用层就可用。应用层还依赖一台可用性为0.99的共享数据库。假设各组件故障相互独立、切换完全可靠，则系统总可用性约为（）。

流式处理系统中，生产者持续每秒产生 10 万条消息，消费者只能稳定处理 6 万条。若不希望队列无限增长并最终耗尽内存，较合理的机制是（）。

某只读查询服务部署了多个等价副本，绝大多数请求 80 ms 内完成，但少量请求会拖到 2 秒。团队计划使用 Hedged Request 降低尾延迟。较稳妥的做法是（）。

某 Event Sourcing 聚合已经积累数十万条事件，团队准备引入快照以缩短加载时间。较合理的做法是（）。

某复制系统共有 N=3 个副本，一次写入至少获得 W=2 个副本确认才成功，一次读取查询 R=2 个副本。关于该配置，正确的是（）。

订单服务需要同时写入本地数据库并向消息队列发布“订单已创建”事件。为减少数据库提交成功、消息发送失败造成的不一致，采用 Transactional Outbox 模式时，较合理的做法是（）。

某旅游平台的下单流程包括预订机票、预订酒店、生成订单和扣减优惠券。各步骤可以拆成多个本地事务，如果后续步骤失败，需要按业务补偿动作撤销前面已经完成的操作。另一个资金冻结场景要求先 Try 预留资源，再 Confirm 提交或 Cancel 取消。关于 Saga 和 TCC 的理解，较合理的是（）。

某电商系统中，商品、订单、推荐、评论等功能共用同一个线程池和连接池。促销期间推荐服务大量超时，占满公共资源，导致原本正常的下单接口也无法响应。架构师准备把不同业务能力的线程池、连接池和调用资源进行隔离，避免局部故障扩散。该设计思想更接近（）。

架构评审时，业务方只说“系统要高可用、响应快”。架构师进一步把需求写成：在促销高峰期，普通用户从移动端提交订单请求，订单服务在主库短暂抖动的环境下仍应返回明确结果，95% 请求在 2 秒内完成，失败请求进入可追踪补偿队列。这个写法主要是在补充（）。

某分布式缓存集群使用普通取模方式分配 key 到节点。每次新增或删除缓存节点时，大量 key 都会重新映射，造成缓存大面积失效。架构师希望节点变化时尽量只迁移少量 key，较适合采用（）。

某微服务调用下游库存服务时出现短暂超时。开发人员准备让所有失败请求立即无限重试，架构师认为这样可能在下游刚刚变慢时进一步放大压力，形成重试风暴。较合理的改进措施是（）。

某微服务系统对外需要统一入口，集中处理路由、认证、限流和协议转换；同时，服务之间的大量内部调用希望通过 Sidecar 代理统一处理熔断、重试、流量治理和可观测性。关于 API 网关和 Service Mesh 的分工，下列说法较合理的是（）。

某互联网系统上线新版本时，先让 2% 的用户访问新版本，观察错误率、延迟、订单转化等指标；若指标正常，再逐步扩大到 10%、30%、100%。这种发布策略更接近（）。

某微服务系统希望把数据库连接串、功能开关、限流阈值、第三方接口地址等运行配置集中管理，并支持按环境发布和必要时动态刷新。另一个组件则负责记录服务实例地址，供调用方找到可用服务。前者更接近（），后者更接近（）。

某订单系统通过消息队列异步通知积分服务。少量消息因为参数异常或下游服务错误，重试多次后仍无法成功处理。如果这些消息一直在主队列中反复重试，会影响后续正常消息消费。架构师希望把这类异常消息隔离保存，便于告警、排查和后续人工补偿。较合适的机制是（）。

某电商系统在秒杀开始后的几分钟内订单请求暴增，如果每个请求都同步写数据库和调用库存、支付等服务，下游系统很容易被瞬时流量压垮。架构师希望先把请求写入一个缓冲组件，再由后端消费者按可承受速率处理。较合适的设计是（）。

某图片和视频访问量很大的网站，把静态资源分发到离用户更近的边缘节点。用户访问时优先从边缘节点获取内容，只有未命中或内容过期时才回源站。该设计主要利用了（）。

某业务系统写入时需要严格校验业务规则和事务一致性，而查询侧需要面向报表、搜索和列表展示做复杂聚合。架构师将命令写入模型与查询读取模型分开设计，以便分别优化。该架构思想通常称为（）。

某电商系统中，商品服务、库存服务和推荐服务共享同一批调用线程。推荐服务偶发响应很慢时，大量线程被占用，商品和库存调用也被拖慢。架构师为不同下游服务配置独立线程池和容量限制，主要是为了实现（）。

某订单流程需要依次完成创建订单、扣减库存、扣款和发放权益。系统不希望长时间锁住多个服务的数据库，而是把大事务拆成一系列本地事务；如果后续步骤失败，则执行取消订单、恢复库存、退款等补偿动作。该思路更接近（）。

某微服务系统一次下单请求会经过网关、订单、库存、支付和通知等多个服务。用户反馈下单偶尔很慢，单看某一个服务日志很难判断时间耗在哪一段。为了把一次请求经过的服务、调用顺序和每段耗时串起来分析，较合适的能力是（）。

订单系统完成支付后，只发布“订单已支付”事件，库存、积分、通知等服务各自订阅该事件并独立处理。订单系统不需要同步调用每个下游服务，也不关心它们的内部实现。该设计主要体现了（）。

某系统上线新版本时，同时保留旧版本环境和新版本环境。流量先从旧环境切到新环境，如果新版本出现严重问题，可以迅速把流量切回旧环境。这种发布方式通常称为（）。

某微服务系统对外提供订单、库存、支付、会员等多个服务。架构师希望外部客户端不用分别了解每个服务地址，并希望在统一入口完成认证、路由、限流和日志记录。较合适的架构组件是（）。

第三方支付平台在未收到商户系统确认时，可能多次重试发送同一笔支付成功回调。如果商户系统每收到一次回调就重复发货或重复加款，风险很大。较合理的架构设计是（）。

某秒杀系统在活动开始前限制下单接口每秒最多接收一定数量的请求；另一个系统在下游库存服务连续超时后，暂时停止继续调用该库存服务，并返回兜底提示。上述两种措施分别更接近（）。

某电商系统中，攻击者不断请求大量根本不存在的商品 ID。由于缓存中查不到，数据库中也查不到，这些请求持续绕过缓存打到数据库，造成数据库压力升高。该现象更接近（）。

某微服务系统中，订单服务调用积分服务时经常超时，导致订单线程大量阻塞，进一步影响下单主流程。为了避免单个依赖故障拖垮整个链路，架构上较合适的措施是（）。

在分布式系统设计中，架构师讨论一致性、可用性和分区容错性之间的取舍。CAP 定理通常强调，在发生网络分区时，系统难以同时完全满足（）。

某 Web 系统访问量持续增长，单台应用服务器已经难以承受。架构师计划部署多台应用服务器，并把用户请求按策略分发到不同节点。该方案主要体现了（）。

某系统由两个必须同时正常工作的组件串联组成，组件 A 可用性为 0.99，组件 B 可用性为 0.98。假设两者独立，则系统总可用性约为（）。

某系统要求年可用率达到 99.9%。按一年 365 天、8760 小时粗略计算，该系统一年不可用时间约为（）。

在微服务架构中，服务实例数量和地址可能动态变化，调用方需要能够找到可用服务实例。用于解决该问题的机制通常称为（）。

某核心业务系统要求单个服务器故障时服务仍能继续对外提供能力。架构设计中更合适的措施是（）。

某大型业务系统被拆分为多个围绕业务能力构建的小服务，各服务可以独立开发、独立部署，并通过轻量级通信机制协作。这种架构风格通常称为什么？

某系统要求在部分节点故障时仍能继续对外提供服务，并尽量缩短故障恢复时间。该需求主要体现哪一种软件质量属性？

应用程序先查询缓存，缓存未命中时再访问数据库，并把查询结果写入缓存。后续请求优先从缓存读取。该模式通常称为什么？

分布式系统设计中，CAP 理论认为一致性、可用性和分区容错性三者在网络分区发生时通常不能同时完全满足。CAP 中的 P 指的是哪一项？

系统架构设计中，性能、可用性、安全性、可维护性等通常被称为什么？

将系统划分为表示层、业务逻辑层和数据访问层等层次，以降低耦合和提高可维护性，这属于哪种架构风格？