第五篇 工程化与后端基础（必背保底分）

第五篇 工程化与后端基础必背保底分本篇定位AI应用开发岗的工程基础必考题占面试分值约20%是保底拿分的核心模块。所有AI系统最终都要落地为软件工程本篇章摒弃纯后端八股重点讲解与RAG、Agent场景强相关的工程技术兼顾基础原理与落地实践。5.1 Redis核心应用核心题1Redis在Agent/RAG系统中的四大核心用途是什么背诵要点Redis是AI应用系统的标配组件核心承担四大角色会话状态缓存存储Agent多步任务的中间状态、对话历史、执行进度支持断线重连、断点续跑用户刷新页面无需从头执行典型场景长流程Agent任务、多轮对话记忆LLM响应缓存缓存高频重复问题的答案、Embedding向量、召回结果大幅降低Token消耗提升响应速度典型场景FAQ问答、标准查询、重复度高的生成任务接口限流基于原子计数器精准控制LLM API调用频次、用户请求频次防止突发流量耗尽预算、触发第三方限流典型场景大模型API配额管控、多租户限流分布式锁多Agent实例同时操作同一资源时避免并发冲突、数据错乱典型场景共享文档编辑、同一份数据的并发修改、任务调度防重复核心题2Agent开发常用的Redis数据结构有哪些分别对应什么场景背诵要点掌握4种核心数据结构即可覆盖90%以上的AI场景String字符串场景缓存单值答案、存储限流计数器、分布式锁优势最简单通用支持过期时间Hash哈希场景存储会话完整状态、用户配置、Agent任务信息优势可单独修改某个字段不用整体读写List列表场景存储对话历史消息、简单消息队列、任务排队优势有序支持首尾操作适合按时间顺序的序列数据Sorted Set有序集合场景带权重的任务排序、热点问题排行榜、延时任务优势自动按分数排序适合优先级场景核心题3Redis内存持续增长不释放怎么解决内存淘汰策略有哪些背诵要点完整治理方案设置maxmemory最大内存上限防止无限增长导致OOM配置合理的内存淘汰策略内存达上限时自动清理所有业务Key必须设置过期时间TTL永久Key严格管控过期时间加随机偏移避免大量Key同时过期引发缓存雪崩治理大Key拆分过大的Hash、List、String冷热数据分离冷数据落地到磁盘数据库8种内存淘汰策略三大类不淘汰noeviction内存满后新写入直接报错数据不能丢的场景用全量Key范围淘汰allkeys-lru淘汰最近最少使用生产最常用allkeys-lfu淘汰使用频率最低allkeys-random随机淘汰仅过期Key范围淘汰volatile-lru/volatile-lfu/volatile-random/volatile-ttl核心题4缓存雪崩、缓存穿透、缓存击穿是什么怎么应对背诵要点缓存雪崩现象大量Key同时过期请求全部打向后端压垮下游应对过期时间加随机值分散过期时间、多级缓存、服务降级缓存穿透现象查询不存在的数据缓存永远不命中请求全部穿透到后端应对空值缓存、布隆过滤器、参数合法性校验缓存击穿现象单个热点Key过期瞬间大量并发请求打向后端应对互斥锁、热点数据永不过期、后台异步更新高频追问Redis过期策略和淘汰策略有什么区别过期策略删除已经到了过期时间的Key有定期删除惰性删除两种淘汰策略内存达到maxmemory上限时主动清理部分Key腾空间两者是不同机制共同保障Redis内存可控分布式锁怎么实现有哪些注意事项基础实现SETNX加锁 设置过期时间必须原子操作注意事项锁的唯一标识、过期时间合理、释放锁只能释放自己加的锁进阶Redisson框架支持可重入锁、看门狗续期大Key有什么危害怎么处理危害读写慢、阻塞线程、内存不均、删除卡顿处理拆分大Key为多个小Key、压缩内容、异步删除AI场景常见把整个对话历史、大段生成结果存在单个Key里5.2 数据库选型与优化核心题1AI应用项目怎么选数据库各类型适用场景是什么背诵要点按场景选型不盲目追新MySQL优势国内普及率最高、生态成熟、运维资料多适用用户信息、对话历史、任务记录、配置等结构化数据建议存量系统已有MySQL基建的项目优先复用PostgreSQL优势功能丰富自带JSONB类型支持非结构化数据可加装pgvector做向量检索适用从零起步的新项目、需要同时存结构化非结构化向量的场景建议新项目优先选长远扩展性更好SQLite优势轻量嵌入式单文件数据库无需启动服务适用本地Demo、命令行工具、单机运行的AgentMongoDB优势文档型数据库灵活存储非结构化JSON数据适用Agent中间状态、工具调用返回结果等 schema 不固定的数据TiDB优势国产分布式数据库兼容MySQL协议支持水平扩展适用大规模用户、海量数据的Agent平台中大型团队核心题2MySQL索引按底层结构分哪几类BTree索引有什么特点背诵要点两大类索引BTree索引InnoDB默认最核心最常用结构多路平衡查找树非叶子节点存索引键叶子节点存完整数据/主键特点树高低磁盘IO少叶子节点用双向链表串联天然支持范围查询、排序、分组分类聚簇索引主键索引叶子存整行数据、二级索引叶子存主键值需要回表Hash索引Memory引擎默认结构哈希表键值映射特点等值查询极快但不支持范围查询、排序、模糊匹配有哈希冲突问题核心题3慢查询怎么排查和优化背诵要点标准化排查流程定位慢SQL开启慢查询日志找到执行时间长的SQL语句分析执行计划用explain查看执行计划重点看type列是否全表扫描ALL有没有走索引rows列扫描的行数是不是过多Extra列有没有Using filesort、Using temporary针对性优化索引缺失给查询条件、关联条件、排序字段建合适的索引索引失效避免索引列上用函数、隐式类型转换、模糊查询前导通配符SQL优化减少不必要的关联、避免select *、分页优化架构优化读写分离、分库分表、数据冷热分离核心题4pgvector是什么和专业向量数据库比有什么优劣背诵要点pgvector是PostgreSQL的向量检索扩展能让关系型数据库直接存储和查询向量优势复用现有PostgreSQL基建不用新增组件降低运维复杂度事务一致性好向量和结构化数据同库关联查询方便支持过滤向量混合查询权限、条件筛选原生支持劣势向量检索性能弱于Milvus等专业向量库亿级以上规模性能下降明显向量索引类型较少高级特性不足适用场景中小规模RAG系统、已有PG基建、向量数据量百万级以内高频追问聚簇索引和非聚簇索引有什么区别聚簇索引索引和数据在一起叶子节点存整行数据一个表只有一个查询速度快非聚簇索引索引和数据分离叶子节点存主键值需要回表一个表可以有多个InnoDB主键是聚簇索引普通二级索引是非聚簇索引什么是回表怎么减少回表回表通过二级索引找到主键后还要再去聚簇索引查完整数据减少回表覆盖索引把需要查询的字段都包含在索引里不用回表AI场景只查对话ID、标题等少量字段时可用覆盖索引优化MongoDB和MySQL怎么选结构化、事务要求高、关系复杂选MySQL数据结构不固定、非结构化、多嵌套、事务要求低选MongoDBAI项目通常两者结合核心业务数据用MySQL中间状态、日志类用MongoDB5.3 消息队列选型与应用核心题1Agent系统为什么需要消息队列解决什么核心痛点背诵要点核心解决同步执行的三大痛点异步解耦大模型调用、工具执行往往耗时几秒到几十秒同步等待用户体验极差接入队列后用户提交任务立刻返回“处理中”后台异步执行完成后再通知削峰填谷突发流量时请求进入队列排队避免瞬间打垮大模型API和下游服务保护系统稳定性防止流量突增导致服务雪崩可靠重试任务执行失败可自动重试提升任务成功率消息持久化服务重启后任务不丢失系统解耦Agent和下游工具、服务通过队列解耦可独立迭代、独立扩容核心题2主流消息队列怎么选型各自适用场景是什么背诵要点四款主流选型按需对号入座Redis Streams / BullMQ定位轻量首选基于Redis实现优势不用额外部署组件维护成本低开箱即用适用个人/小团队项目、已有Redis基建、轻量级Agent任务RabbitMQ定位经典通用成熟可靠优势支持复杂路由规则投递可靠消息不丢失适用需要精准任务分发、多类型Agent分工、对可靠性要求高的中小团队RocketMQ定位国产首选阿里开源优势高吞吐、分布式场景表现好Java生态适配极佳阿里云有全托管服务适用Java技术栈、中大型团队、高吞吐业务场景Kafka定位大规模事件流处理优势超高吞吐适合海量日志、事件流适用Agent行为日志分析、大规模数据同步、决策回溯调试常规Agent项目偏笨重选型口诀已有Redis选BullMQJava栈选RocketMQ可靠投递选RabbitMQ日志流处理选Kafka。核心题3消息队列怎么保证消息不丢失背诵要点三段式保障生产端确认机制发送后等待Broker确认返回失败自动重试事务消息确保业务执行和消息发送的一致性Broker端持久化消息写入磁盘服务重启不丢失多副本集群多节点备份单节点故障不丢数据消费端手动确认业务处理完成后再提交确认没处理完的消息会重新投递幂等处理防止重复消费导致业务异常高频追问消息重复消费怎么处理根本方法业务侧做幂等设计同一条消息执行多次结果一致实现方式唯一消息ID去重、数据库唯一键、业务状态校验AI场景常见同一个Agent任务重复执行要避免重复生成、重复写数据消息积压了怎么排查和处理排查先看消费速度是不是变慢了是不是下游故障是不是流量突增紧急处理临时扩容消费者、降级非核心任务、丢弃不重要的消息长期优化优化消费逻辑、扩容集群、优化限流策略什么时候用消息队列什么时候直接同步调用耗时短、实时性要求高、必须立刻返回结果同步调用耗时长、用户不需要立刻等结果、可异步处理用消息队列需要削峰、解耦、重试用消息队列5.4 全链路性能排查核心题1前端请求超过3秒全链路怎么排查原因背诵要点按链路从上到下分层定位先定大环节再挖细节前端与网络层F12看Network面板TimingDNS、TCP、SSL、TTFB、下载各阶段耗时TTFB高 → 后端问题内容下载慢 → 响应体太大/带宽问题DOM渲染慢 → 前端问题排查跨域、CDN、弱网等因素应用服务层关键节点加耗时埋点用Trace ID串联全链路定位具体哪个步骤慢参数校验、业务逻辑、缓存、数据库、外部调用排查线程池、连接池是否耗尽请求是否在排队缓存层Redis排查大Key、慢查询、连接池耗尽、网络延迟数据库层查慢查询日志定位慢SQLexplain分析执行计划排查索引失效、全表扫描、锁等待外部依赖层排查第三方接口、大模型API的耗时和可用性检查是否没设超时导致线程长时间阻塞核心题2大模型调用超时、不稳定怎么处理背诵要点AI项目特有高频问题五层应对方案超时控制设置合理的超时时间分首字超时和整体超时超时后快速失败不阻塞业务线程重试机制网络波动、偶发错误自动重试配合指数退避注意有副作用的操作不能随意重试降级兜底配置主备多模型主模型超时自动切备用模型极端情况返回兜底话术保证服务可用异步化长耗时任务改成异步队列模式不阻塞用户配合进度推送、结果回调通知用户就近部署业务服务和模型服务同可用区部署减少网络延迟国内业务优先选国内大模型避免跨境网络波动核心题3线程池、连接池耗尽怎么排查和优化背诵要点常见表现接口耗时整体变长CPU不高但请求都在等待吞吐量上不去排查方法查看线程池/连接池的活跃数、等待队列长度打线程栈看线程都阻塞在什么地方定位是下游慢导致占用久还是池大小设置不合理优化方案先优化下游慢调用减少单任务占用时间这是根本合理调整池大小不是越大越好根据CPU核数和IO比例调整设置合理的超时和拒绝策略避免无限排队拖垮系统异步化、降级非核心业务释放核心资源高频追问接口响应慢CPU和内存都不高可能是什么原因IO阻塞数据库慢、外部接口慢、锁等待、连接池阻塞线程阻塞线程池满了请求排队网络延迟服务间调用、跨机房、跨境网络慢怎么快速判断是前端问题还是后端问题看TTFB首字节时间TTFB高基本是后端问题用Postman等工具直接调接口排除前端影响看服务器日志请求到服务端的时间到返回的时间就是后端耗时第三方依赖不可用会导致什么问题怎么预防问题线程阻塞、服务雪崩、整个接口不可用预防设置超时、熔断降级、异步解耦、备用方案AI项目尤其要注意大模型API不可用不能拖垮整个业务系统5.5 容器化与部署核心题1Docker在AI应用开发中的核心作用是什么背诵要点两大核心价值第二点是AI场景特有环境一致性打包所有组件和依赖任何环境运行状态一致解决“本地能跑生产跑不通”的环境适配问题一套Agent系统包含服务、Redis、数据库、消息队列等多个组件用Docker可一键部署代码执行沙箱Agent自动生成并运行代码时直接在宿主机执行有极高安全风险Docker容器实现资源隔离可限制CPU、内存禁止网络访问限时自动销毁就算生成恶意代码也无法影响主系统是代码执行类Agent的安全标配核心题2Docker Compose有什么用适用什么场景背诵要点作用用一份YAML文件定义所有服务Agent服务、Redis、数据库、消息队列等一条命令就能启动/停止整套系统价值不用手动逐个启动组件、配置网络本地开发、测试环境效率极高适用场景本地开发环境、单服务器部署、小型测试环境生产环境一般不用Docker Compose用K8s或云托管服务做编排核心题3代码执行沙箱有哪些方案怎么选型背诵要点三种主流方案适配不同场景Docker容器沙箱优势隔离彻底可精细限制CPU、内存、网络、磁盘劣势启动慢、资源占用高适用重任务、长时间运行、对隔离要求极高的场景Wasm沙箱优势启动极快毫秒级、资源占用极低、安全性好劣势支持的语言和能力有限适用轻量代码执行、高并发、短任务场景是当前的主流演进方向Serverless函数优势天然隔离、免运维、弹性扩容劣势冷启动延迟、成本较高适用调用频率波动大、不想运维沙箱集群的场景核心题4什么时候需要用KubernetesK8s背诵要点不是所有项目都需要上K8s满足以下需求再考虑需要服务自动扩缩容用户量波动大服务实例多需要统一编排、滚动发布、故障自愈微服务架构多服务协同部署中小规模项目、单实例能扛住的场景不用盲目上K8s徒增运维成本国内主流用法直接用阿里云ACK、腾讯云TKE等托管K8s服务不用自己搭建集群高频追问Docker和虚拟机有什么区别Docker是容器级共享宿主机内核体积小、启动快、资源占用低虚拟机是硬件级有完整的操作系统体积大、启动慢、隔离更彻底应用部署用Docker足够完全隔离的场景才用虚拟机国内用Docker有什么常见坑怎么解决最大的坑Docker Hub国内访问不稳定拉镜像慢或失败解决配置国内镜像源比如阿里云、腾讯云的容器镜像加速建议项目初期就配置好能省大量调试时间Agent服务部署有哪些注意事项无状态设计方便水平扩容状态存在外部Redis/数据库实例重启不丢失配置外置不要硬编码API Key等敏感信息做好资源限制防止大模型调用占用过多资源5.6 可观测性体系核心题1为什么AI系统需要专门的可观测性工具和普通日志有什么区别背诵要点Agent行为链路长接收指令→思考→调工具→处理结果→再思考→再调工具→生成回复普通日志只能看到零散的输出无法直观还原完整决策链专用Trace工具可以可视化展示完整执行过程每一步的Prompt、模型返回、调用的工具、工具结果、Token消耗、耗时排查问题效率比翻原始日志高10倍是生产级Agent系统的必备能力核心题2LLM可观测工具有哪些怎么选型背诵要点主流两款核心工具Langfuse定位开源首选支持自建部署优势数据不出境符合国内数据安全要求功能全面支持Trace、评估、成本统计适用国内企业级生产环境是当前社区推荐度最高的方案LangSmith定位LangChain官方平台和LangChain生态深度集成优势原生适配、体验好、功能强劣势数据需要传到海外服务器国内合规场景有顾虑补充如果用Dify等低代码平台自带日志监控能满足基础需求不用额外引入核心题3通用监控体系怎么搭建核心监控哪些指标背诵要点业界标准方案Prometheus GrafanaPrometheus负责采集各类指标数据Grafana负责把指标画成可视化仪表盘直观展示服务状态AI系统核心监控指标业务指标调用量、对话数、任务成功率、错误率性能指标平均响应耗时、首字延迟、吞吐量成本指标Token消耗量、日均调用成本、模型配额使用率资源指标CPU、内存、磁盘、连接池水位、队列堆积配套告警关键指标异常时自动通知及时发现故障核心题4结构化日志怎么设计有什么要求背诵要点核心要求统一JSON格式输出不要用零散的print必备字段时间戳精确到毫秒Trace ID串联一次完整请求的所有步骤全链路统一步骤类型模型调用、工具执行、检索、生成等输入输出关键入参出参便于排查耗时、Token数、错误信息落地建议中小团队直接用云厂商日志服务阿里云SLS、腾讯云CLS大规模团队自建ELK栈ElasticsearchLogstashKibana高频追问Trace ID有什么用怎么传递作用把一次请求的全链路日志串联起来排查问题时能看到完整流程传递请求入口生成全程透传跨服务、跨工具调用都要带上AI场景尤其重要Agent多步调用、多工具调用靠Trace ID串起完整决策链线上出了问题标准排查流程是什么第一步看监控告警先定位是哪个环节、哪个服务出问题第二步用Trace ID查完整链路日志定位具体错误和异常第三步复现问题根因分析修复验证第四步复盘优化补充监控和测试用例避免再发可观测性三件套是什么日志Logging记录离散事件排查错误详情指标Metrics聚合统计数据看整体趋势和告警链路追踪Tracing串联单次请求全链路看性能瓶颈和流程三者结合构成完整的可观测体系