InfluxDB 1.8 OSS多进程写入时measurement字段值混杂问题咨询

最高概率原因：跨进程共享非进程安全的Python客户端实例 #

influxdb==5.x 等适配InfluxDB 1.8的Python客户端本身不支持多进程共享使用。如果在主进程提前初始化客户端连接，再通过multiprocessing fork子进程复用该实例，会触发底层连接池、批量写入缓冲区的状态错乱：不同子进程提交的写入点会被混入同一个HTTP批量请求发往服务端。
这类批量请求如果没有逐点显式声明所属measurement，客户端会默认取请求内第一个点的measurement值作为整批点的写入目标，直接导致measurement2的field被写入measurement1下。

验证方法：临时关闭多进程，改为单进程顺序写入，若串field问题完全消失，即可确认是该原因
修复方案：禁止跨进程传递、复用InfluxDB客户端实例，每个子进程启动后独立初始化属于自己的客户端连接。

次高概率原因：写入点构造时复用可变对象导致字段残留 #

如果两个写入函数复用了同一个外层作用域的fields字典、Point模板对象，且每次写入前没有清空历史字段、没有做深拷贝，就会把其他measurement的field键值残留在当前待写入的点结构里。典型错误写法：

# 错误写法：复用全局fields字典
field_cache = {}
def write_measurement1():
    field_cache["Apple"] = 123
    field_cache["Banana"] = 456
    # 未清空field_cache中之前写入的Potato、Onion等key
    client.write_points([{"measurement": "measurement1", "fields": field_cache}])

def write_measurement2():
    field_cache["Potato"] = 789
    field_cache["Onion"] = 101
    client.write_points([{"measurement": "measurement2", "fields": field_cache}])

即使用了多进程的fork启动模式（写时复制独立内存），只要子进程内的写入逻辑复用了从主进程继承的可变字典对象，且没有做初始化清空，就会出现字段混带的问题。

验证方法：在每次调用写入接口前，打印完整的待写入点结构，检查是否已经混入非当前measurement的field
修复方案：每次构造写入点时新建空的fields字典，不要复用历史字典对象；必须用模板的话，调用copy.deepcopy()复制模板后再修改赋值。

其他常见触发原因 #

• 调用write_points接口时传入了全局measurement参数，待写入的点列表里混入了其他measurement的点且没有逐点声明自身measurement，客户端会把整批点都写入全局指定的measurement下。并行写入时批量攒点逻辑更容易出现这类列表污染。
• 自行拼接InfluxDB行协议时漏写不同点之间的换行符，导致服务端解析时把后续measurement的field识别为当前measurement的字段。错误行协议示例：

  measurement1 Apple=1,Banana=2 Potato=3,Onion=4
  

  正确格式要求不同measurement的点之间必须用换行分隔。

内容的提问来源于stack exchange，提问作者sreevalsan