场景八股分析

异常解决

1.就比如说你这个部署到线上了，然后他抛了一个异常，然后那你这个应该怎么排查呢

线上出现异常，我会遵循一套从宏观到微观、由表及里的排查SOP（标准作业程序）来定位和解决问题。

第一步：信息收集与初步判断

  1. 确认影响范围：首先，快速判断这个异常的影响面有多大。是影响了所有用户，还是部分用户？是核心功能还是边缘功能？这决定了问题的紧急程度。

  2. 查看监控告警：立即查看监控系统（如Prometheus/Grafana, Zabbix）的告警信息。检查应用的

    关键指标，如：

    • 应用层面：QPS、响应时间（RT）、错误率（Error Rate）是否突增？
    • JVM层面：CPU使用率、内存占用、GC活动是否异常？
    • 主机层面：服务器的CPU、内存、磁盘I/O、网络流量是否正常？
    • 依赖服务：数据库、Redis、MQ等中间件的健康状况如何？
    • 这一步的目标是快速定位问题是出在应用本身，还是外部依赖。

第二步：日志分析与精准定位

  1. 聚合日志平台检索：登录ELK（Elasticsearch, Logstash, Kibana）或类似日志平台，根据告警信息中的时间点、错误信息关键字（如RuntimeException）进行检索。
  2. 利用Trace ID进行链路追踪：如果系统接入了分布式追踪系统（如SkyWalking, Zipkin），这是最强大的工具。我会根据报错信息找到一个Trace ID，然后用这个ID查询完整的请求调用链。这可以清晰地看到请求经过了哪些服务，在哪一个环节耗时最长，又是在哪个服务的具体代码行抛出了异常。
  3. Linux服务器手动排查（作为补充）：如果日志平台不完善，我会登录到具体的服务器上进行排查。
    • 使用grep命令根据关键字快速过滤日志：grep -C 10 'ExceptionNameToFind' /path/to/app.log。-C 10可以显示异常上下文的10行，帮助理解问题背景。
    • 如果需要根据Trace ID查，我会用：grep 'your-trace-id' /path/to/app.log。
    • 对于实时滚动的日志，我会用tail -f /path/to/app.log | grep 'ERROR'来实时监控错误输出。

第三步：根因分析与问题复现

  1. 代码分析：定位到具体的异常代码后，分析代码逻辑，判断是业务逻辑错误、空指针、并发问题还是资源未释放等。
  2. 环境复现：如果可能，尝试在测试环境或预发环境，构造相同的参数和条件，复现这个问题，以便于调试和验证修复方案。

第四步：问题解决与复盘

  1. 紧急修复：如果是严重Bug，立即进行Hotfix修复并上线。如果是资源问题，进行扩容或配置调整。
  2. 复盘总结：问题解决后，必须进行复盘。分析问题发生的根本原因，是代码缺陷、设计不合理、还是容量预估不足？并制定改进措施，例如增加单元测试、完善监控告警、优化架构等，防止同类问题再次发生。

2.考察线上问题排查

  • 第一步：紧急止血（恢复服务优先）。
  • 第二步：定位根因（Root Cause）。

  • 第三步：复盘总结（避免再犯）。

  • \1. 看监控，定范围：

    • 看应用自身监控： 接口的 QPS、P99 响应时间、JVM（GC次数/时间、线程数）、线程池监控（队列长度、活跃线程数）。首先确认是自身应用的问题还是外部问题。
    • 看主机监控： CPU 使用率、内存占用、网络 I/O、磁盘 I/O。确认是不是机器资源被打满了。
  • \2. 分析线程，找瓶颈：
    • 使用 jstack 命令 dump 线程堆栈。分析是否有大量线程处于 BLOCKED 状态（锁竞争）、WAITING 状态（等待外部资源，如 HTTP 调用、数据库连接）。这是定位问题的最核心手段。
  • \3. 查GC，判影响：
    • 使用 jstat -gcutil 查看 GC 情况。确认是否发生了频繁的 Full GC，导致 STW（Stop-The-World），从而影响接口响应。
  • \4. 查依赖，判外部：
    • 检查所有下游服务（RPC 调用）的响应时间。是不是某个下游服务变慢，拖垮了你。
    • 检查数据库和缓存（Redis）的慢查询日志和响应时间。是不是因为慢 SQL 或 Redis 大 Key 导致的阻塞。
  • \5. 看网络，做补充：
    • 如果以上都正常，再考虑网络问题，比如丢包、重传等。

恢复手段：

  • 重启大法： 最简单粗暴但有效。
  • 服务降级： 通过配置中心，暂时关闭一些非核心功能。
  • 服务限流： 立即调低接口的 QPS 阈值，避免被流量打垮。
  • 扩容： 如果是资源不足，立即进行水平扩容。

3.线上问题卡顿

提出了一个“自顶向下”的排查思路：先通过监控工具（宝塔）看服务器资源（CPU、内存），定位到具体程序，再通过程序的日志（Docker日志）定位到具体组件和代码异常。

Linux 命令行工具（如 top, jstack, jmap）的提及。对于一个硬核的技术面试，面试官更希望听到你如何使用这些底层工具进行排查。此外，排查的维度不够全面，没有考虑到网络问题、数据库慢查询、下游服务拖累等常见原因。

AI

1.设计一个可扩展的架构，并说明如何实现 1-2 秒 P95 的延迟指标。

召回、重排、向量库更新、上下文窗口管理、长对话状态持久化，以及延迟预算分配几个维度，

RAG 的核心流程：文档切分 -> 向量化入库 -> 用户问题向量化 -> Top K 相似度检索 -> 结果送入 LLM 生成答案。RAG 是为了解决 LLM 没有“记忆”和无法利用私有知识的问题。

  • 召回（Recall）： 你只提到了向量相似度检索。但一个生产级的 RAG 系统，召回层通常是混合检索，比如 向量检索 + 关键词检索（如 BM25），以应对不同类型的问题。
  • 重排（Rerank）： 你提到了重排模型，但没有说明它的作用。Rerank 模型（如 Cohere Rerank）通常是一个轻量级的交叉编码器模型，它会对召回的 Top N（比如 N=50）个文档，进行更精细化的相关性打分，再选出最终的 Top K（比如 K=5）送给 LLM，能显著提升最终答案的质量。
  • 向量库更新： 这是一个工程难题，你完全没有提及。如何处理知识的增量更新、修改和删除？是定期全量重建索引，还是采用支持实时更新的向量数据库？

时间分配：

  • 用户问题预处理：50ms
  • 向量化（Embedding）: 100ms
  • 向量检索（Recall）: 150ms
  • 重排（Rerank）: 200ms
  • LLM 生成（Generation）: 1000ms (这是大头)
  • 网络开销等：500ms 然后你需要思考如何优化每个环节。比如，Embedding 模型和 Rerank 模型需要选择轻量级、高性能的版本；向量检索需要对索引进行优化（如 HNSW 索引的参数调优）；LLM 需要采用流式输出（Streaming），让用户能更快地看到第一个 Token。