解读

在国内互联网/基础架构岗位的面试里，面试官问“并发集合的扩展性”并不是想听“加锁”或“无锁”两个词就结束，而是希望候选人能给出可量化、可复现、贴合业务的评估体系，并能把 Rust 的内存模型、调度器开销与硬件拓扑结合起来。核心考察点有三：

1. 是否理解扩展性（Scalability）≠ 绝对性能（Performance）；
2. 能否用Rust 原生工具链把指标跑出来，而不是空谈理论；
3. 能否把结果翻译成业务语言，指导容量规划。

知识点

1. 扩展性维度

   • 强扩展：固定总工作量，线程数从 1 到 N，看加速比（Speedup）= T₁/Tₙ；理想值是线性，Rust 中可用 std::thread::scope 快速搭原型。
   • 弱扩展：单线程工作量固定，线程数与总工作量等比增加，看效率（Efficiency）= T₁/(N·Tₙ)；云原生场景更关注这一条。

2. Rust 侧关键指标

   • CPU 级：每操作平均 CPU 周期（cycles/op），用 perf stat -e cycles,instructions,cache-misses 采集；Rust 编译器开启 codegen-units=16 lto=thin 避免内联差异。
   • 内存级：跨 NUMA 节点远程内存访问率（NUMA ratio），numactl --hardware 看节点距离，再用 perf c2c 查伪共享；Rust 的 crossbeam::cache_padded 可显式对齐。
   • 调度级：锁竞争率（contention rate） = 获取锁总耗时 / 总耗时，parking_lot::Mutex 自带 raw() 拿内部统计，可直接打印。
   • 尾部延迟：P99.9 延迟，用 hdrhistogram::Histogram 在 Rust 侧无锁采样，避免 Instant::now() 系统调用开销。

3. 基准测试框架

   • Criterion.rs：支持渐增线程数的 BenchmarkGroup，自动计算加速比置信区间；配合 cargo bench -- --save-baseline 可回归。
   • Miri + Loom：在 CI 阶段跑并发模型验证，保证无数据竞争，防止“跑分正确、线上崩溃”。

4. 业务映射

   • 把吞吐换算成QPS/核，再除以单核成本（元/年），得到“每元 QPS”；国内云厂商预算评审常用此口径。
   • 若 P99 延迟随线程数呈指数>1 上扬，即出现“延迟悬崖”，此时扩展性已失效，需降级为分片架构。

答案

衡量 Rust 并发集合的扩展性，我采用“三步七指标”法：

1. 选基准：用 Criterion.rs 构造混合读写负载，读占 80%、写占 20%，数据规模设为L3 缓存的 2 倍以暴露 NUMA 效应。
2. 采指标：
   • 强扩展加速比 ≥ 0.7×线性视为合格；
   • 每操作 CPU 周期增长 ≤ 15% 当线程翻倍；
   • 锁竞争率 ≤ 5%，否则回退到 crossbeam::SkipSet 或 flurry 分段结构；
   • NUMA 节点间远程访问率 ≤ 10%，超标则在 numactl --cpunodebind 下重测；
   • P99.9 延迟斜率 ≤ 1.2×线程数，否则记录为扩展性拐点。
3. 换业务：把最高吞吐换算成QPS/核，再乘以云主机单价，得出“每元 QPS”；若该值随线程数增加而单调不升，则认定扩展性良好，可直接进入容量池。

整套流程用 GitHub Action nightly 跑，cargo bench --features nightly 自动生成报告，编译通过即基准通过，符合 Rust 社区文化。

拓展思考

1. 当集合操作跨 NUMA 绑定线程时，Rust 的 std::thread::spawn 默认不感知拓扑；可封装一个 numa_aware_spawn 宏，在启动前读取 /sys/devices/system/node/nodeX/cpulist，把线程亲和性写进 tokio::task::spawn_blocking 的 core_affinity，实现用户态调度下沉。
2. 对于异步化场景，可把并发集合包进 tokio::sync::RwLock 再跑相同指标，观察阻塞 vs 异步两种模型在相同 CPU 核心下的能效比；若异步版本吞吐反而下降，说明集合内部临界区过短，同步模型更省调度开销，此时应果断回退。
3. 国内大厂常要求双十一压测与离线基准对齐；可用 cargo flamegraph 采样线上火焰图，把热点函数周期数映射到离线基准，建立数字孪生模型，实现“线下 1 核结论直接放大到线上 128 核”，减少真实压测成本。