时序数据库系列9-服务框架_iotdb tdengine 对比

服务框架

在《时序数据库系列1-综述》中说过时序数据库存在高吞吐写的特点，因此在时序数据库中客户端和服务端远程传输数据的性能非常重要，数据传输的性能直接影响了数据库整体的读写性能。

起始除了内存数据库之外，其他类型的数据数据库都面临着客户端到服务端的远程调用，同样的时序数据库也面临同样的需求。那么在C/S间的远程调用方式有哪些呢？最常见的就是RPC和HTTP。

1.RPC：即Remote Procedure Call，远程过程调用，通常基于TCP/IP协议。

2.HTTP：即超文本协议，基于HTTP协议，在TCP协议之上。

上述表述并不严谨，严格地说HTTP只是一个通信协议，工作在OSI第七层。而RPC是一个完整的远程调用方案，它包含了:接口规范、传输协议、数据序列化反序列化规范。在本文中我们用HTTP指代基于HTTP的远程调用方案(如:HTTP+RESTful+JSON)

适用场景

RPC基于TCP/IP协议，主要用于系统内部服务调用，传输效率高，性能消耗小。

HTTP基于HTTP协议，其报文中包含的臃肿的头部信息，一般用在网关之前来提供系统与系统之间的通信，性能消耗大。

性能测试

作者对HTTP和RPC发送数据的性能进行了简单测试，测试条件和结果如下：

网络环境：内网万兆网，循环20000次

数据环境：每条记录有120个 Java Integer字段，每5000条记录一个批次

并发：20并发

测试结果：

​ http：平均值 109.427ms

​ Thrift：平均值 7.59ms

从上述结果中可见，HTTP方案和RPC方案（Thrift）的数据传输性能存在一个数量级的差距。

RPC介绍

常见的RPC框架

目前常见的RPC框架主要有Dubbo、 Thrift、 gRPC等等，这里只介绍这三者。

• gRPC：是 Google 公布的开源软件，基于 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。

• Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。

• Dubbo：是阿里集团开源的一个极为出名的 RPC 框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是极其鲜明的特色

RPC核心功能

一个 RPC 的核心功能主要有 5 个部分组成

1）client code：客户端代码调用的实现，负责发起RPC调用，为调用方提供提供API;

2）序列号与反序列化：一般RPC网络传输的内容有文本和二进制两大类。文本：xml和json。二进制：java原生的序列化与反序列化，以及Hession、protobuf、Thrift、Avro、Kryo、MessagePack；

3）stub Proxy：存根，可以看做一种代理对象，屏蔽了RPC调用的复杂网络处理，使得RPC调用透明化。

4）Transport:作为RPC底层的通讯模块，一般使用Socket使得客户端与服务端之间传递请求与应答。

5）service code:服务端服务业务逻辑具体的实现。

RPC核心功能

RPC流程

1. 服务调用者（client）通过本地调用的方式调用服务。

2. 客户端存根（client stub）接收到请求后负责将方法、入参等信息序列化（组装）成能够进行网络 传输的消息体。

3. 客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端。

4. 服务端存根（server stub）收到消息后进行解码（反序列化操作）。

5. 服务端存根（server stub）根据解码结果调用本地的服务进行相关处理。

6. 本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）。

7. 服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方。

8. 客户端存根（client stub）接收到消息，并进行解码（反序列化）。

9. 服务调用方得到最终结果

RPC调用流程

RPC重要性

为什么在数据库中需要RPC？

传统HTTP的通信⽅式基于HTTP协议，在TCP协议之上，在网关之内⼤量的请求头之类信息是无效的，会造成性能浪费，而RPC则可基于TCP/IP协议完成，内容更精简，性能比HTTP优秀，此外RPC在服务治理、追踪和易⽤性方面也更有优势。

在《时序数据库》系列的前文中我们介绍了通过压缩、存储引擎、查询引擎等多种方式加速时序数据库的查询性能，如果在通信方式上性能低下那么服务端通过各种技术积累的性能优势将不复存在。因此我们在通信阶段要采用性能更好的RPC以保证数据库整体性能的优秀。

时序数据库常用服务框架

下面我们对InfluxDB、TDengine、IoTDB使用地服务框架进行分析说明。

InfluxDB

influxdb采用了多种协议来完成服务端和客户端的通信，包括了http和UDP，其中http协议采用的是okhttp3。这种设计的原因我们从InfluxDB官网介绍可以得知一二：

TCP

InfluxDB uses Transmission Control Protocol (TCP) port 8086 for client-server communication over the InfluxDB HTTP API.

UDP

User Datagram Protocol is a packet of information. When a request is made, a UDP packet is sent to the recipient. The sender doesn’t verify the packet is received. The sender continues to send the next packets. This means computers can communicate more quickly. This protocol is used when speed is desirable and error correction is not necessary.

通过http方式保证安全的数据传输，由于时序数据具有数据价值密度低的特点，又通过UDP满足高速写入的需求。

influxDBFactory连接实现详见此处

TDengine

TDengine自研了RPC框架，并且已经开源。其原理如下图所示：

TDengine RPC原理

主要结构由最外层的控制器（RpcConn）和中层的Rpc_server与最内层的SRpcChann组成。

1.首先客户端先通过控制器发送一个计算请求给服务端。

2.服务端收到后先发送一个收到的回应给客户端。

3.服务端经过解析后将计算请求解析后执行。

4.服务端将结果发回给客户端。

TDengine RPC实现详见此处

IoTDB

IoTDB使用了Thrift。前面介绍了Thrift最初由 facebook 开发，07 年四月开放源码，08 年 5 月进入 apache 孵化器，现在是 Apache 基金会的顶级项目。

Thrift结合了功能强大的软件堆栈和代码生成引 擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。

IotDB Thrift实现详见此处

值得一提的是在上述的三种时序数据库中，TDengine将客户端的SQL解析工作放在了客户端，但只做 SQL 语句词法、语法解析部分工作，将解析的SQL结果，通过 RPC 方式发送到 Server 端执行。这中方式利用了RPC低廉的传输成本降低了服务端的工作压力，同时使其在一些只关注服务端性能的测试中表现更优秀。

小结

在数据库服务端使用了各种优秀设计提高数据库的性能之后，为了保持整体优秀的性能，在调用能力上我们也需要使用优秀的实现，而RPC是一个非常适合完成此类工作的工具。

从前文RPC核心功能介绍中我们可以发现RPC不仅仅能够实现客户端和服务之间的通信，同样适合在不同的节点之间通信。选用优秀的RPC框架不仅能够增加单机性能，同时可以增加集群服务的性能。

更多内容，敬请关注同名微信公众号：时空大数据兴趣小组。