主题
后端
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
30 道问题
A · 专业解题与实现29
- 写代码和做代码评审时，你有哪些已经形成习惯的检查点，用来防止循环里查数据库、大对象长期不释放这类性能问题？你怎样知道它们真的有效？
- 请实现一个重试封装：调用外部服务失败时按规则重试，同时不让重试压垮对方。先说明接口，再写代码，并说明怎样让它在测试里可确定地运行。
- 缓存能让读取变快，也可能让用户看到过期内容。你会怎样判断一份数据适不适合缓存，出错时又怎样发现？
- 页面空闲一段时间后，第一次请求明显比之后的请求慢。从网络层面看，可能有哪些原因，你会怎样区分它们？
- 一条查询的过滤列上已经建了索引，却仍然很慢。请讲讲索引查找是怎么工作的，以及哪些情况会让它帮不上忙。
- 一个长时间运行的进程内存持续增长，但没人能指出明显的泄漏。你怎样区分真正的泄漏、正常的缓存增长和内存碎片？
- 服务现在用多线程处理请求，同事建议改成多进程。你会从哪些方面比较两者，什么情况下你会反对？
- 你的接口本地测试正常，联调时前端同学坚持说接口报错或没返回数据。你会用哪些手段去定位，又怎样拿出让对方信服的证据？
- 线上偶尔出现同一订单被提交两次，你在本地无法复现。你会怎样缩小范围，并决定先止血还是先补观测？
- 一个接口从昨天开始变慢，但没有任何发布记录。给你日志、监控和数据库慢查询记录，你会按什么顺序排查？
- 一个大型运营后台的权限系统应该怎样设计？角色、数据范围、审批和审计怎样组织，权限越来越多时怎样不失控？
- 怎样设计一个文章编辑和发布系统？草稿、审核、定时发布、多渠道分发和事后修改，状态和数据应该怎样组织？
- 付款后发券原本是同步执行，现在要改成异步队列加重试。请审查这个改动：你最担心哪些失败过程，上线前要演练什么？
- 怎样设计一个音频或视频的在线编辑器？时间线、素材、非破坏性编辑、预览和最终导出，各自应该怎样设计？
- 本地数据库已更新，但缓存同步或下游消息发送失败。你会如何确保状态最终一致，并设计重试、补偿或人工处理？
- 请设计一个支持大文件上传的产品能力。你会先澄清哪些约束，再怎样逐层展开？
- 怎样设计一个大模型对话系统？流式输出、多轮上下文、历史记录、中断和重试分别怎么处理，成本和延迟怎么控制？
- 在交易系统里，优惠券、满减和秒杀应该怎样接入，才不会拖慢核心交易流程？优惠怎样计算、叠加和对账？
- 消费者处理速度低于生产者，消息队列持续增长，但上游仍显示请求成功。你会怎样确定控制上游发送速度应作用在哪一层，并保护系统恢复能力？
- API 延迟升高时数据库 CPU 很低，但应用日志出现等待连接。你会如何区分连接泄漏、池容量不足和慢事务占用？
- 支付创建接口需要支持安全重试。你会怎样定义防止重复扣款的请求标识，包括它的作用范围、保存期限和冲突处理规则？
- 订单写入数据库后需要发布事件给下游；进程可能在任一步骤崩溃。你会怎样设计持久化发布机制，并说明如何处理重复与顺序？
- 管理后台按创建时间翻页时，新增和删除会让用户看到重复或漏项。你会比较 offset 与游标分页，并定义何种一致性预期？
- 一个 API 部署在多个实例后，单机请求限制使总额度随实例数增加。你会根据突发容忍度、精度和故障策略设计请求速率限制，并说明状态放在哪里？
- 请实现一个支持并发读写、按条目过期并可清理过期数据的映射。你会如何定义过期语义、同步边界和确定性测试？
- 实现一个逐块接收 UTF-8 数据的增量日志解析器：输入块可能截断多字节字符、字段顺序变化，也可能包含多条记录或超长单行。请定义解析状态、错误恢复策略和内存上限，并实现可重复解析的核心逻辑。
- 一个服务被声明为单例后，不同用户请求偶尔读到彼此的临时状态。你会如何解释依赖注入生命周期与请求作用域，并设计安全的对象边界？
- 加入鉴权、日志和异常处理中间件后，部分错误没有 trace id，且未授权请求仍触发昂贵的解析逻辑。你会如何分析执行顺序并重新安排边界？
- 服务平均耗时稳定，但最慢 1% 的请求会周期性变慢，时间点与内存分配高峰接近。你会如何判断垃圾回收是否是原因，并区分其他暂停来源？
当前目标在这里暂无匹配题。 ·