大家好，我是二哥呀。
昨天有球友说深信服的 AI 软开岗开到了 30k+，这真的是高的离谱啊，基本上等同于互联网大厂的 SSP offer 了。
这谁看了不心动？
对比一下去年深信服的薪资，只能说今年的 AI 应用开发岗位是真的香。
记得 7 月份球友找我修改简历的时候，他用的是 PmHub 微服务和 RAG 项目，没有写轮子，时隔三月，也是开花结果了。
秋招下半场的 26 届同学，以及打算参加接下来寒假日常实习的 27 届同学要注意，简历上的项目能往 AI 方面靠，尽量靠一点。
哪怕你只写一条：
通过模板方法设计模式+门面类设计模式封装 DeepSeek-Chat 模型，完成派聪明 AI 聊天助手。
都会勾起面试官的浓烈兴趣，😄，这就像移动互联网时代，你有安卓/IOS 开发经验就是香饽饽。
更别说你简历上有 RAG 或者 Agent 项目了，我随便给大家提供个例子：
构建 RAG 检索流程：通过用户提问 + 检索片段拼接生成增强型 Prompt，结合上下文与语义召回提升问答准确度，构建企业私有知识问答体系。
面试官可能就会问你一连串的 AI 问题：
- RAG 是什么？
- 你平常是怎么优化 prompt 的？
- 上下文是如何保证的？
- 语义召回你是如何评估的？
我把派聪明的简历写法放到了下面这个帖子里了，想蹭 AI 热度的同学可以参考。
复制到浏览器打开：https://paicoding.com/column/10/2
Agent 项目也正在做，昨天晚上我和团队开会，把 PaiAgent 的需求重新过了一遍，基础框架就打算用阿里的 SpringAI Alibaba 来搭。
有想学习的同学可以提前去看一下，基础组件如 workflow、Agent、tool、chatmemory、Graph 都有。
另外，要多说一句，还没有 offer 的同学 11 月一定要沉住气，目前开奖的同学越来越多了，头部和部分肩部选手正在做抉择，并且很多没办法再拖下去。
球友告诉我，深信服 HR 那边已经明确希望在这周签三方。签了或者超时了就意味着手头上其他的 offer 就要释放出来。
一连串，HC 没招满的，就要通知池子里的同学，或者重新面试新的候选人。
接下来，我会继续更新迭代项目和八股，托举大家上岸。
八股带背-深信服篇
接下来，我会花一段时间带背八股，帮大家搞定各大公司的八股高频题，开始冲刺，面渣逆袭 RocketMQ 篇网址：https://javabetter.cn/sidebar/sanfene/rocketmq.html
2.为什么要选择 RocketMQ?
首先，在事务支持方面，RocketMQ 做得特别好。比如说在转账场景下，我们要保证"扣款"的本地事务和"发送转账消息"这两个操作要么都成功，要么都失败，不能出现只扣款但没发消息的情况。RocketMQ 的事务消息机制就能很好地解决这个问题。
// RocketMQ 事务消息示例
TransactionSendResult sendResult = rocketMQTemplate.executeAndReplyTransaction(
"transfer_topic",
new Message("transfer_topic",
JSON.toJSONString(new TransferRequest(fromId, toId, amount)).getBytes()),
new RocketMQLocalTransactionListener() {
@Override
public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
try {
// 执行本地事务 - 扣款
accountService.deductAccount(fromId, amount);
return RocketMQLocalTransactionState.COMMIT;
} catch (Exception e) {
return RocketMQLocalTransactionState.ROLLBACK;
}
}
@Override
public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
// 事务回查逻辑
return accountService.isDeducted(fromId, amount) ?
RocketMQLocalTransactionState.COMMIT :
RocketMQLocalTransactionState.ROLLBACK;
}
}
);
其次是对顺序消息的支持。在很多场景下，消息的顺序很重要。比如订单的生命周期，应该是：下单 → 支付 → 发货 → 确认收货。如果消息乱序了，就会出现还没付款就发货的逻辑混乱。
RocketMQ 的顺序消息能够保证同一个 OrderId 的消息，它们能够被发送到同一个队列，然后被同一个消费者按顺序消费。
PmHub 中的任务审批流程，就是用的 RocketMQ 来保证审批步骤的正确顺序。
再有就是 RocketMQ 支持 Master-Slave 模式的高可用部署。当 Master 节点宕机时，Slave 可以自动转换为 Master，从而提供更好的容错能力。
如果是日志收集和流式处理场景，Kafka 更合适，因为它天生为大数据场景设计。派聪明 RAG 项目中的文件上传后的向量化、索引构建任务，就是用的 Kafka 来做消息队列。
如果是需要轻量级的消息传递，RabbitMQ 更好，因为它实现了 AMQP 协议，支持丰富的路由和交换机类型。
技术派项目中的点赞、收藏、评论等功能的异步处理，就是用的 RabbitMQ 来做消息队列。
不过，RocketMQ 也有缺点，由于 RocketMQ 的消息去重不是自动的，所以需要消费者端自己实现幂等，否则容易出现重复消费的问题。
// 需要在消费端自己实现幂等
@RocketMQMessageListener(topic = "order_topic",
consumerGroup = "order_consumer_group")
public class OrderConsumer implements RocketMQListener<OrderMessage> {
@Override
public void onMessage(OrderMessage message) {
// 需要根据消息的唯一标识检查是否已经处理过
if (orderService.isProcessed(message.getOrderId())) {
// 已经处理过，直接返回
return;
}
// 处理订单逻辑
orderService.processOrder(message);
}
}
说说你对 RocketMQ 的理解？
RocketMQ 是阿里巴巴开源的一款分布式消息中间件，具有高吞吐量、低延迟和高可用性。其主要组件包括生产者、消费者、Broker、Topic 和队列。消息由生产者发送到 Broker，再根据路由规则存储到队列中，消费者从队列中拉取消息进行处理。适用于异步解耦和流量削峰等场景。
ending
一个人可以走得很快，但一群人才能走得更远。二哥的编程星球已经有 10300 多名球友加入了（马上涨价），如果你也需要一个优质的学习环境，戳链接 🔗 加入我们吧。这是一个 简历精修 + 编程项目实战（RAG 派聪明 Java 版/Go 版本、技术派、微服务 PmHub）+ Java 面试指南的私密圈子，你可以阅读星球专栏、向二哥提问、帮你制定学习计划、和球友一起打卡成长。
最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。
回复