Stripe 2026 SDE OA辅助实况

最近刚帮一位学员复盘了 Stripe 的 OA 笔试真题，一道经典的负载均衡模拟题。题目本身不难，但细节非常多，五个部分层层递进，稍不注意就会在某个边界条件上翻车。下面把题目完整还原，思路拆开讲透，准备冲 Stripe 的同学可以直接对照着推演一遍。

题目背景

Stripe 内部的 notebook 平台基于 Jupyter，大量活跃连接下性能表现不佳，需要你实现一个负载均衡器 route_requests，将开发者的请求路由到不同的 Jupyter 服务器上。

输入参数：

• numTargets：目标服务器数量
• maxConnectionsPerTarget：每台服务器允许的最大活跃连接数
• requests[n]：按时间顺序到达的请求列表，每行格式为：
• CONNECT,connectionId,userId,objectId
• DISCONNECT,connectionId（假设一定对应已存在的连接）
• SHUTDOWN,targetIndex

返回值：

• 对于每一个成功建立的 CONNECT 请求，按处理顺序输出日志 connectionId,userId,targetIndex，其中 targetIndex 是 1-based 的服务器编号。

题目共分五个部分，每个部分都在前一部分的基础上增加新的规则。

Part 1：基础负载均衡

规则：

• 每次 CONNECT 请求到达时，选择当前活跃连接数最少的服务器。
• 如果有多台服务器的活跃连接数相同，选择编号更小的那台。
• 请求按顺序处理，不考虑断开。

思路： 直接维护一个数组记录每台服务器的当前连接数。每次收到 CONNECT，遍历找出负载最小且编号最小的目标，增加它的连接数，记录日志。这一步是热身，很多人觉得简单就略过，但实际上它为后续的扩展打下了结构基础 — — 一定要用一个哈希表存储每个连接的详细信息（如 connId → {target, userId}），否则后面 DISCONNECT 和 SHUTDOWN 没法处理。

Part 2：引入 DISCONNECT

规则：

• 收到 DISCONNECT,connectionId 时，将该连接从它所在的目标服务器上移除，释放一个连接名额。

思路： 需要维护一个 connId → targetIndex 的映射，方便快速找到该连接属于哪个服务器，然后对应服务器的活跃连接数减一。这里的一个小坑是：DISCONNECT 一定对应一个已存在的连接，所以不需要做额外的校验，但如果在真实场景中，防御性编程可能会要求处理异常，面试时可以主动和面试官确认。

Part 3：基于 objectId 的路由

规则：

• 如果某个 objectId 当前已经有一台服务器在处理，那么后续任何包含相同 objectId 的 CONNECT 请求，必须路由到同一台服务器，以保持 notebook 的共享状态。
• 这个约束优先于负载均衡规则，但不能突破容量上限（Part 4 会引入容量限制）。

思路： 增加一个 objectId → targetIndex 的映射。每次 CONNECT 时，如果该 objectId 已经有绑定，则直接将该请求也分配到同一台服务器，即使这台服务器当前的负载不是最小的。当然，如果该服务器已经满了，如何处理？这就自然衔接到 Part 4。

这里容易忽略的是：一个 objectId 可能对应多个连接，当这些连接全部断开后，objectId 的绑定是否要解除？题目没有明确说，但通常的模拟逻辑是：如果某台服务器上该 objectId 的活跃连接数降为 0，则可以释放绑定，否则会影响后续新建连接的自由度。但 Stripe 这道题原题通常会简化成：只要该 objectId 还有任意一个活跃连接，绑定就维持；或者更简单地，一旦建立绑定，除非服务器 shutdown，否则不会主动解绑。具体要和面试官确认，但基本思路一致。

Part 4：目标服务器容量上限

规则：

• 每台服务器有 maxConnectionsPerTarget 的限制。如果一台服务器已满，则不再接受新的连接。
• 当为一个 CONNECT 请求选择目标时：
• 如果该请求有绑定的 objectId 且对应服务器未满，则路由到该服务器。
• 如果绑定的服务器已满，或者没有绑定，则在所有未满的服务器中，按照负载最小、编号最小的规则选择。
• 如果所有服务器都已满，或所有未满的服务器都无法满足（比如绑定服务器已满且没有其他可选），则该连接被拒绝，不记录日志。

思路： 在 Part 1 的选择逻辑中加入容量判断，遍历时跳过已满的服务器。对于有对象绑定的情况，如果绑定的服务器还有空位，就强行分配过去；否则，同样进入常规负载均衡逻辑，但绑定自然失效（或视为特殊情况）。核心是维护每台服务器的当前连接数，并与 maxConnectionsPerTarget 比较。

Part 5：服务器 SHUTDOWN

规则：

• 收到 SHUTDOWN,targetIndex 时，该服务器上的所有活跃连接被强制断开。
• 这些被驱逐的连接需要重新路由，就像它们是新到达的 CONNECT 请求一样，按照连接 ID 的字典序一个接一个处理。
• 重新路由时，同样要遵循所有的负载均衡和对象绑定规则（Part 3 和 Part 4）。
• 只有成功重新建立连接的请求，才会在日志中记录对应的新条目。如果因为容量满等原因无法重新路由，该连接就丢失了，不记录。
• 注意：SHUTDOWN 后该服务器上的原有连接全部清空，服务器的连接数归零，但服务器本身仍然存在，可以继续接受后续的新连接。

思路： 这一部分是最容易出错的。需要做的是：

• 找出目标服务器上的所有活跃连接，按照连接 ID 排序。
• 将该服务器的连接数和所有相关映射清除（注意更新 connId→target 映射、objectId 绑定关系等）。
• 将排序后的连接逐一作为“新请求”重新执行路由逻辑。注意，这些请求携带了原有的 userId 和 objectId，所以需要保存每个连接的完整信息。
• 重新路由过程中产生的成功连接，记录日志，追加到最终输出中。

很多人在处理 SHUTDOWN 时会忘记更新 objectId 绑定：如果被驱逐的连接正好是某个 objectId 的唯一连接，那么重新路由后可能被分配到其他服务器，此时绑定关系也应该更新到新服务器；而如果该 objectId 还有其他连接留在原服务器（不可能，因为整个服务器都 shutdown 了），所以实际上绑定关系需要重新建立。实现时务必小心处理映射的增删。

整体实现要点

• 数据结构：几个字典必不可少：
• conn_info: connId → {userId, objectId, targetIndex}
• target_load: 数组，每个目标服务器的当前连接数
• obj_target: objectId → targetIndex，绑定关系
• target_conns: 可选，targetIndex → set of connIds，便于 SHUTDOWN 时快速取出所有连接
• 处理流程严格按照请求顺序，模拟状态变化。
• 边界条件：maxConnectionsPerTarget 可能为 0？一般不会，但可以确认。如果为 0，则所有服务器不可用，所有连接拒绝。
• 日志记录：只有成功分配的 CONNECT 才输出，格式严格为 connId,userId,targetIndex。

这道题本质上是一个带约束的事件模拟，写起来代码量不大，但逻辑分支非常多，极其考验细心程度和代码组织能力。

岸不能靠碰运气，Stripe OA 这种模拟题更得练透

很多人觉得模拟题没有算法，不用专门准备，结果一到限时环境中，SHUTDOWN 的重新路由逻辑、对象绑定的优先级、满容量的拒绝处理，各种细节搅在一起，debug 时间直接爆炸。最近经手的几位同学，在 VO 辅助 OA辅导 的陪跑下，提前把 Stripe 的高频模拟题完整推演了多遍，包括各种边界和追问，真正笔试时心态稳得一批，最终顺利拿下 onsite。

如果你现在也在准备 Stripe 或其他大厂的 OA，担心自己卡在这些细节题上，不如让真正经历过北美一线大厂面试的专家带你走一遍。OA辅助、简历包装、VO 助攻，全程真人在线，不整 AI 模板，缺哪补哪。