小红书 跨境电商&交易平台 一面

《面试题目》

1. 自我介绍
2. 详细讲一下什么是扫码当面付以及业务场景，你是怎么做的？
3. 讲一下整个链路是什么样的？
4. 扫码付中资金是怎么流转的？
5. 是参与其中一些小需求点的优化吗，听下来感觉对业务的描述有断点，是没有完整了解过这个链路吗
6. 你主要负责哪些内容的交付，熟悉哪一块？
7. 幂等保障你是怎么做的？
8. 说一下跨机房写入缓存？
9. 为什么要用线程池 + CountDownLatch？
10. 有没有了解过为什么要做单元化？
11. 单元化是用来解决什么问题的？
12. 做单元化时是按照什么来做的单元化路由，比如一笔流量过来怎么知道要去哪个单元？
13. 在做这个业务的时候对你来说挑战最大的点在哪，解决了哪些问题，成就最大的点？
14. 手撕：实现 LRU 缓存

《参考解析》

扫码当面付的链路怎么讲：面试官问「资金怎么流转」，是想听你说清楚一笔钱经过哪些系统。典型链路是：用户扫商户码 → 收银台 / 支付网关解析商户与订单信息 → 创建支付单（幂等）→ 调用渠道（微信 / 支付宝）下单 → 用户确认付款 → 渠道异步回调通知 → 支付系统校验签名与金额、更新支付单状态 → 触发业务动作（订单状态、账务记账、商户结算）→ 通知商户系统。资金流与信息流是两条：信息流走上述链路，资金流是渠道清结算后按 T+1 结算到商户账户，支付系统只记账不管钱。要主动交代幂等（同一笔回调重复到达）、对账（与渠道账单核对长款短款）、以及异常（超时未支付关单、退款链路）这几点，才算「完整了解过链路」。

跨机房写入缓存与 CountDownLatch：多机房场景下，「写本机房缓存 + 写远程机房缓存」需要并行才能把 RT 压下来，所以用线程池并发提交多个机房的写入任务，再用 CountDownLatch 等所有任务完成（或设置超时）后统一返回。要说的关键是：CountDownLatch 是一次性的计数闩，await(timeout) 必须带超时，避免某个机房卡死拖垮主流程；同时要处理部分失败（某个机房写失败怎么办——重试、异步补偿、还是以本机房为准并记录待同步）。更现代的写法用 CompletableFuture.allOf + orTimeout，语义更清楚。

幂等怎么做：先定义幂等键（业务单号、渠道流水号，或用户 id + 场景 + 请求参数的哈希），再用「唯一约束 + 状态机」保证只生效一次：数据库唯一索引兜底、Redis SETNX 抢占、状态流转必须按合法顺序（未支付 → 已支付，重复回调直接返回成功）。注意幂等键的长度与哈希选择（超过一定长度用 MD5 降级时要说明碰撞概率与误拦截风险，通常用带命名空间的前缀降低碰撞影响），以及幂等记录的有效期（太长占空间，太短覆盖不住重试窗口）。

单元化：单元化的目的是「把流量和数据的爆炸半径限制在一个单元内」——一个单元（机房 / 分区）具备完整的业务闭环，出故障时只影响部分用户，同时天然支持异地多活与就近接入。路由依据通常是「分片键」（用户 id 或商户 id 的哈希取模），一笔流量带着用户标识进入网关后，由路由层计算出所属单元再转发；难点在于跨单元的数据（比如全局流水号、跨用户交易）需要特殊处理（如中心单元记账、异步同步），以及数据同步与一致性。回答时把它和「异地多活」「故障隔离」「数据分片」串起来讲，比背定义更完整。

LRU 缓存手撕：标准解法是「哈希表 + 双向链表」：哈希表提供 O(1) 查找，双向链表维护访问顺序（头部最新、尾部最旧），get 命中就移到头部，put 时若 key 存在则更新并移到头部，不存在则插入头部并判断容量，超了就删尾部。工程细节：加虚拟头尾节点省掉边界判断，用 sync.Mutex / ReentrantLock 保证并发安全（或说明为什么用 ConcurrentHashMap + 细粒度锁），也可以直接用 LinkedHashMap 的 accessOrder + removeEldestEntry 一行搞定（面试时先说思路再选实现）。类似题还有 LFU（需要额外的频次桶或双哈希）。

这一轮的特点：连续追问业务链路（「听下来感觉对业务的描述有断点」）是小红书这类交易岗的典型风格——它默认你参与了真实链路，如果你只做了其中一小段，很难撑住三层追问。应对方式是老实圈定自己的范围（「我负责的是支付单状态机与幂等这块，上游下单和下游结算我了解流程但没深入」），然后在自己的范围内把细节讲到位；硬撑着讲全链路，反而会在细节点上露怯。作者也总结出「小红书不喜欢问八股」——这类公司更看重你对自己系统的理解深度。