Shell.Xu
Shell.Xu
请先试试http api的结果对不对。或者用influxdb提供的cli查。
这是个influxdb的问题把...
measurements里配多个backends。
实话说，我也不确定。 我们默认使用的redis就是存放一下配置，然后proxy从里面读取就行了。由于非常简单，所以在proxy旁边各建一个同步一下就行。也不需要读写业务数据，所以没有压力。这种情况下就根本没考虑过redis密码的问题。 如果redis一定要加密码的话，需要调整这部分。 https://github.com/shell909090/influx-proxy/blob/master/service/main.go#L40 https://github.com/go-redis/redis/blob/v5.2.9/options.go 你可以看到，Option部分是照搬了redis。所以理论上你在Addr的下面接着写Password那块应该就行。 但是我没测试过。有结果的话请反馈。
我在饿厂的时候基于这套提供的服务，基本没出过事。性能我记不清了，调整合适的话，一个后端几百万rec每秒还是没啥问题的。保险点1Mrec/s好了，100Mrec一个backend也就100s就处理完了。 当然，这是天时地利人和的理想情况。你的CPU要顶得住拆装数据压力，内存足够不会频繁交换。measurement在后端分布均匀，不会单个机器忙死。tags不会出现组合爆炸。如果都做到了，压力最后会堆积到代码的核心交换部分。核心的排队是用ch完成的，一个backend一个ch。
influx proxy的主要目标是对数据做分片，也就是说，backend的数据库performance顶不住要用多台。既然backend都顶不住了，也就不存在和别人混用，混合部署的问题了。你可以认为backend是专属的，或者说是独占的。那我就不明白为什么大家都想要auth需求呢，static ip filter就好了...
这个从设计上就做不了。除非把每个请求参数加到写入数据的结构里去，然后再按照写入参数分类再写入。否则打散合并写入的过程一定会丢掉write的其他参数的。
那我等您的PR。
@kkdev163 多谢多谢哈。一阵没上来，连PR都有了。 方便私下沟通一下么？