双非黑黑榜

面完其实还好，最焦虑的是等结果那几天。每天刷邮箱、刷牛客，看别人发“oc了”“二面过了”，自己却一点消息都没有。明知道 HR 可能还在流程里，但脑子还是会忍不住想：是不是挂了、是不是表现不好。那几天干啥都不太踏实。

假如你简历需要优化模板和内容，可以让 AI 在获取你的信息和项目结构之后，进行一些修改，另外就是AI面试官的模拟面试了，因为有些人在面试的时候会紧张，建议先模拟一下，次数多了之后会很快缓解的，另外 AI 还可以做自动化测试，code review，还有像需求分析等等功能，现在 AI 是比较全面的，还是要多在生活中使用，不光是代码

hr说1-2天给我面试结果，前天晚上7点面完的，今天下午问一下合适吗

围绕项目，无八股算法部署服务的方式pod 最大多少个：高峰期7k QPS： 呃到☂️十个 Pod每个pod占用的资源：API 查询和任务消费/回调合并在一个 Pod 内，这类 Pod 既有高并发读流量，又有异步写和状态更新，也就是2C4G request，4C8G limit。分表的分页表怎么做有没有更好的方案  从产品思维：根据用户会员等级，限制用户查询的数量。加入缓存遇到了哪些问题：数据的不一致性问题，具体来说，当回调主动更改缓存任务状态时，有可能更改失败，因为mysql和redis的更新不在一个事务内，这个时候ttl就发挥了作用，视频生成的平均时长是2到3分钟，ttl设置为3分钟，当任务过期就被清楚，从数据库取出最新的数据，保证了redis和缓存的一致性消费者怎么回调：消费者回调通过rpc的方式回调我们的服务，传入状态和视频结果等信息，我们的服务去更新数据库和缓存服务之间调用的输入输出  用了 rpc 的什么协议调用的：百度内部常见的 RPC 框架是 brpc。它底层一般跑在 TCP 之上，消息序列化常用 protobuf；协议层不是只有一种，百度内部常见有 baidu_std 等私有协议，brpc 同时也兼容 HTTP、gRPC、Thrift 等多种协议。在这个项目中的一些不足和经验1. 后续流量增长还需要将轮询缓存的方式改成主动推送2. 对于慢sql的监控不完善，应该及时报警3. 在方案选型时考虑成本风险和收益反问：技术挑战如何，答：高并发以及维护可用性