北京纷享销客面经

一、基础信息与项目背景 请做一个简单的自我介绍，并重点阐述你近期正在开展的工作内容。 你简历上提到的算法竞赛奖项具体是什么？你的英语水平如何？ 你目前的实习诉求是什么？为什么想找实习？ 你这个项目的来源是什么？是独立完成还是团队合作？你在团队中具体负责哪部分？ 你的简历是否是AI生成的？你是如何撰写这份简历的？ 你们团队规模多大？这个项目占团队工作量的百分之多少？ 二、后端架构与并发控制 请解释 single flight 机制，它在什么经典场景下使用？ 在你的项目中，single flight 是如何做到复用相同AI请求以节省 token 的？ 为什么使用 Redis Lua 脚本？它解决了什么问题？ 为什么分布式锁无法满足你的业务场景需求？ 你如何处理请求超时或失败的情况？请说明你的错误分类策略。 当 owner 节点宕机后，你是如何解决"脑裂"导致的状态冲突问题的？ 你引入了什么版本校验机制来保障数据一致性？ 三、性能压测与极端场景 你展示的 P95 等数据是压测结果吗？如果不是，你的常规化恢复方案的时间成本和数据量是多少？ MongoDB 在你的业务中存储的是什么数据？数据量大概多大？ 如果数据量膨胀到几百兆的极端情况，你的方案如何应对？ 如果缓存失效，同时触发大量并发恢复请求，你如何处理？ 你提出的基于优先级的请求聚合方案具体是如何实现的？聚合条件是什么？ 你的请求聚合方案如何避免重复恢复？最终实际会发出几次请求？ 并发恢复状态时如果发生冲突，你的快照版本号和幂等机制是如何设计的？ 在高并发场景下，你的方案还有哪些防御性设计？ 四、线程池与资源管理 你的项目中线程池具体应用在哪些场景？ 你是如何通过异步请求与 complete future 等待结果的？心跳机制是如何做续约的？ 如果慢请求拖垮线程池，你有什么防范方案？ 请说明你的线程池具体配置与优化策略。 当线程池发生堆积时，你的超时中断、拒绝策略和定时回收方案具体如何落地？ AI 长耗时任务极易拖垮线程池导致服务宕机，你如何重点防范？ 你提出将 AI 调用隔离至独立线程池并调整参数，这个方案有什么潜在风险？做技术选型时如何评估副作用？