目录

一、问题点

二、解决方案

方案一

方案二

一、问题点

influxdb V2作为一个比较新的产品，其实是存在较多的问题的，今天来讲一下时区问题，以及对应的解决方案。

influxdb从v1到v2的升级过程中抛弃了influxQL的类似sql语法，完全使用自制的查询方式，称为"flux"。

v1版本的influxdb flux是跟着版本走的，最新的版本使用最新的flux语法，而v2版本的influxdb所支持的flux语句并不是最新的，功能并不是完整的。

截至2021年9月27日发布的最新influxdb版本为：V2.0.9

它所支持的flux版本为v0.130.0，如下图所示：

而时区包支持的最低flux版本为：Flux 0.134.0

所以，截至2021年9月的influxdb最新2.0版本，都是无法支持时区调整的，而influxdb使用的时间格式是RFC3339，这直接导致了跨月数据查询的不准确，我们使用GMT+8的时区，10月1日凌晨打入的数据落到influxdb上存储的时间为9月30日16点。

如果使用数据聚合task，将数据聚合到一个新的桶上，将会直接丢失10月1日的数据。

二、解决方案

目前有两种可用的解决方案。

方案一

第一种是升级influxdb版本包，根据官网的发布信息，可以看到2021-11-08发布的新版本：v2.1.1 已经支持到 Flux v0.139.0

但为了解决时区问题，在生产上将influxdb完成升级也不现实，其实每次出来的新版本都会存在未知的坑，甚至有些版本官方是后续在官网上说明有哪些bug，该用什么方式去填补它之类的，还是让它被使用一段时间，等论坛上或者官网未指出某些bug，具备一定的使用信任度才可以去尝试使用它。

方案二

第二种解决方案，也是我们自己使用的解决方案，原理上并没有什么问题，但是它是一种不太优雅的解决方案。

通过时间偏移，直接把flux时间range推移八个小时，使得查询的数据结果正确。

被flux语法所限制，只能使用它所支持的function来完成，这里提供一个代码示例(查询10月份的数据信息)：

import "experimental"from(bucket: "aliyun/day")
|> range(start: experimental.addDuration( d: -8h, to: date.truncate(t: -1mo, unit: 1mo)),
stop: 2021-10-31)
|> filter(fn: (r) => r["_measurement"] == "aliyun-instance")
|> filter(fn: (r) => r["_field"] == "count")

不得不说，influxdbv2版本相比于v1，有了控制台，使用起来方便很多，而且作为一个优秀的时序数据库，它的功能也基本能满足所有时序数据库该解决的问题，但由于这个东西太新了，隐藏着很多未知的坑等着程序员们去踩，越复杂的东西坑越多，如果很垂涎它的功能，那就只能硬着头皮上，把所有的问题一一摊平解决，最重要的是需要有最完备的实现方案，能允许任何故障的存在，也不会对自身造成影响，那么便可以大方的使用它。