岗位
后端
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
1216 道问题
本页为第 151–200 题，共 1216 题。
A · 专业解题与实现34
- 构建仓库需要清理多年积累的镜像，但线上仍有服务依赖旧版本回滚。你会如何确定保留策略和制品可恢复要求？
- 两个线程通过一个标志位传递“数据已准备好”的信号。为什么仅把标志位声明为原子类型仍可能不足以保证数据可见？
- 管理后台需要保留不可随意修改的操作记录，既支持按操作者和对象查询，也要应对数据量逐年增长。你会怎样设计写入、索引和保留策略？
- 消费者处理速度低于生产者，消息队列持续增长，但上游仍显示请求成功。你会怎样确定控制上游发送速度应作用在哪一层，并保护系统恢复能力？
- API 延迟升高时数据库 CPU 很低，但应用日志出现等待连接。你会如何区分连接泄漏、池容量不足和慢事务占用？
- 支付创建接口需要支持安全重试。你会怎样定义防止重复扣款的请求标识，包括它的作用范围、保存期限和冲突处理规则？
- 订单写入数据库后需要发布事件给下游；进程可能在任一步骤崩溃。你会怎样设计持久化发布机制，并说明如何处理重复与顺序？
- 管理后台按创建时间翻页时，新增和删除会让用户看到重复或漏项。你会比较 offset 与游标分页，并定义何种一致性预期？
- 一个 API 部署在多个实例后，单机请求限制使总额度随实例数增加。你会根据突发容忍度、精度和故障策略设计请求速率限制，并说明状态放在哪里？
- 某存储服务从读多写少变成持续高写入，团队在 B 树和 LSM 路线间评估。你会根据哪些负载特征比较两者，并关注哪些读写放大代价？
- 多核程序中两个线程各自修改不同字段，性能却随核心数增加而下降。请解释缓存行共享可能怎样造成这种现象，以及代码层面如何验证。
- 组织要把多个仓库从旧的自动构建与检查平台迁到新平台，但团队不能同时停下交付。你会怎样分批迁移，并判断哪些仓库可以进入下一批？
- 用户通过外部链接直接打开需要登录的订单详情页。你会怎样设计路由解析、登录回跳和权限校验，避免深链绕过应用内流程？
- 请实现一个支持并发读写、按条目过期并可清理过期数据的映射。你会如何定义过期语义、同步边界和确定性测试？
- 实现一个深度相等函数，输入可能包含嵌套数组、共享引用和循环引用。请先定义相等语义，再说明如何避免无限递归与错误地混淆引用结构。
- 实现一个小型任务队列，支持并发 worker、任务取消和失败重试；测试不能依赖真实 sleep。你会怎样设计调度接口和状态转换？
- 实现一个逐块接收 UTF-8 数据的增量日志解析器：输入块可能截断多字节字符、字段顺序变化，也可能包含多条记录或超长单行。请定义解析状态、错误恢复策略和内存上限，并实现可重复解析的核心逻辑。
- 一个服务把工作线程数从 16 提到 256 后，吞吐没有提升，CPU 使用率反而更高。你会怎样解释上下文切换可能造成的影响，并用什么证据验证？
- 数据库字段变更完成后，只有部分下游任务间歇性失败。你会怎样找出仍在使用旧接口约定的消费者，并确定回滚还是兼容修复？
- 对账任务发现同一业务对象的事件时间顺序偶尔倒置，日志又分布在多个区域。你会如何判断是时钟偏差、异步延迟还是业务排序规则的问题？
- 月度汇总与明细报表最初一致，几周后差异逐渐扩大。你会如何把问题缩小到规则变更、迟到数据、重复处理或历史回补？
- 一个关键依赖只在某个区域间歇性超时，整体健康检查仍显示正常。你会如何判断影响面，并安全地隔离或临时关闭非核心功能？
- 消息积压经常在扩容后下降，几小时后又反弹。你会检查哪些生产者、消费者和消息特征，以判断真正瓶颈在哪里？
- 服务平均耗时基本不变，但最慢 1% 的请求连续一周变慢，投诉集中在少数大客户。你会如何定位问题并决定先验证什么？
- 设计一个供多个业务团队提交“在某个时间之后执行”的任务服务，任务可能被取消、改期或重复提交。你会怎样划分数据模型和执行组件？
- 数百个仓库都锁定了不同版本的第三方依赖，安全团队发现高危漏洞时很难知道影响范围。你会怎样建立依赖更新和风险处置机制？
- 服务已经切到新地址，一些用户仍连着旧节点，不同网络的恢复时间也不同。你会怎样检查 DNS 缓存、客户端缓存和现有连接？
- 一个缺陷只在线上出现，开发和预发环境都无法复现。你会如何判断问题来自环境差异、流量形态还是数据特征，并改进环境设计？
- 多个服务在请求路径中读取功能开关和分群规则。如何设计控制面与本地求值，让控制服务故障时线上行为仍然可预期？
- 一个关键完整流程测试偶尔失败，团队开始重跑直到通过。你会怎样确定它是否真实暴露产品风险，并改进测试流程？
- 一个服务被声明为单例后，不同用户请求偶尔读到彼此的临时状态。你会如何解释依赖注入生命周期与请求作用域，并设计安全的对象边界？
- 加入鉴权、日志和异常处理中间件后，部分错误没有 trace id，且未授权请求仍触发昂贵的解析逻辑。你会如何分析执行顺序并重新安排边界？
- 用户更新后偶尔加载到新 HTML 和旧 JavaScript，页面因此报错。你会怎样设计静态资源命名、缓存策略和发布顺序来降低不一致？
- 服务平均耗时稳定，但最慢 1% 的请求会周期性变慢，时间点与内存分配高峰接近。你会如何判断垃圾回收是否是原因，并区分其他暂停来源？
当前目标在这里暂无匹配题。 ·
B · 业务理解与领域建模16
- 一个质量检查偶尔误报，导致下游任务停摆；取消检查又曾让错误数据进入结算。你会怎样设计分级处置？
- 同一账号可能同时拥有基础套餐、临时试用、活动权益和客服补偿。各系统对优先级的实现不一致，客户看到的权限偶尔反复变化。你会怎样定义资格与冲突规则？
- 一个模型特征将停止生产，但多个在线模型和历史报表仍依赖它。你会怎样安排退役与替代？
- 一个在线特征需要每秒更新，但它只影响少量请求，且维护成本持续上涨。你会怎样判断是否继续实时计算？
- 一个风险模型使用后续违约作为训练标签，但许多交易在观察窗口结束前没有最终结果。你会怎样处理标签成熟度、样本纳入和回溯评估？
- 为一个预测用户次日是否流失的模型构造“近 7 天活跃天数”特征。你怎样定义这个特征的时间语义，使训练时和线上预测时拿到的是同一个含义？
- 订单上有一个 status 字段，同时表示履约进度和支付结果，多个团队都在读它。你会怎样把它拆成两个概念，并让旧数据和旧使用方平稳过渡？
- 一个服务资格判断从“当前账户状态”改为“申请时的账户状态加风险审核结果”。客服需要解释历史拒绝原因，审计也要求复现当时的判断。你会怎样演进规则和数据模型，避免新旧结果混为一谈？
- 重复注册导致两个客户实体后来被确认属于同一家公司。合并后报表要统一展示，但历史合同、审批、权限和个人操作仍需保留原始责任。你会怎样设计合并关系？
- 客服工单关闭后，客户补充新证据时可以重新打开，有时还会拆成多个跟进事项。你会怎样设计状态与事件，让关闭、重开和拆分都可追溯？
- 业务规则发生追溯更正，报表需要显示修正后的结果，但决策者还要查看当时依据的旧结果。你会怎样管理两种历史视图？
- 生产者新增一个订单状态后，旧消费者因严格枚举校验拒绝整条消息。团队认为应由消费者更新，但多个消费者由不同组织维护。你会怎样设计兼容性和发布顺序？
- 企业合同分别约定首次响应、恢复服务和最终解决时间，暂停计时条件也不同。客服系统只记录一个计时器，导致争议。你会怎样分别记录这些承诺及其计时规则？
- 请为你长期负责的方向画一份业务地图：用户要完成什么任务、流程中主要障碍在哪里、你的模块能影响什么又影响不到什么？
- 请为一位刚加入的同事写一页产品概览。你会怎样标记哪些陈述是事实、哪些是推断、哪些只是尚未回答的问题？
- 你做的项目在整体业务里处在什么位置？谁给它提供输入，谁使用它的结果？如果它延后或做错了，谁会受影响？
当前目标在这里暂无匹配题。 ·