直接写InfluxDB易压垮客户端或服务端，因高频小批量写入导致HTTP开销大、连接复用不足，引发客户端空闲连接关闭或服务端429错误；应用层每条指标立即发送既浪费资源又难控速率与重试，需通过channel缓冲攒批（如chan *Point）、定时/定量触发WriteRecords，并配超时与错误丢弃策略。
为什么直接写InfluxDB容易压垮客户端或服务端
InfluxDB 的 HTTP 写入接口对高频小批量写入不友好：每次 POST /api/v2/write 都带 HTTP 开销，连接复用有限；并发太多时，客户端可能触发 http: server closed idle connection 或服务端返回 429 Too Many Requests。更关键的是，应用层若每条指标都立即发请求，既浪费资源，又难控速率和失败重试。
缓冲的本质是“攒够一批再发”，而 Go 里最自然的攒批机制就是用 chan []map[string]interface{}（或更推荐的 chan []*Point）做生产-消费解耦。
用带缓冲的 channel 控制写入批次与节奏
核心思路：业务 goroutine 只管往 channel 发单点数据（*Point），一个专用 writer goroutine 从 channel 批量收、聚合、调用 InfluxDB client 写入。
pointsCh := make(chan *Point, 1000) // 缓冲区防阻塞生产者
go func() {
batch := make([]*Point, 0, 200)
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
<pre class='brush:php;toolbar:false;'>for {
select {
case p := <-pointsCh:
batch = append(batch, p)
if len(batch) >= 200 {
writeBatch(batch)
batch = batch[:0]
}
case <-ticker.C:
if len(batch) > 0 {
writeBatch(batch)
batch = batch[:0]
}
}
}}()
立即学习“go语言免费学习笔记（深入）”；
注意三点：
-
chan *Point容量设为 1000 是经验值，太小易阻塞业务逻辑，太大内存占用高且延迟不可控 - 批次大小（200）和超时（1s）要根据你的
Point字段数、tag 数量、网络 RTT 调整；实测中 100–500 条/批较稳 - 不要用
len(batch) == cap(batch)触发 flush，因为append后底层数组可能扩容，len和cap关系不稳定
如何安全处理写入失败与 channel 关闭
writer goroutine 不能因一次 WriteAPI.WritePoint() 失败就退出，否则未消费的 pointsCh 数据会堆积并最终卡死生产者。
func writeBatch(pts []*Point) {
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<pre class='brush:php;toolbar:false;'>err := writeAPI.WritePoint(ctx, pts...)
if err != nil {
log.Printf("write batch failed: %v, dropping %d points", err, len(pts))
// 这里不重试：重试需考虑幂等性、顺序、过期点；简单场景直接丢弃更可控
return
}}
关键细节：
- 必须加
context.WithTimeout，否则网络卡住时 goroutine 永久 hang 住 - 不要 panic 或 os.Exit，writer 应持续运行
- 若需重试，建议把失败批次写入本地磁盘队列（如 SQLite 或 boltdb），而非内存重入 channel —— 否则可能无限循环或重复写入
- 关闭 channel 前，先 close(
pointsCh)，再用 sync.WaitGroup 等待 writer 退出；但通常 writer 应长期存活，无需主动关
用 influxdb-client-go 的 WriteAPI 时要注意什么
官方 SDK influxdata/influxdb-client-go 的 WriteAPI 本身已内置缓冲和异步发送，但默认只缓存 1000 点且无超时控制，不能直接替代自建 channel 缓冲。
你仍需自己控制：
-
WriteAPI实例应全局复用，不要每次写都 New - 调用
WritePoint()是同步非阻塞的，它只是把点塞进内部 buffer，真正发请求由后台 goroutine 完成 - 内部 buffer 满时会 block，所以你自己的 channel 缓冲仍是必要的前置保护
- 若启用了
WriteOptions.BatchSize(200)，它只影响内部 flush 阈值，不解决你业务层高频WritePoint()调用带来的锁竞争问题
真正省事的做法是：关掉 SDK 自带缓冲（WriteOptions.BatchSize(1)），完全由你自己的 channel + 定时器控制批次，这样逻辑清晰、可监控、易调试。
InfluxDB 批量写入的缓冲难点不在“怎么攒”，而在“攒多少、何时发、错了怎么办”——这三个决策点都得结合你的采集频率、点结构、错误容忍度来调，没有银弹。
