CN109726211A - 一种分布式时序数据库 - Google Patents

Abstract

本发明提供了一种分布式时序数据库，运行于本地服务器中，包括配置外部操作接口及集群通讯接口的RAFT集群，配置API的RRD存储引擎，以及至少由一个低速存储介质所组成的第一存储装置；外部操作接口受控于客户端，RAFT集群通过集群通讯接口接收外部服务器所发送的原始数据，并基于RAFT集群中的节点所形成的角色形成具一致性的时序数据，RRD存储引擎至少通过API接收RAFT集群所形成的时序数据并存储至第一存储装置。通过本发明所揭示的一种分布式时序数据库，可在运行该分布式时序数据库的硬件故障时依然保证时序数据的一致性与可靠性，保证了对云计算和大数据场景中不断增长且容量巨大的时序数据的管理与存储的业务需求。

Description

一种分布式时序数据库

技术领域

本发明涉及数据库技术领域，尤其涉及一种分布式时序数据库。

背景技术

时序数据库(又称“时间序列数据库”)是一种集时序数据高效读写，压缩存储，实时计算能力为一体的数据库服务，可广泛应用于物联网和互联网领域，实现对设备及业务服务的实时监控，实时预测告警。时间序列数据的特点包括：1.产生频率快；2.严重依赖采集时间：每一天数据均要求对应唯一的时间；3.测点多且信息量大：常规的实时监测系统均有上万个监测点，每天产生几十GB甚至更大的数据量。随着时间序列数据的不断膨胀，必然面临有限的存储空间不能满足存储需求且检索速度降低的技术问题。

为了解决上述技术问题，针对时间序列数据(即“时序数据”)的上述特性，最新的现有技术提出了分精度存储时序数据的思想，即，对不同时间段的数据做不用精度的压缩，且不同精度的数据保留不同的时间。RRD(Round Robin Database)是一种循环使用存储空间的数据库，适用于存储和时间序列相关的时序数据，其作为一种单机文件型数据库，在时序数据库领域有广泛的应用。

虽然RRD简单易用，但在云计算和大数据环境下，由于RRD中的所有时序数据都是存放在本地磁盘中的，而单个本地磁盘的能够存储及处理的时序数据的规模是存在上限的，随着时序数据的不断膨胀，必然导致本地磁盘的存储空间不能满足使用需求的缺陷。同时，RRD显然不能很好的满足分布式环境下的可用性和数据一致性的需求。因为，在云计算和大数据环境下，性能数据必然超出单机处理能力，从而导致现有的RRD无法满足云计算和大数据场景中的时序数据的管理与存储；同时，单机系统的故障(例如：宕机、网络拥塞等异常状况)也无法保证单机系统中基于RRD的时序数据库中数据的可靠性与一致性，以及通过多个单机系统所组成的计算机集群中数据的可靠性与一致性。

有鉴于此，有必要对现有技术中的时序数据库予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种分布式时序数据库，以解决在云计算和大数据环境下RRD无法满足分布式环境下的可用性和数据一致性的需求，解决因硬件故障所导致的时序数据所存在的一致性与可靠性不理想的技术瑕疵。

为实现上述目的，本发明提供了一种分布式时序数据库，运行于本地服务器中，包括：

配置外部操作接口及集群通讯接口的RAFT集群，配置API的RRD存储引擎，以及至少由一个低速存储介质所组成的第一存储装置；

所述外部操作接口受控于客户端，所述RAFT集群通过集群通讯接口接收外部服务器所发送的原始数据，并基于RAFT集群中的节点所形成的角色形成具一致性的时序数据，RRD存储引擎至少通过API接收RAFT集群所形成的时序数据并存储至第一存储装置。

作为本发明的进一步改进，所述RAFT集群由三个以上并运行状态机的节点组成；

其中，每个节点由状态机、一致性单元及日志组成；

所述一致性单元接受客户端发起的请求保存至日志中，所述状态机通过外部操作接口受控于客户端，状态机处理相同的命令序列，并根据状态机的状态属性确保RAFT集群中的所有状态机具相同的状态与输出序列。

作为本发明的进一步改进，所述RAFT集群由三个以上的节点组成，不同节点中的状态机被定义为领导者、追随者或者候选者；其中，

被定义为领导者的状态机负责接收客户端发送的请求，并与被定义为追随者的状态机保持心跳联系；

被定义为追随者的状态机响应被定义为领导者的状态机及被定义为候选者的日志同步请求，并将日志同步请求转发至被定义为领导者的状态机；

被定义为候选者的状态机将RAFT集群在初始状态中的节点是否由被定义为追随者的状态机转变为被定义为候选者的状态机进行选举，并以选举结果领先的状态机定义为被定义为领导者的状态机；

当所述RAFT集群选举出被定义为领导者的状态机后接受客户端的请求。

作为本发明的进一步改进，所述被定义为领导者的状态机所在的节点接收到客户端发起的请求后，将请求添加入领导者的状态机所在的节点中的日志中，然后通过集群通信接口将添加基于客户端请求所形成的日志并行地向通过所述集群通信接口所连接的外部服务器进行复制操作，并由被定义为领导者的状态机向客户端作出响应。

作为本发明的进一步改进，还包括部署于RRD存储引擎中并充当高速缓存的第二存储装置，以及部署于RRD存储引擎中的底层存储接口；

底层存储接口将第二存储装置中临时写入的缓存数据以定期或者定量方式与第一存储装置执行读取或者写入操作。

作为本发明的进一步改进，所述第一存储装置由两个以上的低速存储介质所组成，并形成分布式存储架构。

作为本发明的进一步改进，还包括：业务配置接口；

所述业务配置接口受控于客户端，以接收客户端发起的时序数据库操作指令并存储至第二存储装置，并通过API调取第二存储装置中保存的与所述查时序数据库操作指令所对应的时序数据，并发送至RAFT集群，通过集群通讯接口执行向外部服务器同步更新时序数据的操作；

所述时序数据库操作指令包括插入读取操作指令、写入操作指令或者查询指令。

作为本发明的进一步改进，所述第二存储装置由至少一个高速存储介质组成，所述高速存储介质选自NVDIMM、内存或者SSD。

作为本发明的进一步改进，所述低速存储介质选自机械磁盘或者RAID。

作为本发明的进一步改进，所述RAFT集群挂载至本地服务器的内存。

与现有技术相比，本发明的有益效果是：

通过本发明所揭示的一种分布式时序数据库，可在运行该分布式时序数据库的硬件故障时依然保证时序数据的一致性与可靠性，保证了对云计算和大数据场景中不断增长且容量巨大的时序数据的管理与存储的业务需求。

附图说明

图1为本发明一种分布式时序数据库在实施例一中的结构图；

图2为本发明一种分布式时序数据库在实施例二中的结构图；

图3为本发明一种分布式时序数据库在实施例三中的结构图；

图4为RAFT集群的结构图；

图5为运行有本发明所示出的分布式时序数据库服务器所组成的计算机集群的示意图；

图6为RAFT集群中节点的结构图；

图7为从图4所示出的RAFT集群中的三个节点选举产生被定义为领导者的状态机的过程示意图；

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特定的意义。因此，“模块”、“部件”或“单元”可以混合地使用。使用用于区分元件的诸如“第一”、“第二”等前缀仅为了有利于本发明的说明，其本身没有特定的意义。

术语“领导者”与英文单词“Leader”具等同技术含义。

术语“追随者”与英文单词“Follower”具等同技术含义。

术语“候选者”与英文单词“Candidate”具等同技术含义。

术语“服务器”与英文单词“SERVER”具等同技术含义。

术语“客户端”与英文单词“Client”具等同含义，且该客户端可以是物理装置也可以是虚拟装置，只要能够向外部操作接口11发起数据库操作的指令即可，该指令可以是包含所有的计算机可执行的命令，包括但不限于读操作、写操作、修改操作、查询操作、备份操作、迁移操作等。

术语“以上”包含本数，例如“三个以上”可以理解为三个或者四个或者更多数量。

发明概述：

本申请所揭示的一种分布式时序数据库可运行于计算机集群100(参图5所示)中的任何一个或者多个服务器中。

RAFT集群20通过选举一个领导者(Leader211L)，然后给予领导者211L全部的管理复制日志的责任来实现时序数据的一致性。领导者211L从客户端10接收日志条目，把日志条目复制到其他服务器60上，并且当保证安全性的时候通知其他服务器60应用日志条目到其他服务器60所属的状态机211中(即图5中的SERVER601～SERVER604中所包含的RAFT集群20中所分别部署的状态机211)。领导者211L大大简化了对复制日志的管理。例如，领导者211L可以决定新的日志条目需要放在日志中的什么位置而不需要和其他服务器60的商议，并且数据都从领导者221L流向其他服务器60。领导者211L可以宕机或者发生网络拥塞，可以和其他服务器60失去连接，这时一个新的领导者会被选举出来，并具体为从Candidate211C中以票数占优的选举原则被选举出来。

具体的，外部操作接口11具体为HTTP(S)接口，并采用UTP协议或者RPC协议。集群通讯接口12采用TCP协议。具体的，HTTP(S)接口提供给HTTP(S)API接口给Client10，实现对分布式时序数据库的操作；集群通讯接口12则是作为RAFT集群20的一部分，供多个外部服务器60之间实现集群数据交换(参图5中SERVER之间所形成的虚线连接线)。RRD存储引擎411作为是RRD数据库的一部分，向整个分布式时序数据库提供时序数据的数据库操作与时序数据的存储与调用。

RRD存储引擎41使用固定大小的空间来存储数据，并有一个指针指向最新的数据的位置。可以把用于存储数据的数据库的空间看成一个圆，上面有很多刻度。这些刻度所在的位置就代表用于存储数据的地方。所谓指针，可以认为是从圆心指向这些刻度的一条直线。指针会随着数据的读写自动移动。要注意的是，这个圆没有起点和终点，所以指针可以一直移动，而不用担心到达终点后就无法前进的问题。在一段时间后，当所有的空间都存满了数据，就又从头开始存放。这样整个存储空间的大小就是一个固定的数值。

有基于此，在本发明中，通过RRD存储引擎41与第一存储装置42实现了分布式时序数据库所需要的时序数据分布式写入与读取的性能需求；同时，通过RAFT集群中的三个或者以上被定义为不同角色的节点的一致性算法，实现了图5所示出的计算机集群100中时序数据的一致性。保留了RRD适用于存储和时间序列相关的时序数据的性能优势，从而使得该分布式时序数据库具备良好的扩展性能与容灾自愈能力。

实施例一：

请参图1、图4至图7所示出的本发明一种分布式时序数据库的第一种具体实施方式。

参图1所示，该分布式时序数据库，运行于本地服务器SERVER_1中，包括：

配置外部操作接口11及集群通讯接口12的RAFT集群20，配置API411的RRD存储引擎41，以及至少由一个低速存储介质所组成的第一存储装置42。外部操作接口11受控于客户端10，RAFT集群20通过集群通讯接口12接收外部服务器所发送的原始数据，并基于RAFT集群20中的节点所形成的角色形成具一致性的时序数据，RRD存储引擎41通过API411接收RAFT集群20所形成的时序数据并存储至第一存储装置42。

RAFT集群20由三个以上并运行状态机的节点组成。在本实施例中，范例性地在RAFT集群20中示出了节点21、节点22与节点23；当然，该RAFT集群20中为了进一步提高容错能力及节点故障容忍度，还可以在RAFT集群20中设置四个或者数量更多的节点。在后续阐述中，申请人以节点21为范例，详细展开阐述。

节点21由状态机211、一致性单元212及日志231组成。日志213由标记有序编号(log index)的日志条目与用于被状态机执行的命令组成。每个日志条目包含了该日志条目被创建时的任期(term)。在本申请中，术语“任期”或者“term”表征某个日志所关联的状态机211被定义为领导者(Leader211L)的生命周期，并进一步为：表征状态机211从开始被选举为领导者(Leader211L)至领导者(Leader211L)失效之间的时间轴参数。

一致性单元212接受客户端10发起的请求保存至日志中，状态机211通过外部操作接口11受控于客户端10，状态机211处理相同的命令序列，并根据状态机211的状态属性确保RAFT集群20中的所有状态机211具相同的状态与输出序列。

参图7所示，具体的，在本实施例中，该RAFT集群20由三个以上的节点组成，不同节点中的状态机被定义为领导者、追随者或者候选者。例如将节点21中的状态机211定义为领导者，将节点22中的状态机(未示出)定义为追随者，将节点23中的状态机(未示出)定义为候选者。

被定义为领导者的状态机负责接收客户端10发送的请求，并与被定义为追随者的状态机保持心跳联系；被定义为追随者的状态机响应被定义为领导者的状态机及被定义为候选者的日志同步请求，并将日志同步请求转发至被定义为领导者的状态机；被定义为候选者的状态机将RAFT集群20在初始状态中的节点是否由被定义为追随者的状态机转变为被定义为候选者的状态机进行选举，并以选举结果领先的状态机定义为被定义为领导者的状态机。当所述RAFT集群20选举出被定义为领导者的状态机后接受客户端10的请求。

被定义为领导者的状态机所在的节点接收到客户端10发起的请求后，将请求添加入领导者的状态机所在的节点211中的日志中，然后通过集群通信接口12将添加基于客户端10请求所形成的日志并行地向通过所述集群通信接口12所连接的外部服务器60进行复制操作，并由被定义为领导者的状态机向客户端10作出响应。通过上述的复制操作，可使得图5中计算机集群100中多个外部服务器中的日志执行同步更新操作，使得计算机集群100中的时序数据具有强一致性。

参图7所示，下文对追随者(Follower 211F)、候选者(Candidate 221C)及领导者(Leader 211L)选举过程进行详细阐述。需要说明的是，在一个服务器，例如本地服务器SERVER_1中所形成的节点21、节点22与节点23中所形成的状态机的角色是可以动态变化的。同时，如图5所示，本地服务器与外部服务器仅仅是相对概念。将SERVER_1定义为本地服务器时，则SERVER601、SERVER602、SERVER603、SERVER604就是外部服务器60，反之将SERVER601定义为本地服务器时，则SERVER_1、SERVER602、SERVER603、SERVER604就是外部服务器60。

开始220：刚启动时节点21、节点2及节点23均为Follower状态，响应Leader211L的日志同步请求，响应Candidate211C的请求，把请求到Follower211F的事务转发给Leader211L。

Follower211F通过开始选举221的操作、开始选举222的操作及开始选举223的操作，分别将三个节点中的一个节点，例如节点21通过上述三个选举操作将候选者被重新定义为领导者，并同时选举出候选者(即Candidate211C)与追随者(Follower211F)。

Leader211L：负责日志的同步管理，处理来自客户端10的请求，与Follower211F保持这心跳(Heart Beat)的联系。Candidate211C：负责选举投票，RAFT集群20刚启动时由一个节点从Follower211F转为Candidate211C发起选举，选举出Leader211L后从Candidate211C转为Leader211L状态。

节点21、节点22与节点23启动以后，首先都是被定义为Follower状态。在Follower状态下，会有一个选举超时时间的计时器(这个时间是在配置的超时时间基础上加一个随机的时间得来的)。如果在这个时间内没有收到Leader发送的心跳包，则节点状态会变成Candidate状态，也就是变成了候选者，候选者会循环广播选举请求；如果超过半数的节点同意选举请求，则节点转化为Leader状态。如果在选举过程中，发现已经有了Leader或者有更高的任期值的选举信息，则自动变成Follower状态。处于Leader状态的节点如果发现有更高任期值的Leader存在，则也是自动变成Follower状态。

RAFT集群20把时间属性划分为任期(Term)。任期是一个递增的整数。任期是从开始选举为Leader到Leader失效的这段时间。任期的时间是不一定的，也就是说只要服务器或者本地服务器SERVER_1中的某个节点中的Leader工作状态良好，它可能成为一个独裁者，可以一直被定义为Leader。当然，如果本地服务器SERVER-1中发现更长人气的节点225，则将Leader211L被重新定义为Follower211F；如果从Candidate211C发现当前领导者或者新任期224时(即从Candidate211C被重新定义为Leader或者存在多个Leader时存在新任期的Leader)，将Candidate211C重新定义为Follower211F。

每个term一开始就进行选主，并历经下述三个阶段：

阶段(1)：Follower将自己维护的current_term_id加1；

阶段(2)：然后将自己的状态转成Candidate；

阶段(3)：发送RequestVoteRPC消息(带上current_term_id)给其它所有server。

这个过程会有三种结果：

结果A：自己被选成了主。当收到了majority的投票后，状态切成Leader，并且定期给其它的所有server发心跳消息(不带log的Append Entries RPC)以告诉对方自己是current_term_id所标识的term的leader。每个term最多只有一个Leader，term id作为logical clock，在每个RPC消息中都会带上，用于检测过期的消息。当一个server收到的RPC消息中的rpc_term_id比本地的current_term_id更大时，就更新current_term_id为rpc_term_id，并且如果当前state(即当前状态机的状态)为Leader或者Candidate时，将自己的状态切成Follower。如果rpc_term_id比本地的current_term_id更小，则拒绝这个RPC消息。

结果B：别人成为了主。当Candidator在等待投票的过程中，收到了大于或者等于本地的current_term_id的声明对方是leader的Append Entries RPC时，则将自己的状态机切换为Follower，并且更新本地的current_term_id。

结果C：没有选出主。当投票被瓜分，没有任何一个Candidate收到了majority的vote时，没有Leader被选出。这种情况下，每个Candidate等待的投票的过程就超时了(TIMEOUT)，接着Candidate都会将本地的current_term_id再加1，发起Request Vote RPC进行新一轮的Leader选举。

Leader选出后，就开始由被定义为Leader的节点(例如节点21)接收客户端10的请求。Leader把请求作为日志条目(Log entries)加入到它的日志中，然后并行的向其他服务器发起Append Entries RPC复制日志条目。当这条日志被复制到大多数或者全部的外部服务器60上，Leader将这条日志应用到它的状态机211，并向客户10返回执行结果。

RAFT集群20中被定义为领导者(Leader)的节点所发起的日志同步操作的过程如下：某些Followers或者某个Follower可能没有成功复制Leader所分发的日志，Leader会无限地重试Append Entries RPC，直到所有的Followers最终存储了所有的日志条目。如果一个日志条目被复制到大多数或者全部的外部服务器上，就被认为可以提交(commit)了。

RAFT集群中的日志同步保证如下两点特性：特性(1)如果不同日志中的两个条目有着相同的索引和任期号，则它们所存储的命令是相同的；特性(2)如果不同日志中的两个条目有着相同的索引和任期号，则它们之前的所有条目都是完全一样的。特性(1)源于Leader在一个term内在给定的一个log index最多创建一条日志条目，同时该条目在日志中的位置也从来不会改变。特性(2)源于Append Entries的一个简单的一致性检查。当发送一个Append Entries RPC时，Leader会把新日志条目紧接着之前的条目的log index和term都包含在里面。如果Follower没有在它的日志中找到Log index和term都相同的日志，它就会拒绝新的日志条目。一般情况下，Leader和Followers的日志保持一致，因此AppendEntries一致性检查通常不会失败。然而，Leader崩溃可能会导致日志不一致：旧的Leader可能没有完全复制完日志中的所有条目。

同时，为了解决Leader与Follower上存储的日志不一致的问题，在本实施例中，采用如下解决方案。

Follower可能会丢失掉Leader上的一些日志条目，也有可能包含一些Leader没有的日志条目，也有可能两者都会发生。丢失的或者多出来的日志条目可能会持续多个任期。因此，Leader通过强制Followers复制它的日志条目来处理日志条目的不一致，Followers上的不一致的日志条目会被Leader的日志条目覆盖。Leader为了使Followers的日志条目与自己的日志条目(即Leader的日志条目)一致，Leader需要找到Follower或者Followers与其的日志条目(即Leader的日志条目)一致的地方，然后覆盖Followers在该位置之后的日志条目。Leader会从后往前试，每次Append Entries失败后尝试前一个日志条目，直到成功找到每个Follower的日志条目的一致位点，然后向后逐条覆盖Followers在该位置之后的日志条目。Leader会从后往前试，每次Append Entries失败后尝试前一个日志条目，直到成功找到每个Follower的日志一致位点，然后向后逐条覆盖Followers在该位置之后的日志条目。

同时，为了确保计算机集群100中的多个服务器或者一个服务器中的多个节点之间日志同步更新的安全性，在本实施例中通过以下两个机制来实现的。

(一)最新保证机制：

确保拥有最新的已提交的Log entry的Follower才有资格成为Leader。

最新保证机制是在Request Vote RPC中执行的，Candidate在发送Request VoteRPC时，要带上自己的最后一条日志的term和Log index，其他节点收到消息时，如果发现自己的日志比请求中携带的更新，则拒绝投票。

(二)日志比较机制：

如果本地的最后一条Log entry的term更大，则term更大的更新，如果term一样大，则Log index更大的更新。Leader只能推进commit index来提交当前term的已经复制到大多数服务器上的日志，旧term日志的提交要等到提交当前term的日志来间接提交。Logindex小于commit index的日志被间接提交。

在本实施例中，基于RRD存储引擎实现一种了分布式时序数据库的需求；保留了RRD的优点又能具备分布式系统的可用性和数据一致性的需求；基于RRD存储引擎的分布式时序数据库具备较好的可扩展性和容灾自愈性。

实施例二：

请参图2、图4至图7所示出的本发明一种分布式时序数据库的第一种具体实施方式。本实施例与实施例一相比，其主要区别在于，本实施例所揭示的一种分布式时序数据库还包括：业务配置接口50。

第一存储装置42由两个以上的低速存储介质所组成，例如图2中范例性的示出了低速存储介质421及低速存储介质42i(其中，参数i取大于或者等于2的正整数)，多个低速存储介质形成分布式存储架构。具体的，低速存储介质选自机械磁盘或者RAID，并在本实施例中进一步选用机械磁盘。在本实施例中，通过多个低速存储介质形成分布式存储架构，以形成了相互嵌套的二层分布式存储架构，以进一步提高了该分布式时序数据库的数据自愈能力，并提高了本地服务器SERVER_1中所保存的时序数据的一致性与数据自愈能力。同时，在本实施例中，该RAFT集群20挂载至本地服务器SERVER_1的内存。通过此种技术手段提高了RRD存储引擎41向第一存储装置42执行数据写入与读取的效率，同时提高了对SERVER_1中内存数据的快速响应。

本实施例与实施例一中相同部分的技术方案，请参实施例一所述，在此不再赘述。

实施例三：

请参图3、图4至图7所示出的本发明一种分布式时序数据库的第一种具体实施方式。本实施例与实施例一和/或实施例二相比，其主要区别在于，在本实施例所示出的分布式时序数据库还包括：部署于RRD存储引擎41中并充当高速缓存的第二存储装置412，以及部署于RRD存储引擎41中的底层存储接口413。

在本实施例中，该业务配置接口50受控于客户端10，以接收客户端10发起的时序数据库操作指令并存储至第二存储装置412，并通过API411调取第二存储装置412中保存的与所述查时序数据库操作指令所对应的时序数据，并发送至RAFT集群20，通过集群通讯接口12执行向外部服务器同步更新时序数据的操作。时序数据库操作指令包括插入读取操作指令、写入操作指令或者查询指令。底层存储接口413将第二存储装置412中临时写入的缓存数据以定期或者定量方式与第一存储装置42执行读取或者写入操作。第二存储装置412由至少一个高速存储介质组成，高速存储介质选自NVDIMM、内存或者SSD中的任意一种。

本实施例与实施例一和/或实施例二中相同部分的技术方案，请参实施例一和/或实施例二所述，在此不再赘述。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.一种分布式时序数据库，运行于本地服务器中，其特征在于，包括：

配置外部操作接口(11)及集群通讯接口(12)的RAFT集群(20)，配置API(411)的RRD存储引擎(41)，以及至少由一个低速存储介质所组成的第一存储装置(42)；

所述外部操作接口(11)受控于客户端(10)，所述RAFT集群(20)通过集群通讯接口(12)接收外部服务器所发送的原始数据，并基于RAFT集群(20)中的节点所形成的角色形成具一致性的时序数据，RRD存储引擎(41)至少通过API(411)接收RAFT集群(20)所形成的时序数据并存储至第一存储装置(42)。

2.根据权利要求1所述的分布式时序数据库，其特征在于，所述RAFT集群(20)由三个以上并运行状态机的节点组成；

其中，每个节点由状态机、一致性单元及日志组成；

所述一致性单元接受客户端(10)发起的请求保存至日志中，所述状态机通过外部操作接口(11)受控于客户端(10)，状态机处理相同的命令序列，并根据状态机的状态属性确保RAFT集群(20)中的所有状态机具相同的状态与输出序列。

3.根据权利要求2所述的分布式时序数据库，其特征在于，所述RAFT集群(20)由三个以上的节点组成，不同节点中的状态机被定义为领导者、追随者或者候选者；其中，

被定义为领导者的状态机负责接收客户端(10)发送的请求，并与被定义为追随者的状态机保持心跳联系；

被定义为追随者的状态机响应被定义为领导者的状态机及被定义为候选者的日志同步请求，并将日志同步请求转发至被定义为领导者的状态机；

被定义为候选者的状态机将RAFT集群(20)在初始状态中的节点是否由被定义为追随者的状态机转变为被定义为候选者的状态机进行选举，并以选举结果领先的状态机定义为被定义为领导者的状态机；

当所述RAFT集群(20)选举出被定义为领导者的状态机后接受客户端(10)的请求。

4.根据权利要求2所述的分布式时序数据库，其特征在于，所述被定义为领导者的状态机所在的节点接收到客户端(10)发起的请求后，将请求添加入领导者的状态机所在的节点中的日志中，然后通过集群通信接口(12)将添加基于客户端(10)请求所形成的日志并行地向通过所述集群通信接口(12)所连接的外部服务器进行复制操作，并由被定义为领导者的状态机向客户端(10)作出响应。

5.根据权利要求3或者4所述的分布式时序数据库，其特征在于，还包括部署于RRD存储引擎(41)中并充当高速缓存的第二存储装置(412)，以及部署于RRD存储引擎(41)中的底层存储接口(413)；

底层存储接口(413)将第二存储装置(412)中临时写入的缓存数据以定期或者定量方式与第一存储装置(42)执行读取或者写入操作。

6.根据权利要求3或者4所述的分布式时序数据库，其特征在于，所述第一存储装置(42)由两个以上的低速存储介质所组成，并形成分布式存储架构。

7.根据权利要求5所述的分布式时序数据库，其特征在于，还包括：业务配置接口(50)；

所述业务配置接口(50)受控于客户端(10)，以接收客户端(10)发起的时序数据库操作指令并存储至第二存储装置(412)，并通过API(411)调取第二存储装置(412)中保存的与所述查时序数据库操作指令所对应的时序数据，并发送至RAFT集群(20)，通过集群通讯接口(12)执行向外部服务器同步更新时序数据的操作；其中，

所述时序数据库操作指令包括插入读取操作指令、写入操作指令或者查询指令。

8.根据权利要求7所述的分布式时序数据库，其特征在于，所述第二存储装置(412)由至少一个高速存储介质组成，所述高速存储介质选自NVDIMM、内存或者SSD。

9.根据权利要求7所述的分布式时序数据库，其特征在于，所述低速存储介质选自机械磁盘或者RAID。

10.根据权利要求1所述的分布式时序数据库，其特征在于，所述RAFT集群(20)挂载至本地服务器的内存。