解读

面试官把“1000 万点/秒”抛出来，核心不是考你会不会背参数，而是看你在国内真实高并发场景下：

1. 把“业务点”换算成“InfluxDB 行协议点”——搞清楚 1 条行协议到底含几个 field、tag，从而估算真实写入行数；
2. 在 shard 与 batch 两个维度做权衡，既不让 shard 过早分裂，也不让 batch 过大触发 OOM；
3. 用可重复、可量化的手段证明“零丢点”，而不是口头说“应该没丢”。

国内互联网环境常用 16C32G～64C128G 物理机、万兆网、SSD 或 NVMe，JDK 与 Go 版本固定，面试官希望你把参数、监控、验证三板斧讲透。

知识点

1. InfluxDB 数据模型：measurement + tag set + field set + timestamp = 1 行，1 行可含多 field，但写入吞吐按“行”算。
2. shard 与 shard group：shard group duration 决定同一时间范围内数据是否落同一 shard，shard 过多会放大索引开销。
3. batch：客户端一次 POST /write 的行数；受 max-body-size、max-row-count、内存队列三方面限制。
4. 写入路径：HTTP → Hinted-handoff → WAL → Cache → TSM → Compaction；丢点常发生在 HH 丢包、WAL 刷盘失败、客户端超时重试去重。
5. 国内常用验证手段：二分时间戳比对、series cardinality 指纹、CRC32 校验文件，配合 Grafana + Loki 做审计日志。

答案

一、需求换算
假设 1 行协议平均 200 Byte，1000 万点/秒 ≈ 2 GB/s 网络吞吐，单物理机万兆网 1.25 GB/s 打满，必须三节点集群负载均衡，每台目标 350 万点/秒。

二、shard 调优

1. 预估保留策略 7 天，数据总量 ≈ 2 GB/s × 604800 s ≈ 1.2 PB。
2. 按“单 shard 100 GB 以内查询性能最佳”的经验，shard group duration 取 6 h，这样 7 天共 28 个 shard group，每个 group 内数据≈ 42 GB，合理。
3. 提前预建 shard：在业务低峰期通过 CREATE SHARD GROUP 手动触发，避免写入高峰自动建 shard 的锁竞争。
4. 关闭不必要的 series 索引（如高频 tag 值离散度>100 万），设置 max-series-per-database=0 先观察，再按实际 cardinality 收紧。

三、batch 调优

1. 客户端采用官方 telegraf 或自研 Go 客户端，开启 UDP 负载均衡到 3 台 data node。
2. batch-size 行数：单批 5000 行，单批大小≈ 1 MB，既小于默认 max-body-size=25 MB，又降低 RTT。
3. flush-interval=200 ms，保证 1 s 内 5 批，单台 350 万点/秒 ÷ 5 = 70 万行/批，与 batch-size=5000 匹配需 140 并发连接，用协程池控制。
4. 开启 retry-on-failure=3，退避策略 50 ms→100 ms→200 ms，防止突刺造成 HH 堆积。
5. server 端调大 max-concurrent-write-limit=0（关闭限流），wal-fsync-delay=0 ms（SSD 场景），wal-max-write-delay=10 min，给 WAL 充分刷盘时间。

四、无丢点验证

1. 审计日志：客户端在每条行协议尾部注入递增 fingerprint=trace_id，写入前落本地磁盘顺序文件。
2. 二分查询：写入结束后，按 1 min 粒度对 fingerprint 做二分排序，取最大值与最小值，计算期望值=最大值-最小值+1，与实际查询返回条数对比，差值为 0 即无丢。
3. 时间戳对齐：用 SELECT COUNT(fingerprint) GROUP BY time(1s) 填充 0 值，检查是否有秒级断档。
4. 双写校验：10% 流量同步写 Kafka，再独立消费写入临时库，最后与 InfluxDB 做集合差。
5. 资源监控：写入期间 Grafana 看 WAL 文件数是否持续增长、HH 目录是否为空、memTable 占用是否低于 80% 阈值，确保无反压。

五、结果
按以上参数，三节点 64C128G NVMe Raid0 环境实测稳定 360 万点/秒，CPU 60%，磁盘写带宽 900 MB/s，网络 950 Mb/s，二分指纹验证 0 丢点，达到 SLA。

拓展思考

1. 若业务要求 30 天保留、查询跨度一周，shard duration 继续 6 h 会导致 shard 数量 120，查询需合并大量 TSM 文件，此时可牺牲部分写入吞吐，把 duration 提到 24 h，并开启 tsi1 索引，用磁盘换查询性能。
2. 如果未来点/秒再翻倍到 2000 万，单集群已无法水平扩展，需考虑 InfluxDB IOx 或 Kafka→ClickHouse 架构，面试时可主动抛出“换引擎”的边界条件，体现容量规划前瞻性。
3. 国内金融场景对“零丢点”要求 6σ，可引入三副本 quorum 写入、客户端本地双缓存 + 幂等 ID，面试中把“成本”与“一致性”摆到台面上，展示全链路思维。