写入批量与重试策略是什么
时序写入性能取决于批次大小、并发与压缩：常见实践是每批数千行、单请求控制在数 MB，并开启 gzip；遇到 429 或 503 要退避重试，而不是持续加压。同一时间戳加相同标签组合的写入会覆盖旧值，这让重试天然具备幂等性。自研采集器要把队列长度、重试次数与丢弃条数做成指标暴露出来，否则一旦积压只能从业务现象去猜。
基本信息
| 批次 | 每批数千行是常见起点，按行宽与网络调整 |
|---|---|
| 并发 | 单实例控制在较小范围，过度并发反而触发限流 |
| 退避 | 429 / 503 要退避重试，网络错误重试依赖覆盖写幂等 |
| 压缩 | Content-Encoding: gzip 对文本行协议压缩率很高 |
| 可观测 | 队列长度、重试次数、丢弃条数 |
| 所属系统 | InfluxDB 写入实践 |
典型使用场景
- 批量导入：把历史数据整理成批次写入，控制单请求体积
- 采集器调优：按行宽调整批量行数
- 限流应对：出现 429 时退避并降低并发
- 网络抖动：重试依赖同时间戳同标签的覆盖写特性
- 链路巡检：用重试与丢弃指标判断吞吐是否健康
错误与请求头示意
错误与请求头示意
# 写失败时的响应示例（429 需要退避重试）
# HTTP/1.1 429 Too Many Requests
# {"code":"too many requests","message":"write rejected"}
# 认证与压缩头示例
# -H "Authorization: Token $INFLUX_TOKEN"
# -H "Content-Encoding: gzip"
# 幂等依据：同时间戳 + 相同标签组合的写入会覆盖旧值写入参数取舍
| 维度 | 常见做法 | 代价 |
|---|---|---|
| 批量行数 | 数千行一批 | 过大时单条坏点影响整批 |
| 请求体积 | 控制在数 MB | 过大容易超时与重传 |
| 并发连接 | 较小并发 | 过高会触发限流 |
| 压缩 | 开启 gzip | 少量 CPU 换带宽 |
| 重试 | 指数退避 | 无限重试会持续过载 |
客户端库通常已内置批量与重试机制；自研采集器要把队列长度、重试次数与丢弃数做成指标暴露，出问题时才有线索。
无限重试且不退避会造成持续过载，必须设置最大重试次数与丢弃策略，并记录被丢弃的数据范围。
批量过大时一条坏点会拖累整批，日志要保留出错的行内容与批次标识，便于定位与重放。