解读

面试官真正想考察的是：

1. 能否把“100 并发 × 10 TB × 三副本”这一看似夸张的指标拆解成可落地的性能模型；
2. 是否理解国内主流分布式存储（Ceph、HDFS、TiKV、PolarDB-X、阿里云盘古、腾讯云TFS 等）在副本一致性、故障域、限流、背压、校验和等方面的实现细节；
3. 能否用可观测手段（metrics + tracing + profiling）证明“数据真没丢”，而不是拍胸脯保证；
4. 是否具备“容量-并发-副本”三角平衡意识：副本数翻倍，写入放大至少 3×，网络、磁盘、CPU、内存、IDC 机架带宽、交换机收敛比都会成为瓶颈；
5. 能否给出灰度、回滚、故障演练方案，体现生产安全意识。

知识点

1. 国内 IDC 网络现状：25 GbE/40 GbE 为主，TOR 收敛比 1:3～1:5，跨机架写三副本必须考虑机架故障域。
2. 三副本一致性协议：Raft（TiKV、PolarDB-X）、Paxos（OceanBase）、Primary-Backup（HDFS）、CRAQ/Chain Replication（自研）。
3. 写放大模型：客户端吞吐 × 副本数 × 编码/校验开销 × 网络重传系数 ≈ 后端实际落盘量；10 TB 业务数据 ≈ 30 TB 落盘，再考虑 20 % 校验和与日志，总磁盘写入 36 TB。
4. 并发模型：100 并发 ≠ 100 线程，可能是 100 条 gRPC 流、100 个 Flink slot、100 个 k6 VU；需明确“并发”指客户端并发度还是服务端并发度。
5. 压测工具链：
   • 客户端：go-ycsb、tsbs、k6、JMeter-RaftPlugin、自研 gRPC 压测框架；
   • 服务端：Ceph perf、HDFS DFSAdmin、TiDB tikv-details、OpenTelemetry + Prometheus；
   • 故障注入：ChaosMesh、Alibaba ChaosBlade、自研基于 eBPF 的 netem。
6. 数据完整性校验：端到端 CRC32C、Merkle Tree、周期性 CRC 对账、后台 Scruber、副本间 diff-repair。
7. SLA 量化：RPO=0（不丢数据）、RTO≤30 s、写延迟 P99≤100 ms、吞吐≥2 GB/s。
8. 国内合规：等保 2.0 要求“剩余信息保护”“数据完整性”“网络安全审计”，测试报告需留痕。

答案

回答时分四步：建模 → 场景设计 → 执行验证 → 兜底复盘，全程用数字说话。

1. 建模
   a. 业务数据量：10 TB 逻辑数据，条均 1 KB → 约 100 亿条记录。
   b. 副本策略：强同步三副本，机架级故障域，写 quorum=2，读 quorum=2，保证 RPO=0。
   c. 写放大：3 副本 × 1.2（日志+校验） ≈ 3.6 ×，总物理写入 36 TB。
   d. 目标吞吐：希望在 2 h 内完成，则平均吞吐需 ≥ 5 GB/s；单客户端 50 MB/s，需 ≥ 100 并发。
   e. 网络：36 TB / 2 h = 40 Gb/s，占 4 条 25 GbE 链路，TOR 收敛比 1:3 时，需独占 2 台 TOR 的上行，避免与线上混布。

2. 场景设计
   a. 客户端分层：

   • 控制面：Kubernetes Job，100 个 Pod，每个 Pod 1 个 gRPC 长连接，限速 50 MB/s；
   • 数据面：每条记录带 8 B 单调递增 key + 992 B 随机 payload，key 范围 0～99 9999 9999，保证均匀分布与可校验。
     b. 服务端：
   • 存储池 12 台 NVMe 服务器，每台 12 × 7.68 TB，总裸容量 1.1 PB，可用 60 % 约 660 TB，富余度 18 ×；
   • 每个 OSD/ChunkServer 绑定 2 个 25 GbE 口，做 LACP，冗余 1 台交换机故障。
     c. 一致性参数：
   • Raft heartbeat 300 ms，election timeout 1.5 s，log replication 流水线 64 in-flight，开启 pre-vote；
   • 开启 checksum=on、flush=sync、wal-fsync=1，保证掉电不丢。
     d. 限流与背压：
   • 客户端令牌桶 50 MB/s；
   • 服务端基于 PD/Manager 动态下调写入带宽，当磁盘 util>80 % 或延迟 P99>100 ms 时触发背压。

3. 执行验证
   a. 预跑 1 % 数据（100 GB）热身，确认热点均衡、CPU iowait<10 %、网络 retrans<0.01 %。
   b. 全量跑：

   • 监控 Prometheus：rate(tikv_grpc_msg_duration_seconds_count) ≈ 5 GB/s，P99 latency<80 ms；
   • 巡检副本健康：tikv_raftstore_region_count 与 tikv_store_size_bytes 三副本差异<0.1 %；
   • 完整性：每 10 s 抽样 1 ‰ 记录，实时计算 CRC32C，与存储端返回值比对，误差=0；
   • 故障演练：随机下线 1 台 OSD（机架级），Raft 在 6 s 内选主，写吞吐下降 15 %，无丢数据报警。
     c. 结果：
   • 总耗时 1 h 58 min，平均吞吐 5.1 GB/s，峰值 5.3 GB/s；
   • 端到端 CRC 比对 100 亿条全部通过；
   • ChaosMesh 注入 7 类故障（网延迟、磁盘慢盘、CPU 打满、断电 OSD），RPO=0 全部满足。

4. 兜底复盘
   a. 数据稽核：跑完 24 h 后，后台 Scruber 全量扫描，三副本 Merkle Tree 对账，差异记录 0。
   b. 报告：输出《性能测试报告》《风险评估报告》《等保合规检查表》，留档 GitLab，供审计。
   c. 优化建议：

   • 磁盘 util 峰值 82 %，建议换 PCIe 4.0 NVMe，降低 10 % 延迟；
   • 跨机房写三副本时延 18 ms，可调整写 quorum=2+异步第 3 副本，降低 P99 到 50 ms，但需业务接受最终一致。

拓展思考

1. 如果预算减半，只能提供 1.5 倍副本磁盘，如何“逻辑三副本”不丢数据？
   答：采用 1.5 副本 EC（10+4）+ 异步第 3 副本快照上云（OSS/COS），通过 CRC 对账+增量修复，RPO≤5 min，成本降 40 %。

2. 若业务要求“100 并发写 10 TB”同时“混合读 1 万 QPS”，如何防止读干扰写？
   答：使用 QoS 流控，把读写分别放入不同 io_ cgroup，写带宽预留 60 %，读 IOPS 限制 2 万；客户端采用 hedged read（50 ms 超时触发第二副本读），保证读 P99<50 ms。

3. 当测试环境无法提供 10 TB 真实数据时，如何“等比例缩容”验证三副本一致性？
   答：采用“时间换空间”模型：把 10 TB 按 1:100 采样到 100 GB，但保持 key 空间哈希分布一致；同时把并发度从 100 提到 1000，把单条延迟压到极限，验证副本算法正确性；最后再用数学外推证明全量场景下一致性误差概率<10^-15。