大家好，我是二哥呀。

喜报喜报。周六凌晨的时候，有球友发私信说拿到了携程的 SP，十分满意，并且 HR 说有两天可居家办公，准备签了，非常感谢星球里的项目。

翻了一下聊天记录，一个是RAG 派聪明，一个是轮子 MYDB，两个难度都不算大，但在今年的求职市场上非常吃香。

想去大厂的同学都可以按照这个套餐来，一个业务+一个轮子，业务可以是 AI 强相关，无论是 RAG 还是 Agent，还是 MCP 均可，现在每个厂都在卷这个。

如果你手头上的项目没有 AI 相关的，不求职还好，一旦求职就会感觉很吃力。

轮子的话，主要是针对那些做基架的面试官，他们非常喜欢问你底层原理，而 MYDB 的天然优势就是可以和 MySQL 关联起来。

这里再给大家盘点一下携程今年的薪资情况，大家可以感受一下 SP 在什么段位。

• 硕士 985，后端岗，给了 27k，酒店业务，算是 SP 了，不给 A。
• 硕士其他，测开岗，给了 25k，病假每年 5 天，年假第二年 5 天，居家办公看 ld，一年晋升两次。早 10 晚 8，十点打车报销，餐补 20，出勤补 20，试用期 4 个月。
• 硕士双一流，后端开发岗，给了 27k，实习转正，薪资还在 A。
• 学历没说，产品岗，给了 21 k，没签字费，base 上海。

心动的同学，尤其是 27 届的，可以趁这个寒假猛猛冲一段日常实习，春节后的暑期就会轻松很多，暑期有了，秋招也就有了。

给大家看一个数据，昨天修改的 20 多份简历上，竟然有 90% 的同学是 27 届，这你敢信？

反正我是挺诧异的！

这说明 27 届醒悟得非常早，应该是从师兄师姐那里打听到的，互联网的求职已经从秋招提前卷到暑期实习了，而大厂在评估暑期实习的转正标准时，会更加倾向于你有没有一段日常实习。

包括秋招的横向对比，已经不止一个球友在星球里发出这样的感慨：没有实习在横向环节太吃亏了。

该说不说，提前发力有利有弊，弊端就是需要提前进入求职的节奏，而求职的节奏和校园生活有很大的区别，很累。

读研的同学就更不用说了，科研压力非常大。上周末和我妹打视频，她说午休完还要去学习，读研比考研累多了，同学们都很卷。

好处就是可以提前结束，基本上 11 月开奖完就一切都结束了。

没有实习的同学，秋招往往要拖到 12 月中旬去捡漏，如果捡漏未果，战线要一直延长到明年的春招，如果有科研的压力，会更加喘不过气。

八股带背-携程篇

接下来，我会花一段时间带背八股，主要针对面渣逆袭 RocketMQ 篇，网址：https://javabetter.cn/sidebar/sanfene/rocketmq.html

4.消息队列有哪些消息模型？

我认为消息队列的消息模型可以分为两大类：点对点模型和发布-订阅模型。

点对点模型的特点是一条消息只能被一个消费者消费。生产者把消息发送到一个队列里，消费者从这个队列里拉取消息进行处理。一旦消息被某个消费者消费了，这条消息就被删除了，其他消费者是看不到这条消息的。

发布-订阅模型的特点是一条消息可以被多个订阅者消费。生产者发布消息到一个主题（Topic），所有订阅了这个主题的消费者都会收到这条消息。

这个模型特别适合用来做事件通知。比如说在技术派项目中，作者发布了一篇内容，可以同时通知所有关注了这个作者的用户，让他们收到更新提醒。系统级的消息通知也是类似的道理。

5.那 RocketMQ 的消息模型呢？

RocketMQ 采用的是一个统一的、基于 Topic 和 Group 的消息模型。同一个消费者组内可以算是点对点，不同消费者组之间算是发布-订阅。

在 RocketMQ 中，主题（Topic）是消息的逻辑分类。生产者把消息发送到某个 Topic，消费者从某个 Topic 拉取消息。一个 Topic 可以有多个生产者向它发送消息，也可以有多个消费者从它消费消息。

一个 Topic 在物理上被分成了多个队列（Queue）。生产者发送消息时，消息会根据某个 key 被路由到不同的 Queue 中。这个设计的巧妙之处在于，它既保证了单个 Queue 内的消息顺序，又能通过多个 Queue 实现并行处理。

消费者端，消费者归属于某一个消费者组（Consumer Group）。一个 消费者组内的多个消费者会协同消费同一个主题的消息。RocketMQ 会把主题下的多个队列分配给这个消费者组内的消费者进行消费。

场景 1：一个消费者，一个 Topic 有 4 个 Queue

ConsumerGroup: order_consumer_group
└─ Consumer 1
├─ Queue 0
├─ Queue 1
├─ Queue 2
└─ Queue 3

一个消费者消费所有 4 个队列。

场景 2：两个消费者，一个 Topic 有 4 个 Queue

ConsumerGroup: order_consumer_group

├─ Consumer 1
│ ├─ Queue 0
│ └─ Queue 2
│
└─ Consumer 2
├─ Queue 1
└─ Queue 3

两个消费者各消费 2 个队列，实现了负载均衡。

场景 3：四个消费者，一个 Topic 有 4 个 Queue

ConsumerGroup: order_consumer_group
├─ Consumer 1 → Queue 0
├─ Consumer 2 → Queue 1
├─ Consumer 3 → Queue 2
└─ Consumer 4 → Queue 3

四个消费者各消费 1 个队列，充分并行。

ending

一个人可以走得很快，但一群人才能走得更远。二哥的编程星球已经有 10400 多名球友加入了（马上涨价），如果你也需要一个优质的学习环境，戳链接 🔗 加入我们吧。这是一个 简历精修 + 编程项目实战（RAG 派聪明 Java 版/Go 版本、技术派、微服务 PmHub）+ Java 面试指南的私密圈子，你可以阅读星球专栏、向二哥提问、帮你制定学习计划、和球友一起打卡成长。

最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。