QuestDb使用Influx行协议写入时出现重复记录的问题咨询

已知接入基础配置与异常特征如下：

• 时序存储层使用QuestDB，通过InfluxDB SDK实现数据写入，核心写入逻辑为：

influxDB = InfluxDBFactory.connect("http://localhost:9000", username, password);
influxDB.setDatabase(database);
influxDB.enableBatch(BatchOptions.DEFAULTS);
influxDB.write(Point.measurement(TABLE_NAME)
                .addField("ID",ir.getid())
                .addField(....)
                .build());

• 写入流程未主动传递时间戳字段，依赖QuestDB自动使用服务端接收时间作为记录的时间戳
• QuestDB服务端配置为单工作线程运行模式
• 业务侧已做单条写入记录的ID字段唯一性保障
• 异常表现：查询时偶发出现同一ID对应最多5条完全重复的业务记录，所有业务字段值完全一致，仅相邻重复记录的时间戳存在约10秒间隔

所有现象的核心逻辑是客户端无幂等重试能力 + 服务端无有效重复拦截机制的组合问题，具体分为三类：

• InfluxDB SDK批量模块的无校验重试逻辑
  开启enableBatch(BatchOptions.DEFAULTS)默认配置后，批量运行为异步模式：客户端会先将业务侧提交的Point放入内存队列，按固定批次攒包后统一发送。当出现网络瞬断、请求超时、QuestDB返回临时错误时，SDK默认的重试策略不会校验此前的批次是否已被服务端成功落盘，会直接把失败的批次重新放回发送队列重发。默认配置下该重试的最大次数为5次，叠加服务端单线程模式下的请求排队延迟，重试触发的写入时间和上一次请求的处理时间刚好形成约10秒的相邻间隔，和观察到的现象完全匹配。加之写入时未携带客户端生成的固定时间戳，QuestDB每收到一次相同内容的请求，都会生成新的服务端时间戳作为落盘版本，不会判定为重复记录。
• 写入设计缺失服务端去重的有效维度
  QuestDB对接InfluxDB线协议时，仅会对所有tag字段、时间戳字段完全一致的行做覆盖去重，不会针对普通业务字段（也就是通过addField传入的ID字段）做去重校验。当前将全局唯一的ID放在普通字段（Field）而非维度字段（Tag）中，且没有传入固定的客户端时间戳，服务端根本没有可用于识别重复写入的判定维度，就算收到完全相同的业务内容，也会全部作为新记录落盘，没有任何重复拦截能力。
• 单工作线程模式下的请求超时错配
  QuestDB配置为单工作线程运行时，写入处理能力存在明确上限，当短时写入量超过处理阈值时，服务端请求排队耗时会快速上升，很容易超过客户端SDK默认的请求超时时间。此时客户端会判定该次写入失败、触发重试，但服务端实际上已经完成了该批次数据的落盘操作，只是还在排队返回响应，最终就会造成同一份数据被重复写入，两次写入的时间差刚好匹配服务端排队耗时和客户端重试间隔。

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