首页/数据/NoSQL 速查/写入批量与重试策略
本包目录(322 条)

写入批量与重试策略

写入性能取决于批次大小、并发与压缩:常见实践是每批数千行、单请求控制在数 MB,开启 gzip;遇到 429/503 用指数退避重试,避免把集群压垮。

NoSQL 速查数据更新于 2026-10-12
批次每批约 5000 行左右是常见起点,按行宽与网络调整
并发单实例并发写入建议控制在个位数到十几个连接,过度并发反而触发限流
退避429/503 响应要退避重试;网络错误重试需保证幂等(同时间戳同标签覆盖写)
压缩Content-Encoding: gzip 对文本行协议压缩率很高

示例

示例
# 写失败时记录的响应示例(429 需要退避重试)
# HTTP/1.1 429 Too Many Requests
# {"code":"too many requests","message":"write rejected"}

# 认证与压缩头示例
# -H "Authorization: Token $INFLUX_TOKEN"
# -H "Content-Encoding: gzip"
客户端库通常已内置批量与重试,自研采集器要把队列长度、重试次数、丢弃数做成指标暴露出来。

易错点

  • 无限重试且不退避会造成持续过载,必须设置最大重试与丢弃策略
  • 批量过大时单条坏点会拖累整批,日志要保留错误行内容便于定位

数据来源与参考

  • InfluxData Docs: Write data best practices
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌