InfluxDB应该是目前最专业的时序数据库，但是InfluxDB Cluster的代码在0.11版本之后就宣布闭源，作为商业软件。InfluxDB越来越受欢迎，目前很多公司都是基于其搭建自己的时序数据集群。最近阿里云推出InfluxDB®，是一个基于开源版InfluxDB的商业化时序数据库，还在研发分布式高可用版本 ：5分钟了解阿里时序时空数据库。
这里我们基于InfluxDB Cluster v0.11的实现，并结合目前正火的开源HTAP数据库TiDB，通过对比理解InfluxDB Cluster的解决方案。因为TiDB的分布式方案社区很成熟，很容易获得专业资料，但是InfluxDB Cluster在其闭源后社区相关资料几乎没有更新。
TiKV分布式存储
TiKV的数据存储原理细节建议参考PingCAP的官方博文。这里做一个总结：
- TiKV的sharding策略是range sharding，把不同区间的key分到不同的region，当region的数据量超过阈值时，会发生分裂成为2个region。
- region作为数据存储的单位，会在集群中做3副本，3个副本通过raft保证数据复制的一致性。底层数据存储使用的是RocksDB，单个TiKV node里面会起2个RocksDB实例，一个用于存储数据，它会包含多个region，通过在key中加入region ID作为前缀来区分，另一个存储raft log。
- Placement driver在raft的上层，存储region的路由表，作为索引加速数据定位。
- 再上一层基于MVCC实现单个TiKV node内部的事务。
- 然后就是基于2PC算法实现TiKV 集群上的分布式事务。
InfluxDB Cluster
在0.11版本中，InfluxDB Cluster架构已经基本完善，其将整体分为2个集群，一个是真正存储数据的data cluster，另一个是存储数据集群元信息的meta server。以下涉及的基础概念和逻辑，可参考本人前面的博文InfluxDB的存储引擎演化过程，用TiKV存储时序数据与InfluxDB对比。InfluxDB Cluster实现原理参考：
- InfluxDB Doc
- InfluxDB Clustering Design – neither strictly CP or AP
- Simplifying InfluxDB: Shards and Retention Policies
下面是基于我的理解，画的InfluxDB Cluster架构图：
上图中上层是InfluxDB中数据逻辑层次结构，下层是真正的物理集群，存储数据。
Retention policy就是前面博文多次提到的InfluxDB的数据过期管理策略，它与database关联。为database创建retention policy：
CREATE RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT]DURATION: 数据保存期限。比如30d，24h。REPLICATION: 见下文。SHARD DURATION: 见下文。同一retention policy的数据会根据time range进行sharding，把数据分到不同的shard group，每个shard group所包含的时间区间由第1条中的
SHARD DURATION指定，默认是每24h就会创建一个shard group。在同一个shard group中的数据，对应相同的过期周期，同时在同一个时间范围内，所以它们将接近同时过期，这非常有方便于数据清除。前面的博文提到，根据time range进行sharding会把最新的的数据写到同一个shard group，造成写入热点。InfluxDB通过hash sharding来解决这个问题，每个shard group会包含多个shard，数据通过对
SeriesKey进行hash取模被分发到不同的shard。在开源的单机版本中，这一层会被设定为1个hash槽，所以不会起作用。Shard是InfluxDB中数据的基本组织形式，每个shard是一个完整的TSM存储引擎，包含独立的WAL和数据存储文件。每一个shard会被放在多个数据节点上，以保证数据的安全和可用。这里的副本数可以通过1中的
REPLICATION指定。默认在单机环境中为1，在集群环境中为3。同一个shard在不同节点中的多个副本基于Gossip协议实现数据一致性，这是一个去中心化的一致性协议。
上图是meta cluster架构图。InfluxDB的元数据节点存储了所有的数据库信息，包括数据集群中的逻辑层次，所有retention policy，shard group时间区间分配以及shard的hash设置。也就是说元数据集群的作用就是根据数据信息定位到该数据会存储在哪个shard。然后再到shard中读/写数据。
与TiKV对比
InfluxDB Cluster整体框架与TiKV的存储相比，meta cluster类似于TiKV的placement driver，用作集群元信息的存储。meta cluster存储的信息更全面，其实是数据库的管理信息都在里面。
上层的分布式思想都是一样的，都是使用range sharding的思想。TiKV直接通过数据条目的key的区间来做sharding，对于数据更新很友好。而InfluxDB则是基于point的时间区间段进行sharding，这便于过期数据清除。InfluxDB还通过SeriesKey进行第二次sharding，解决数据写入热点问题。
InfluxDB中的shard与TiKV中的region是等价的，都是数据存储的单元。存在以下不同点：
- 每个TiKV节点只起一个RocketsDB实例用作数据存储，其包含了节点中所有region。而InfluxDB中，每个shard是一个独立的TSM，等价于一个独立的RocketsDB实例。
- TiKV中每个region的多个副本之间是使用raft协议，达到强一致性。InfluxBD的shard副本之间则是使用gossip协议达到最终一致。
- TiKV的region会在条目太多的时候进行分裂，这跟InfluxDB的hash sharding到不同的shard类似，目的都是为了防止出现热点。
所以，从数据存储角度来说，对于分布式CAP理论，TiKV更偏向于CP系统，因为它完全兼容传统RDBMS，支持事务是必备的。而InfluxDB Cluster主要目标是提供高可用，是一个偏向于AP系统。这是因为面向前面的博文中所说的时序数据的特征，让高频率数据能够及时写入，而不支持事务。但是，meta cluster则是一个CP系统，保证数据库信息的完全一致，这也是为下层数据存储服务的。
