简历+boss打招呼

我投简历已经投了一个月了，boss直聘打招呼不回，要么就是简历投不出去，就算投出去的也没下文了，boss直聘沟通已经一千三了，投递简历数量才一百多，各公司的官网也在投，但是对口的并不多，官网估计才投二十来份。三月以来只有一个面试，春招也快结束了，是简历问题还是什么问题啊，求大佬指点，从简历-投递渠道-面试准备三个层面指导我

1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...

AI时代虽能快速生成代码，但刷LeetCode依旧必不可少。大厂面试核心考察算法逻辑与思维能力，而非单纯代码编写，AI只能给出答案，却无法替代逻辑推导与复杂度分析。面试字节、蚂蚁时，即便允许AI辅助编码，面试官仍会追问思路与优化方案，没有刷题基础根本无法应对。刷题是夯实数据结构、锻炼逻辑思维的关键，AI只是效率工具，核心编程功底还得靠刷题积累，二者结合才是求职最优解。

Nginx 是七层代理还是四层代理？你用过 LVS 吗？你的后端跑了两个 Tomcat 服务，在分布式架构下，Session 的会话保持（一致性）是怎么做的？什么是缓存穿透？简单讲一下你的项目中是如何用布隆过滤器解决缓存穿透问题的？场景设计题：如何设计一个海量日志采集系统（要求：日志尽量不丢、中间需拦截并添加流量/用户特征等处理、未来支持动态扩容）？谈谈你的技术架构设计思考。在业务代码中通过 AOP 记录完日志后，具体该如何将这些日志传输并提交到那个独立的日志服务上？如果该日志系统要求对接全集团的服务，日志量极大且 QPS 极高，应该如何设计高吞吐架构？如果在日志系统引入 Redis 缓存“热...