虾皮后端研发三面

我们都知道想进大厂难度确实比较高，有些小伙伴去面试虽然是实习生岗位，但依然会问你很刁钻的问题，来考验你的技术能力到底如何？而我辅导的小伙伴就有不少人问到了架构方面的问题，就比如在项目的运行时，就会被问到：Redis宕机了怎么办？MQ宕机了怎么办？MQ消息丢失了怎么办？MQ消息延迟消费了怎么办？数据库的余票数量和Redis中的不一致怎么办？Redis恢复后，丢失的数据要怎么恢复？等等一系列的这种令人头疼的问题！之前的 damai 项目关于这方面的问题有做过处理，但有些是人工处理，没有实现全面的自动化，有的面试官听着感觉比较普通，没有给人十足的亮点。所以针对上述说的这种疑难杂症，特意开发出了 da...

一面 1、拷打实验室项目（10min）2、讲一下秒杀活动的实现3、前端防刷能解决哪些问题，有哪些局限性4、如果用户不通过浏览器界面，而是直接模拟或调用后端接口进行刷单，如何防范？5、在应对局域网下（同一IP）大量用户同时抢购的场景时，怎么设计IP限流策略？6、高并发场景下“热Key”问题会对系统产生什么影响？怎么解决7、除了“下单”环节，整个秒杀链路中还有哪些环节可能存在性能瓶颈或挑战？8、在秒杀活动正式开始前，如何应对用户不断刷新页面等行为带来的流量冲击？9、为什么决定做这个Agent项目？10、怎么用Graph框架来设计和控制任务流程的？11、RAG知识引擎包含了哪些核心功能？12、如果知识库的内容非常庞杂，包括多种类型，如何智能地判断和优先提供最相关的知识？13、讲一下MCP的实际开发或集成经验？14、MCP与传统的Function Calling在工具调用层面，主要的区别和优势是什么？15、反问

这是一个典型的“消息分发模型”设计问题，微博/社交平台在设计大V发博分发时，推模式（push） 和 拉模式（pull） 各有利弊。下面结合你提到的“大V发博客”场景详细分析：一、两种模式简介推模式（push）大V一发微博，系统立即将内容推送到每一个粉丝的时间线中（如写入粉丝的消息队列或Feed中）拉模式（pull）粉丝查看时间线时，实时去拉取他关注的人（如大V）最新发布的内容，再合并排序显示二、微博类应用场景选型✅ 小V/普通用户：使用 推模式粉丝数少，推送量小；内容分发量级低；直接推送到粉丝的 Feed 表中，读取快，体验好。⚠️ 大V用户（如百万粉丝）：不能用纯推模式，会有严重问题顺便吆喝...

今天得知秋招被毁意向，这下得从头再来了。😅