大家好，我是二哥呀。
往年 21k 算白菜，今年水涨船高，有同学淘天开了 25k，也说自己是白菜😄，照这样下去，开 SSP 的同学也只敢说自己开了大 SP。
果不其然，星球里一位球友的 base 给的很高，必须是 SSP 的水平，并且还是 AI Agent 相关业务开发，直接就杀死比赛了。
他是 26 届当中我印象最深刻的一位，可能没有之一。9 月中旬就 OC 了五家大厂。
现在总算是告一段落了，相信他会有一个光明的未来，毕竟 AI 就是现在的版本答案。
能陪伴大家从开花到结果，感觉人生真的特别有意义——我骄傲。
虽然 26 届秋招已经是下半场，还有最后 20 天就将落下帷幕，但希望 26 届已经开奖的同学不要忘了二哥，常回来看看、瞅瞅，让我们相随相伴到永远😄。
这里也把《Java 面试指南》专栏中收录的，有关淘天的薪资给大家同步一下，做个参考。
- 硕士 211，Java 开发岗，给了 26k，还有 2k 的房补，签字费 1 万，base 杭州；
- 本科 985，Java 岗，给了 28k，签字费 8 万，绝对大 SP 的水平；
- 后端岗给了 29k，还有 800 交通补贴；
- 开发岗给了 32k，绝对 SSP 的水平了，算上房补和交通补贴，年包 55 万左右了。
淘天和阿里云算是阿里最重要的核心资产了，自从支付宝独立门户后，这俩就是顶梁柱，所以每年的年终奖也是阿里各 bu 当中最好的两个。
这里透露几点阿里系今年的招聘特点，27 届打算冲阿里系的同学一定要注意：
- 强 AI 味，这也是阿里今年能打翻身仗的重要原因，所以大家简历上一定要有 AI 相关的开发内容。
- 要有多段实习经历，如果能有一段日常一段暑期，秋招基本上就是横着走。
- 八股一定要知其然知其所以然，不管是实习还是秋招，八股盛宴几乎就是开胃菜。
给大家看一眼球友当时的淘天一面面经（暑期实习），日常实习拷打了 15 分钟，然后就是高频八股，还有大模型。
了解了一家公司的招聘特点，就能有的放矢，更针对性的查漏补缺。这样求职的成功率也会大大提高。
那有同学可能就要问了，这位球友找日常实习的时候用的什么项目啊？
答案是：技术派+ mydb，这是他二开技术派的网站。
开始的早，确实有一定的优势，日常相对来说是各个校招求职阶段最容易的一趴。
希望有时间去实习的同学一定要把握住寒假前的这个窗口期，也不剩多少时间了，春节后就要筹备暑期实习了。
节奏还是挺紧凑。
八股带背-淘天篇
接下来，我会花一段时间带背八股，主要针对面渣逆袭 RocketMQ 篇（顺嘴，好背），网址：https://javabetter.cn/sidebar/sanfene/rocketmq.html
6.消息的消费模式了解吗？
我认为消费模式可以从两个维度来分类：一个是消费的方向，一个是消费的范围。
从消费方向来分的话，有两种模式，一种是 pull 模式，一种是 push 模式。
pull 模式需要消费者主动去消息队列中拉取消息，消费者可以控制拉取的速度、数量，但需要不断地轮询，比较浪费资源。
push 模式则是消息队列主动把消息推送给消费者，消费者只需要注册一个监听器，消息一到达就会触发回调进行处理，响应速度快，但可能会出现消息堆积的情况。
从消费范围来分的话，也有两种模式，一种是集群消费，一种是广播消费。
集群消费是指，同一个消费者组中的多个消费者共同消费一个主题中的消息。消息被分散分配给这个消费者组中的各个消费者，每条消息只被这个消费者组中的一个消费者消费。
RocketMQ 会把主题下的所有队列均匀地分配给消费者组内的消费者，实现负载均衡。同时保证同一条消息只会被消费者组内的一个消费者消费，避免重复消费。
Topic: order_topic
├─ Queue 0 → [消息1] [消息3] [消息5]
├─ Queue 1 → [消息2] [消息4] [消息6]
├─ Queue 2 → [消息7] [消息9] [消息11]
└─ Queue 3 → [消息8] [消息10] [消息12]
ConsumerGroup: order_consumer_group
├─ Consumer 1 消费 Queue 0, 1
├─ Consumer 2 消费 Queue 2, 3
同一条消息只被 Consumer 1 或 Consumer 2 之一消费，不会重复消费。
广播消费是指，同一个主题的每条消息都会被消费者组内的每个消费者消费一次。也就是说，消费者组内的每个消费者都会收到主题下的所有消息，从而实现消息的广播效果。
Topic: config_update_topic
└─ [配置更新消息1] [配置更新消息2] [配置更新消息3]
ConsumerGroup: config_consumer_group
├─ Consumer 1（服务器1上的应用）
│ └─ 收到：消息1, 消息2, 消息3（完整的）
│
├─ Consumer 2（服务器2上的应用）
│ └─ 收到：消息1, 消息2, 消息3（完整的）
│
└─ Consumer 3（服务器3上的应用）
└─ 收到：消息1, 消息2, 消息3（完整的）
三个消费者都收到了所有的消息，各自独立处理。
7.RocketMQ 的基本架构了解吗？
RocketMQ 的架构由四个核心部分组成：NameServer、Broker、生产者和消费者。
我的理解是，NameServer 就是 RocketMQ 的路由中心，负责维护 Topic 和 Broker 之间的路由信息。生产者在发送消息前，消费者在消费消息前，都会先从 NameServer 获取最新的路由信息。
每个 Broker 会向 NameServer 注册自己的信息，包括 Broker 的地址、端口、存储的 Topic 和 Queue 等。
NameServer 会根据 Topic 名称告诉生产者和消费者对应的 Broker 地址。
Broker 会定期向 NameServer 发送心跳，报告自己的状态。
Broker 是消息存储中心，它的职责包括：
所有生产者发送的消息都会被存储在 Broker 上，以文件的形式持久化到磁盘。
消费者从 Broker 拉取消息时，Broker 需要根据消费者的 Offset 找到对应的消息，返回给消费者。
如果配置了高可用，Broker Master 会把消息同步到 Broker Slave，实现主从备份。
生产者在发送消息时，会先从 NameServer 获取 Topic 的路由信息，然后根据路由信息把消息发送到对应的 Broker 上。
消费者在消费消息时，也会先从 NameServer 获取 Topic 的路由信息，然后根据路由信息从对应的 Broker 上拉取消息进行处理。
ending
一个人可以走得很快，但一群人才能走得更远。二哥的编程星球已经有 10400 多名球友加入了（马上涨价），如果你也需要一个优质的学习环境，戳链接 🔗 加入我们吧。这是一个 简历精修 + 编程项目实战（RAG 派聪明 Java 版/Go 版本、技术派、微服务 PmHub）+ Java 面试指南的私密圈子，你可以阅读星球专栏、向二哥提问、帮你制定学习计划、和球友一起打卡成长。
最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。
回复