这道 Stripe 的 HackerRank OA 真题是一道非常高频的系统模拟题，背景来源于 Jupyter load balancing 的实际工程场景。Stripe 的 Notebook 平台运行在 Jupyter 上，而 Jupyter 在面对大量用户时性能下降明显，因此公司会部署多个 Jupyter servers，并通过一个 load balancer 自动分配用户请求。这道题的目标是模拟这一逻辑，实现一个函数 route_requests()，用于确定每个 incoming request 应该被路由到哪个目标服务器。虽然题目不涉及真实的网络通信，但它要求完整模拟连接建立、断开、对象共享、capacity 限制以及 server 重启等一系列复杂的行为。

虽然说是一小时完成一道题，但是难度远大于tiktok的一小时四道题。

函数 route_requests(numTargets, maxConnectionsPerTarget, requests) 接收三个参数，分别代表 number of target servers、maximum connections per server、以及 request sequence。每个请求字符串格式可能为 action, connectionId, userId, objectId 或 action, targetIndex。返回值是一个字符串数组，包含所有成功的 CONNECT 操作结果，格式为 connectionId, userId, targetIndex。题目共分五个阶段（Part 1–5）每个阶段在前一阶段的逻辑上递进，最终形成一个接近真实系统负载均衡器的完整模拟。

Part1

第一部分是 Basic Load Balancing。这一阶段要求实现最基本的调度逻辑。程序需要维护每台 server 当前的 active connection 数量，当有新的 CONNECT 请求到达时，应选择负载最小的 server。如果有多个负载相同，则选择 index 最小的一个。每个请求独立处理，与用户或对象无关。核心思路是通过一个 array 或 dictionary 跟踪当前各 server 的连接数量，并在 O(1) 时间内找到最优目标。

Part2

第二部分是 Modeling Disconnection。在第一阶段的基础上新增 DISCONNECT 请求。系统需要维护一个 connection mapping table，记录每个 connectionId 当前所在的 server。当接收到断开请求时，从 mapping 中查找该 connectionId，释放相应的 server 负载。这要求在数据结构层面保持 connection 与 server 状态同步，以确保负载统计正确。实现的重点在于使 connect 与 disconnect 操作的更新成本都保持常数级别。

Part3

第三部分是 Routing Based on Object ID。这一阶段引入了对象一致性（object-level consistency）的约束。Jupyter notebooks 的多个用户可能共享同一个 objectId（即共同编辑同一个文档），因此这些请求必须被路由到同一台 server。程序需要维护一个 objectId → targetIndex 的映射表，当有新请求到达时，如果 objectId 已经存在，就直接使用同一台 server；否则执行常规的负载均衡逻辑。难点在于维护 object-server 绑定关系的正确性，并在连接断开后及时清理。

Part4

第四部分是 Target Size Limits。本阶段模拟服务器容量限制。每台 server 最多可承载 maxConnectionsPerTarget 个连接。当 server 达到上限后，它将从候选列表中排除。如果所有服务器都已满载，新请求将被拒绝，不会输出日志。同样，如果一个 objectId 已绑定的 server 已经满载，即使按照一致性规则该 server 是正确目标，也必须拒绝该连接。思路是增加容量检查逻辑，动态地跳过 overloaded targets。实现过程中需要保证 routing 决策的稳定性与一致性。

Part5

第五部分是 Target Shutdown。该阶段模拟服务器暂时下线的情况。当收到 SHUTDOWN,targetIndex 请求时，表示该 server 需要 temporarily reboot。系统必须立即驱逐（evict）该 server 上所有 active connections，并重新按照之前的 routing 规则将它们迁移到其他 server。这一过程称为 connection re-routing。被重新路由的连接也会被记录在输出日志中。题目假设 shutdown 是瞬时的，服务器会立即恢复，因此后续请求仍可被分配到它上面。思路是先收集被驱逐的连接，更新状态映射，再逐一调用先前的 routing 逻辑为其分配新 server。

整体实现中需要同时维护四个核心数据结构：connection_map（connectionId → server index）、object_map（objectId → server index）、target_load（server index → active count）、以及 shutdown_targets（暂时不可用服务器集合）。这些状态共同描述了系统的全局状态。每次操作都需要保证这四张表的数据一致性。在复杂度上，每个请求的处理应为 O(1)，从而在大规模输入下保持高效。对于 SHUTDOWN 操作，可能需要遍历被驱逐连接，但整体依然能保证线性复杂度。

这道题是 Stripe HackerRank 中非常有代表性的 system simulation problem，融合了负载均衡策略、状态同步、对象一致性、capacity control 以及容灾恢复逻辑。在一小时内完成全部五个阶段，意味着你能快速构建并实现一个具备动态调度、资源管理、consistency 约束与 failover 恢复机制的系统原型。