大家好，我是二哥呀。
往年 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 面试指南的私密圈子，你可以阅读星球专栏、向二哥提问、帮你制定学习计划、和球友一起打卡成长。
最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。
回复