小红书校招年薪竟高达51w+！这薪资水平真的合理吗？

前几天，我整理分享了招银网络和中兴今年校招开奖的情况。招银软开的整体总包在 26w~~31w（部分可能更低或者更高），公积金按照 12% 标准缴纳。中兴开的就比较低一点，整体总包在 19w~~33w 附近，公积金是按照 8% 标准缴纳。

今天再来看一个炸裂点的，小红书的今年的校招薪资开的是真的离谱啊！

根据网上已经爆出的薪资来看，下面是小红书今年已经开奖岗位的薪资情况：

是的，你没看错，小红书的今年校招的大白菜一年都能给到 51w+（应该是大白菜，暂时没看到比这更低的了），比别家的很多 SP 和 SSP 还要高很多，太猛了呀！

这还要啥自行车啊！这薪资就是工作强度大，绩效考核，咱也得认啊！不过，小红书确实高压环境，流动性比较大。

下图是网友爆料的 2025 年互联网公司工作强度排行榜，可以看到小红书仅次于大疆、PDD 和得物。

对于后端面试来说，小红书基础八股问的不多，更多的是结合项目去提问。

下面给大家分享一篇小红去年秋招的后端面经。我精选了一二面中的一些比较典型的面试问题进行解答， 大家可以感受一下小红书的面试难度如何。

UDP 和 TCP 区别

1. 是否面向连接：
2. 是否是可靠传输：
3. 是否有状态：
4. 传输效率：
5. 传输形式：
6. 首部开销：
7. 是否提供广播或多播服务：
8. ……

为了更直观地对比，可以看下面这个表格：

特性TCPUDP

连接性

面向连接

无连接

可靠性

可靠

不可靠 (尽力而为)

状态维护

有状态

无状态

传输效率

较低

较高

传输形式

面向字节流

面向数据报 (报文)

头部开销

20 - 60 字节

8 字节

通信模式

点对点 (单播)

单播、多播、广播

常见应用

HTTP/HTTPS, FTP, SMTP, SSH

DNS, DHCP, SNMP, TFTP, VoIP, 视频流

TCP 为什么可靠呢

1. 基于数据块传输：应用数据被分割成 TCP 认为最适合发送的数据块，再传输给网络层，数据块被称为报文段或段。
2. 对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
3. 校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4. 重传机制 : 在数据包丢失或延迟的情况下，重新发送数据包，直到收到对方的确认应答（ACK）。TCP 重传机制主要有：基于计时器的重传（也就是超时重传）、快速重传（基于接收端的反馈信息来引发重传）、SACK（在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了）、D-SACK（重复 SACK，在 SACK 的基础上，额外携带信息，告知发送方有哪些数据包自己重复接收了）。
5. 流量控制 : TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议（TCP 利用滑动窗口实现流量控制）。
6. 拥塞控制 : 当网络拥塞时，减少数据的发送。TCP 在发送数据的时候，需要考虑两个因素：一是接收方的接收能力，二是网络的拥塞程度。接收方的接收能力由滑动窗口表示，表示接收方还有多少缓冲区可以用来接收数据。网络的拥塞程度由拥塞窗口表示，它是发送方根据网络状况自己维护的一个值，表示发送方认为可以在网络中传输的数据量。发送方发送数据的大小是滑动窗口和拥塞窗口的最小值，这样可以保证发送方既不会超过接收方的接收能力，也不会造成网络的过度拥塞。

更多网络高频知识点和面试题总结，可以阅读笔者写的这几篇文章：

你的项目用过什么设计模式？

我的项目用到了责任链模式。责任链模式（Chain of Responsibility Pattern）是一种行为型设计模式。它将请求的发送者和接收者解耦，通过创建一个处理请求的接收者链来处理请求。链上的每个接收者（也称为处理器或节点）都负责对请求进行一部分的处理或校验，并决定是否将请求传递给链上的下一个接收者，或者中断处理流程。

举个例子，在我的项目的订单场景，一个订单可能需要进行多种校验，例如商品库存校验、风控校验、支付信息校验等。可以将这些校验规则组成一个责任链，每个校验规则负责一种校验，如果校验不通过，则中断流程并返回错误信息；如果校验通过，则将请求传递给下一个校验规则。

我总结过设计模式相关的高频面试题，需要的朋友可以自取：后端面试 PDF 合集！。

什么是工作流？

维基百科是这样介绍工作流的：

工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表达并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

简单来说，工作流就是定义“为了完成一件事，需要按照什么顺序和规则做哪些事情”。例如，请假审批、订单处理、报销申请等等，这些都是工作流。 它们都包含多个步骤，并且这些步骤需要按照一定的顺序和规则执行。

拿公司员工请假审批流程来说，我们可能会涉及到下面这些流程：

一个业务流程中涉及的环节（比如部门经理审核），按照特定规则组织在一起，这个特定规则可以单纯硬编码来实现和维护。但是，这样很难让我们适应业务流程的变化，并且无法直观地看到每个环节执行的具体的业务逻辑。

那么，有没有一种方法可以让我们更容易地定义、管理和修改这些业务流程呢？

答案就是：使用工作流引擎！

工作流引擎就像一个流程“机器人”，它可以根据我们预先定义好的规则自动执行整个流程。 我们只需要用可视化的方式定义好流程的各个步骤、规则和参与者，剩下的就交给工作流引擎去处理。

为什么要用工作流？

还是拿公司员工请假审批流程来说。在没有工作流的情况下，每一步流程都需要在代码中手动维护请假业务的状态。例如，在“部门经理审核”之后，需要编写代码判断请假天数，以决定是否需要“总经理审核”。

这种方式存在诸多问题，主要体现在下面两个方面：

1. 代码复杂且难以维护： 业务流程的每一步都需要在代码中实现，导致代码冗长、复杂，难以理解和维护。 任何流程的修改都需要修改代码并重新部署，成本高且容易出错。
2. 难以适应变化： 如果需要修改流程，例如在“部门经理审核”之前添加“项目负责人审核”，则需要修改大量的代码，工作量巨大且容易引入 bug。 业务流程的调整变得缓慢且困难。

引入工作流引擎后，这两个问题都能得到有效解决：

1. 简化开发和维护： 通过可视化的流程设计器，可以将业务流程定义为一系列节点和连接，无需编写复杂的代码。 流程的修改只需要修改流程定义，无需修改代码，大大简化了开发和维护工作。
2. 灵活适应变化： 工作流引擎可以轻松地添加、删除或修改流程节点，快速适应业务流程的变化。 例如，添加“项目负责人审核”节点只需在流程定义中添加一个节点即可，无需修改其他代码。

流程引擎和规则引擎有什么区别？

很多小伙伴容易把流程引擎（工作流是流程的定义，流程引擎是流程的具体执行者）和规则引擎的概念混淆，虽然两者都与业务逻辑相关，但它们解决的问题和应用场景有所不同。

流程引擎

流程引擎的核心是定义和执行业务流程，它关注的是业务活动在不同参与者（通常是不同角色）之间的流转和协作。

流程引擎主要解决以下问题：

简单来说，流程引擎的重点是控制业务活动的执行顺序和参与者之间的交互，例如：

规则引擎

规则引擎的核心是将业务决策逻辑从应用程序代码中解耦出来，并使用预定义的语义模块（例如规则语言、决策表、决策树、流程图等）来表达和执行这些决策。它接受数据输入，根据配置的规则进行匹配和计算，并根据结果触发相应的动作，最终产出决策结果或执行预设的操作。

下图很好的展示了规则引擎的基本工作原理（规则参数 + 数据输入 --> 规则引擎 --> 动作）：

规则引擎主要解决以下问题：

简单来说，规则引擎的重点是根据输入数据进行判断和决策，例如：

总结

规则引擎关注的是决策，流程引擎关注的是流程。两者并非是竞争关系，在实际应用中通常是互补的，可以结合使用。例如，在流程引擎的某个节点引入规则引擎，根据不同的条件决定流程的下一步走向，使流程更加灵活和智能。 规则引擎可以作为流程引擎的一个组件，为流程引擎提供决策支持。

你的项目为什么要用 MQ？

通常来说，使用消息队列能为我们的系统带来下面三点好处：

1. 通过异步处理提高系统性能（减少响应所需时间）
2. 削峰/限流
3. 降低系统耦合性。

如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。

这里以 MQ 解耦为例说明。

使用消息队列还可以降低系统耦合性。我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。还是直接上图吧：

生产者（客户端）发送消息到消息队列中去，接受者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费即可而不需要和其他系统有耦合，这显然也提高了系统的扩展性。

消息队列使用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。 从上图可以看到消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

例如，我们商城系统分为用户、订单、财务、仓储、消息通知、物流、风控等多个服务。用户在完成下单后，需要调用财务（扣款）、仓储（库存管理）、物流（发货）、消息通知（通知用户发货）、风控（风险评估）等服务。使用消息队列后，下单操作和后续的扣款、发货、通知等操作就解耦了，下单完成发送一个消息到消息队列，需要用到的地方去订阅这个消息进行消息即可。

你用的这个 MQ 支持延时消息吗?

RocketMQ 4.x 版本及其之前的版本支持基于预定义的延时等级的延时消息处理。消息发送者可以指定一个延时等级（如 1s、5s、10s 等），然后消息会在相应的延时级别到达后被发送到消费者队列。这些延时等级是固定的，不能灵活配置。

如下表所示，一共 18 个延时等级，具体时间如下：

投递等级（delay level）延迟时间投递等级（delay level）延迟时间

1s

10

6min

5s

11

7min

10s

12

8min

30s

13

9min

1min

14

10min

2min

15

20min

3min

16

30min

4min

17

1h

5min

18

2h

RocketMQ 5.0 基于时间轮算法引入了定时消息，解决了延时级别只有 18 个、延时时间不准确等问题。

RocketMQ 定时消息的底层实现可以看看我朋友写的这篇：弥补延时消息的不足，RocketMQ 基于时间轮算法实现了定时消息！。

了解其他的消息队列吗？

常见的消息队列

Kafka

Kafka 是 LinkedIn 开源的一个分布式流式处理平台，已经成为 Apache 顶级项目，早期被用来用于处理海量的日志，后面才慢慢发展成了一款功能全面的高性能消息队列。

流式处理平台具有三个关键功能：

1. 消息队列：发布和订阅消息流，这个功能类似于消息队列，这也是 Kafka 也被归类为消息队列的原因。
2. 容错的持久方式存储记录消息流：Kafka 会把消息持久化到磁盘，有效避免了消息丢失的风险。
3. 流式处理平台： 在消息发布的时候进行处理，Kafka 提供了一个完整的流式处理类库。

Kafka 是一个分布式系统，由通过高性能 TCP 网络协议进行通信的服务器和客户端组成，可以部署在在本地和云环境中的裸机硬件、虚拟机和容器上。

在 Kafka 2.8 之前，Kafka 最被大家诟病的就是其重度依赖于 Zookeeper 做元数据管理和集群的高可用。在 Kafka 2.8 之后，引入了基于 Raft 协议的 KRaft 模式，不再依赖 Zookeeper，大大简化了 Kafka 的架构，让你可以以一种轻量级的方式来使用 Kafka。

不过，要提示一下：如果要使用 KRaft 模式的话，建议选择较高版本的 Kafka，因为这个功能还在持续完善优化中。Kafka 3.3.1 版本是第一个将 KRaft（Kafka Raft）共识协议标记为生产就绪的版本。

Kafka 官网：kafka.apache.org/

Kafka 更新记录（可以直观看到项目是否还在维护）：kafka.apache.org/downloads

RocketMQ

RocketMQ 是阿里开源的一款云原生“消息、事件、流”实时数据处理平台，借鉴了 Kafka，已经成为 Apache 顶级项目。

RocketMQ 的核心特性（摘自 RocketMQ 官网）：

根据官网介绍：

Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。

RocketMQ 官网：rocketmq.apache.org/ （文档很详细，推荐阅读）

RocketMQ 更新记录（可以直观看到项目是否还在维护）：github.com/apache/rock…

RabbitMQ

RabbitMQ 是采用 Erlang 语言实现 AMQP(Advanced Message Queuing Protocol，高级消息队列协议）的消息中间件，它最初起源于金融系统，用于在分布式系统中存储转发消息。

RabbitMQ 发展到今天，被越来越多的人认可，这和它在易用性、扩展性、可靠性和高可用性等方面的卓著表现是分不开的。RabbitMQ 的具体特点可以概括为以下几点：

RabbitMQ 官网：www.rabbitmq.com/ 。

RabbitMQ 更新记录（可以直观看到项目是否还在维护）：www.rabbitmq.com/news.html

Pulsar

Pulsar 是下一代云原生分布式消息流平台，最初由 Yahoo 开发 ，已经成为 Apache 顶级项目。

Pulsar 集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性，被看作是云原生时代实时消息流传输、存储和计算最佳解决方案。

Pulsar 的关键特性如下（摘自官网）：

Pulsar 官网：pulsar.apache.org/

Pulsar 更新记录（可以直观看到项目是否还在维护）：github.com/apache/puls…

ActiveMQ

目前已经被淘汰，不推荐使用，不建议学习。

如何选择？

消息队列基础知识总结这篇文章有详细介绍到。