金三银四 0 offer
最近鸭鸭在脉脉看到一条帖子：
“去年 11 月底裸辞，今年元宵后开始找工作，共面 10 家公司，0 offer。”
发帖人把自己面试的战绩单一条不落地贴了出来：
富途一面挂，OSL 一面挂，腾云科技二面挂，众惠相互保一面挂，京东一面挂，小 AI 创业公司三面挂，华盛通一面挂，顺丰科技二面挂，沃尔玛二面挂，Vivo 二面挂。
最后一句：“30+ 大龄 gap 还能找到工作吗？”
底下 83 条评论，鸭鸭翻了一半就不想翻了。全是：
“我也一样。” “38 岁一个 offer 没有。” “我 gap 一年还在面。” “兄弟加我好友，我跟你一模一样。”
说实话，10 家全挂，大概率真不是你技术差。
因为工作 5 年的后端，真要说技术扛不住一面，概率非常低。10 家里一面挂了 6 家、二面挂了 3 家、三面挂了 1 家，这个分布其实已经透露了答案：挂你的不是八股，也不是你不会写代码，而是你讲不出面试官想听的那个故事。
那 30+ 的面试官想听什么？
这届面试，考的已经不是“你会多少”，而是“你还能涨多少”。
工作 5 年的候选人，面试官心里的那把尺子已经变了。他不是想招一个“能干活”的人，他是想招一个“能带团队、能接新方向、能在 AI 重构这一轮里不掉队”的人。你讲自己在 XX 公司做过订单中台、做过分布式缓存、优化过 QPS——这些对他来说都是“你过去 5 年的及格线”。真正让他眼前一亮的，是你能不能接下来一句：
“这套东西我现在的解法是 XX，但如果让我从零再做一遍，我会结合大模型 / Agent / 新范式，这样做。”
只要没这一句，10 家全挂几乎是必然。
所以鸭鸭反而觉得，这 10 家挂得挺值的。
因为它们已经很清楚地告诉发帖人一件事：你过去那套 “我做过什么” 的讲法，在今年这届面试里已经讲不动了。它不是让你去否定自己前 5 年，而是逼着你把前 5 年重新翻译一遍——翻译成面试官想听的“你还能涨的故事”。
那接下来该怎么做？鸭鸭不想给那种虚头巴脑的“刷题攻略”，就说三件最实在的事：
- 别再海投。精选 3 个方向，每个方向做一版针对性简历，比面 10 家全海投有用得多。
- 把每个项目重讲一遍。过去做过什么是“基础分”，未来还能往哪做才是“拉开差距的分”。
- 面试前一定刷一轮面经。不是为了背答案，是为了把自己这 5 年积累的东西，重新翻译成“结构化的、能讲出来的”语言。
10 家挂完，真的不是你不行。
只是今年这届面试的游戏规则，已经悄悄换了一套。发现得越早，下一家就越稳。
……
今天和大家分享一篇后端面经。
【什么是 MCP 协议，它在 AI 大模型系统中的作用是什么？ 】
回答重点
推模式（Push）：消息队列（Broker）将消息主动推送给消费者，适合实时性要求高、消费者能够及时处理消息的场景。
- 优点：实时性好，消息可立即送达消费者。
- 缺点：难以控制消费速度，容易导致消费者过载，尤其是在高并发时。
拉模式（Pull）：消费者主动从消息队列（Broker）中拉取消息，适合消费能力有限、需要根据自身处理能力调控速率的场景。
- 优点：消费者可以根据自身负载决定拉取频率，避免过载；更适合批量处理。
- 缺点：可能会导致消息延迟，实时性不如推模式，尤其是拉取频率较低时。
主流的消息队列像 RocketMQ、Kafka 都选择了拉模式，但不是纯粹的拉，底层用了长轮询来弥补拉模式实时性差的问题。
长轮询的做法是：消费者去拉消息时，如果有消息 Broker 立马返回，如果没有消息就 hold 住这个请求别断开连接，等消息来了再返回。这样既保证了实时性，又避免了频繁的无效请求。默认等待时间一般是 30 秒，超时后消费者再发起下一次请求。
RocketMQ 的 PushConsumer 看起来是推，其实底层还是拉，只是框架帮你封装了自动拉取的逻辑，对业务代码来说就像是推的一样。
扩展知识
推拉模式
首先明确一下推拉模式到底是在讨论消息队列的哪一个步骤，一般而言我们在谈论推拉模式的时候指的是 Comsumer 和 Broker 之间的交互。
默认的认为 Producer 与 Broker 之间就是推的方式，即 Producer 将消息推送给 Broker，而不是 Broker 主动去拉取消息。
想象一下，如果需要 Broker 去拉取消息，那么 Producer 就必须在本地通过日志的形式保存消息来等待 Broker 的拉取，如果有很多生产者的话，那么消息的可靠性不仅仅靠 Broker 自身，还需要靠成百上千的 Producer。
Broker 还能靠多副本等机制来保证消息的存储可靠，而成百上千的 Producer 可靠性就有点难办了，所以默认的 Producer 都是推消息给 Broker。
所以说有些情况分布式好，而有些时候还是集中管理好。
推模式
推模式指的是消息从 Broker 推向 Consumer，即 Consumer 被动的接收消息，由 Broker 来主导消息的发送。
推模式有什么好处：
- 消息实时性高，Broker 接受完消息之后可以立马推送给 Consumer。
- 对于消费者使用来说更简单，简单啊就等着，反正有消息来了就会推过来。
推模式有什么缺点？
推送速率难以适应消费速率，推模式的目标就是以最快的速度推送消息，当生产者往 Broker 发送消息的速率大于消费者消费消息的速率时，随着时间的增长消费者那边可能就“爆仓”了，因为根本消费不过来啊。当推送速率过快就像 DDos 攻击一样消费者就傻了。
并且不同的消费者的消费速率还不一样，身为 Broker 很难平衡每个消费者的推送速率，如果要实现自适应的推送速率那就需要在推送的时候消费者告诉 Broker ，我不行了你推慢点吧，然后 Broker 需要维护每个消费者的状态进行推送速率的变更。
这其实就增加了 Broker 自身的复杂度。
所以说推模式难以根据消费者的状态控制推送速率，适用于消息量不大、消费能力强要求实时性高的情况下。
拉模式
拉模式指的是 Consumer 主动向 Broker 请求拉取消息，即 Broker 被动的发送消息给 Consumer。
我们来想一下拉模式有什么好处？
拉模式主动权就在消费者身上了，消费者可以根据自身的情况来发起拉取消息的请求。假设当前消费者觉得自己消费不过来了，它可以根据一定的策略停止拉取，或者间隔拉取都行。
拉模式下 Broker 就相对轻松了，它只管存生产者发来的消息，至于消费的时候自然由消费者主动发起，来一个请求就给它消息呗，从哪开始拿消息，拿多少消费者都告诉它，它就是一个没有感情的工具人，消费者要是没来取也不关它的事。
拉模式可以更合适的进行消息的批量发送，基于推模式可以来一个消息就推送，也可以缓存一些消息之后再推送，但是推送的时候其实不知道消费者到底能不能一次性处理这么多消息。而拉模式就更加合理，它可以参考消费者请求的信息来决定缓存多少消息之后批量发送。
拉模式有什么缺点？
消息延迟，毕竟是消费者去拉取消息，但是消费者怎么知道消息到了呢？所以它只能不断地拉取，但是又不能很频繁地请求，太频繁了就变成消费者在攻击 Broker 了。因此需要降低请求的频率，比如隔个2 秒请求一次，你看着消息就很有可能延迟 2 秒了。
消息忙请求，忙请求就是比如消息隔了几个小时才有，那么在几个小时之内消费者的请求都是无效的，在做无用功。
到底是推还是拉
可以看到推模式和拉模式各有优缺点，到底该如何选择呢？
RocketMQ 和 Kafka 都选择了拉模式，当然业界也有基于推模式的消息队列如 ActiveMQ。
我个人觉得拉模式更加的合适，因为现在的消息队列都有持久化消息的需求，也就是说本身它就有个存储功能，它的使命就是接受消息，保存好消息使得消费者可以消费消息即可。
而消费者各种各样，身为 Broker 不应该有依赖于消费者的倾向，我已经为你保存好消息了，你要就来拿好了。
虽说一般而言 Broker 不会成为瓶颈，因为消费端有业务消耗比较慢，但是 Broker 毕竟是一个中心点，能轻量就尽量轻量。
那么竟然 RocketMQ 和 Kafka 都选择了拉模式，它们就不怕拉模式的缺点么？ 怕，所以它们操作了一波，减轻了拉模式的缺点。
篇幅有限，更多 后端场景 相关面试题可以进入面试鸭（mianshiya.com）进行查阅。
