InfluxDB客户端Write方法默认同步阻塞，因底层HTTP请求未异步封装；需用channel+goroutine实现可控写入队列，确保不丢、可降级、带重试与背压处理。
为什么直接用 InfluxDB.Client.Write 会阻塞？
Go 官方 influxdb1-client（v1）或 influxdb-client-go（v2）的 Write 方法默认是同步 HTTP 请求，底层调用 http.DefaultClient.Do，一次写入就卡住 goroutine，高并发下容易堆积、超时甚至压垮客户端连接池。这不是 InfluxDB 服务端的问题，而是客户端未做异步封装。
用 channel + goroutine 手动实现写入队列
最可控、无第三方依赖的方式：自己建一个带缓冲的 chan 做写入缓冲，另起 goroutine 消费。关键点不是“快”，而是“不丢、可控、能降级”。
-
chan缓冲区大小要设合理（比如 1000），太小易丢数据，太大占内存且掩盖背压问题 - 消费 goroutine 必须处理
Write失败（网络抖动、schema 错误、429 等），失败后建议打日志 + 退避重试（最多 2~3 次），别直接 panic - 写入前建议统一加
time.Now().UTC()时间戳，避免依赖服务端时间导致乱序
type Point struct {
Measurement string
Tags map[string]string
Fields map[string]interface{}
Time time.Time
}
<p>func NewWriter(client <em>influxdb2.Client, bucket, org string) </em>Writer {
ch := make(chan Point, 1000)
w := &Writer{ch: ch, client: client, bucket: bucket, org: org}
go w.run()
return w
}</p><p>func (w *Writer) Write(p Point) {
select {
case w.ch <- p:
default:
log.Printf("write queue full, drop point: %s", p.Measurement)
}
}</p><p>func (w <em>Writer) run() {
for p := range w.ch {
writeAPI := w.client.WriteAPI(w.org, w.bucket)
writeAPI.WritePoint(p.ToPoint()) // ToPoint() 将结构转为 influxdb2.Point
if err := writeAPI.Flush(); err != nil {
log.Printf("write failed: %v", err)
time.Sleep(100 </em> time.Millisecond) // 简单退避
}
}
}用 influxdb-client-go 的 WriteAPI 内置异步能力？
注意：WriteAPI 本身不提供“真正异步”接口 —— 它的 WritePoint 只是把数据塞进内部 buffer，Flush 才发请求；而 WriteRecord 同理。它没暴露 buffer 控制权，也不支持自定义重试/背压策略，生产环境慎用默认配置。
- 必须显式调用
Flush或启用自动 flush（WriteAPIConfig.BatchSize和FlushInterval），否则数据可能滞留内存不发出 -
BatchSize默认 1000，但若单条 record 很大（比如含长字符串 tag），实际 HTTP body 可能超 InfluxDB 默认 25MB 限制，触发 413 错误 - 没有写入确认回调，失败时仅记录 error 日志，无法感知哪条丢了
什么时候该考虑用 Kafka / Redis 中转？
当写入峰值远超 InfluxDB 单节点吞吐（比如 > 5k points/sec）、需要严格保序、或要求写入失败后可重放时，直连 InfluxDB 的异步化已不够用。这时应把采集层和存储层解耦：
立即学习“go语言免费学习笔记（深入）”；
- 采集服务只往 Kafka 发消息，由独立的 writer service 拉取、批量转换、重试写入
- Kafka offset 提供精确 once-only 语义，比内存 channel 更可靠
- Redis List + Lua 脚本也能做轻量级中转，但无持久化保障，适合容忍少量丢失的场景
真正的难点不在“怎么发得快”，而在“怎么确保不丢、不重复、可监控”。buffer 大小、重试策略、错误分类（临时性 vs 永久性）、metric 上报延迟，这些细节比选哪个库更重要。
