小红书取消大小周，有人不高兴了
小红书宣布五一节假日之后，取消大小周，恢复为正常的双休，乍一看工作时长变少， 按道理来说大家应该都会很开心，毕竟上班时间缩短了，但是还是有一些小红书的朋友高兴不起来，心情很复杂。
因为没有了大小周，以前不用走申请就能拿到的周末加班费就没了，那每个月收入就会比之前少了两天的双倍薪资收入，相当于少了 4 天薪资，薪资相比以前可能会少 15%左右。
我也帮大家收集了一波，今年小红书校招开发岗的薪资情况，取消了大小周，相当于全年加班费这部分就没有了，但是整体的薪资还是比挺多互联网大厂都多。
那些心情复杂的同学，主要也是因为当初加入小红书的同学，其实大部分都是看在给钱多的份上，早都已经做好大小周的心理准备的了，在乎这个的原本大概率也不会加入小红书。
虽然说取消了大小周，但是以后觉得活干不完，真需要周末加班，还是可以申请周末加班费的，当然很多人最怕就是工作量没有缩减，然后原本需要加班来完成的工作，最后加班费却申请不到。
取消大小周这个事情，快手和字节早在几年前就取消了，一年后大部分人更喜欢双休了，短期看是钱少了，长期来看幸福指数的提升会比多赚加班钱更高，这下压力给到了PDD。
除了取消大小周之外，小红书还做了一件很有格局的事情，把竞业协议也都取消了，这下压力又给到了PDD
瓜吃完了，回归正题！
这次来看看小红书基础架构开发的一面面经，通常搞基础架构开发的都是用 C++，所以面试也稍微问了一些 C++内容，不过面试者简历的技术栈是 Java，语言部分没有考察很多，主要重点拷打了计算网络、Redis、Kafka、分布式、设计模式、算法这些内容。
你们觉得难度如何？
小红书（基础架构一面）1. tcp 四次挥手 time_wait状态是为什么需要？
TIME_WAIT 状态的存在是为了确保网络连接的可靠关闭。只有主动发起关闭连接的一方（即主动关闭方）才会有 TIME_WAIT 状态。
TIME_WAIT 状态的需求主要有两个原因：
防止具有相同「四元组」的「旧」数据包被收到：在网络通信中，每个 TCP 连接都由源 IP 地址、源端口号、目标 IP 地址和目标端口号这四个元素唯一标识，称为「四元组」。当一方主动关闭连接后，进入 TIME_WAIT 状态，它仍然可以接收到一段时间内来自对方的延迟数据包。这是因为网络中可能存在被延迟传输的数据包，如果没有 TIME_WAIT 状态的存在，这些延迟数据包可能会被错误地传递给新的连接，导致数据混乱。通过保持 TIME_WAIT 状态，可以防止旧的数据包干扰新的连接。
保证「被动关闭连接」的一方能被正确关闭：当连接的被动关闭方接收到主动关闭方的 FIN 报文（表示关闭连接），它需要发送一个确认 ACK 报文给主动关闭方，以完成连接的关闭。然而，网络是不可靠的，ACK 报文可能会在传输过程中丢失。如果主动关闭方在收到 ACK 报文之前就关闭连接，被动关闭方将无法正常完成连接的关闭。TIME_WAIT 状态的存在确保了被动关闭方能够接收到最后的 ACK 报文，从而帮助其正常关闭连接。
2. tcp可以同时监听多个端口吗 ？
可以的，TCP 可以通过创建多个套接字监听不同端口，比如 nginx 服务器，它可以同时监听 80 端口和 443 端口。
img3. 打开页面全过程是怎样的？
解析URL：分析 URL 所需要使用的传输协议和请求的资源路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，则对非法字符进行转义后在进行下一过程。
缓存判断：浏览器缓存 → 系统缓存（hosts 文件） → 路由器缓存 → ISP 的 DNS 缓存，如果其中某个缓存存在，直接返回服务器的IP地址。
DNS解析：如果缓存未命中，浏览器向本地 DNS 服务器发起请求，最终可能通过根域名服务器、顶级域名服务器（.com）、权威域名服务器逐级查询，直到获取目标域名的 IP 地址。
获取MAC地址：当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相结合，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
建立TCP连接：主机将使用目标 IP地址和目标MAC地址发送一个TCP SYN包，请求建立一个TCP连接，然后交给路由器转发，等路由器转到目标服务器后，服务器回复一个SYN-ACK包，确认连接请求。然后，主机发送一个ACK包，确认已收到服务器的确认，然后 TCP 连接建立完成。
HTTPS 的 TLS 四次握手：如果使用的是 HTTPS 协议，在通信前还存在 TLS 的四次握手。
发送HTTP请求：连接建立后，浏览器会向服务器发送HTTP请求。请求中包含了用户需要获取的资源的信息，例如网页的URL、请求方法（GET、POST等）等。
服务器处理请求并返回响应：服务器收到请求后，会根据请求的内容进行相应的处理。例如，如果是请求网页，服务器会读取相应的网页文件，并生成HTTP响应。
4. Redis的数据结构你知道哪些？
Redis 提供了丰富的数据类型，常见的有五种数据类型：String（字符串），Hash（哈希），List（列表），Set（集合）、Zset（有序集合）。
随着 Redis 版本的更新，后面又支持了四种数据类型：BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。Redis 五种数据类型的应用场景：
String 类型的应用场景：缓存对象、常规计数、分布式锁、共享 session 信息等。
List 类型的应用场景：消息队列（但是有两个问题：1. 生产者需要自行实现全局唯一 ID；2. 不能以消费组形式消费数据）等。
Hash 类型：缓存对象、购物车等。
Set 类型：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、抽奖活动等。
Zset 类型：排序场景，比如排行榜、电话和姓名排序等。
Redis 后续版本又支持四种数据类型，它们的应用场景如下：
BitMap（2.2 版新增）：二值状态统计的场景，比如签到、判断用户登陆状态、连续签到用户总数等；
HyperLogLog（2.8 版新增）：海量数据基数统计的场景，比如百万级网页 UV 计数等；
GEO（3.2 版新增）：存储地理位置信息的场景，比如滴滴叫车；
Stream（5.0 版新增）：消息队列，相比于基于 List 类型实现的消息队列，有这两个特有的特性：自动生成全局唯一消息ID，支持以消费组形式消费数据。
5. Kafka你一般选几个消费者为什么？
核心原则是消费者数量 ≤ 分区数量。****Kafka 的并行度由分区数决定的，因为每个分区只能被同一个消费者组（Consumer Group）中的一个消费者消费。
比如，如果 Topic 有 6 个分区，消费者组最多可以启动 6 个消费者（1:1 绑定），如果启动 8 个消费者，其中 2 个会闲置（无分区可消费）。
如果要确定消费者数量，可以根据吞吐量需求来计算，公式如下：
消费者数量 = min(分区数, 预期吞吐量 / 单个消费者处理能力)
比如，Topic 有 12 个分区，单个消费者每秒处理 1000 条消息，生产者写入速率 8000 条/秒，至少需要 8000 / 1000 = 8 个消费者（不超过 12）。
所以，我们通常根据分区数量和吞吐需求决定消费者数量。例如，一个 12 分区的 Topic，如果单消费者处理能力为 1000 QPS，而生产者写入速率为 8000 QPS，则会部署 8 个消费者（不超过分区数），同时会预留 20% 分区余量应对突发流量。
6. Kafka怎么做到最多消费一次？
在 Kafka 中要实现 “最多消费一次”（At Most Once）的语义，也就是确保每条消息最多被消费一次，即便出现异常也不会重复消费。
可从生产者、消费者以及 Kafka 集群配置等方面来操作：
生产端：生产者方面主要是保证消息不会重复发送，因为重复发送会造成消费者重复消费，可以采用幂等性生产者，幂等性生产者能够保证在消息发送失败并重试时，相同的消息不会被重复写入 Kafka。
消费端：在消费者端达成 “最多消费一次” 语义，核心在于保证消费消息和提交偏移量这两个操作具有原子性，也就是要保证消息在被消费之后才会提交偏移量。要是在消费消息时出现异常，就不提交偏移量，如此一来，下次消费时就不会重复消费该消息，具体实现方式关闭自动提交偏移量功能，在消息消费成功之后手动提交偏移量，在消费消息时捕获可能出现的异常，若出现异常就不提交偏移量。
7. 分布式的 cap理论说一下？
CAP 原则又称 CAP 定理, 指的是在一个分布式系统中, Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）, 三者不可得兼
img
一致性(C) : 在分布式系统中的所有数据备份, 在同一时刻是否同样的值(等同于所有节点访问同一份最新的数据副本)
可用性(A): 在集群中一部分节点故障后, 集群整体是否还能响应客户端的读写请求(对数据更新具备高可用性)
分区容忍性(P): 以实际效果而言, 分区相当于对通信的时限要求. 系统如果不能在时限内达成数据一致性, 就意味着发生了分区的情况, 必须就当前操作在 C 和 A 之间做出选择
8. 单例模式的应用场景有哪些？
单例模式的核心是确保一个类只有一个实例，并提供全局访问点。它适用于需要严格控制资源唯一性或全局共享状态的场景。以下是单例模式的典型应用场景及具体分析：
全局配置管理：应用程序的配置信息（如数据库连接参数、系统路径、环境变量等）需要全局唯一且一致，用了单例模式之后避免多次读取配置文件，节省资源。
日志记录器：所有模块需要向同一个日志文件写入日志，确保日志顺序和一致性，用了单例模式之后可以避免多个日志实例竞争文件资源。
数据库连接池：管理数据库连接，避免频繁创建和销毁连接带来的性能开销，连接池需要全局唯一，统一分配和回收连接。
9. 写过c++吗？
简单写过，但是自己主要用Java 多一些
10. c++中 stl 中map的插入时间复杂度是多少？
std::map 是基于红黑树实现的，红黑树的插入时间复杂度是 O(logn)。
11. 手撕算法：双向链表反转
迭代法：遍历链表，逐个反转 prev 和 next 指针。
public ListNode reverseDoublyLinkedList(ListNode head) {
if (head == null || head.next == null) {
return head;
}
ListNode prev = null;
ListNode current = head;
while (current != null) {
ListNode nextNode = current.next; // 保存下一个节点
current.next = prev; // 反转 next 指针
current.prev = nextNode; // 反转 prev 指针
prev = current; // 移动 prev
current = nextNode; // 移动 current
}
return prev; // 新的头节点
}
时间复杂度：O(n)，遍历一次链表。
空间复杂度：O(1)，仅用常数级额外空间。
