Shell.Xu

首先明确一点。proxy是在数据校验OK后直接返回成功的，其间并不保证数据向后写入是否正确。数据写入需要看proxy自身向后的刷写是否成功。你可以看一下proxy的日志，看看向后写入是否成功，还是有什么问题。

另外，注意到你的请求返回错误是400，而不是无数据。我现在记得不是很清楚，但是400这个错误并不是无数据，而是你的请求本身并不被接纳的结果。你可以试试直接query目标看看。

你的这个配置和你的写入对不起来，CPU的写入明显是映射到local，没有local2。写入的时候当然只有主节点有数据。至于test_proxy这个数据，如果你用最新版本的话，默认的配置是_default_而不是default。因此根本无法写入。 查询失败是因为query forbidden，估计是因为查询中不带时间。我们默认禁止这样的查询，因为这个会消耗巨量的CPU资源。具体可以看这个文件。其中SupportCmds是必须保持部分，如果无法带有其中之一，则查询被禁用。 https://github.com/shell909090/influx-proxy/blob/master/backend/commands.go 这一功能可以禁用以下代码关闭。 https://github.com/shell909090/influx-proxy/blob/master/backend/cluster.go#L383

您好，您的查询不符合influxdb标准，请使用influxdb客户端，或者根据标准修正格式。 https://docs.influxdata.com/influxdb/v1.6/query_language/spec/

并发写有可预见的风险。 其实我不大理解，influx1重启后，proxy1和2会分别把自身的数据写入到influx1中。这个有问题么？

重复写入并无必要，而且你还要面对local.dat的跨节点竞争写问题。

proxy高可用方案的正解是heartbeat或keepalive。上层再加nginx，如果只有一个，nginx本身不HA。如果有两个，等于没用。 加nginx的话，需要加到目标设备上。如果目标设备离线，那原始监控数据也不用提HA的事了。

那你也可以用k8s方式直接保证proxy的高可用。

这些个问题我没测试过，只凭我对系统的了解猜测一下： 1. 写出是缓存在应用内，而不是系统缓存。所以如果发生服务重启，数据会毫无疑问的丢失。如果将刷写间隔变短，会出现频繁写出，增加IO压力。如果MaxRowLimit设定为1，iops基本等同于数据条数。qps大于1000的时候很可能会把进程写死。 2. 从实践上说，同一个数据就不应当存在覆盖的问题。influx proxy不能严格的保证次序，无论是online写入还是crush recover。因为influx至少需要两个node，而两个node转发速度是不对等的。假设value=1被写入proxy1，value=2被写入proxy2。两者到达backend的先后次序无法保障。即便在同一个proxy，也有非常小的概率出现翻转。只有在写入channel之后，顺序才能被严格的限定。

机房地域。proxy策略是，多个机房同时写入，优先查询本机房。