CN108055255A - 一种事件库、可扩展数据管理系统及其管理方法 - Google Patents

Abstract

本发明属于计算机技术领域，公开了一个面向可扩展数据管理系统的高性能事件库，主要包括：采用异步非阻塞的技术实现多线程处理网络I/O，能够达到对I/O密集型短任务更加高效的处理，充分发挥了新硬件趋势下的多核处理器性能。该事件库底层采用事件循环模型对事件进行注册和更改，支持同步与异步网络传输，同时实现网络编程与网络协议的隔离，管理系统中服务器间的连接以及连接的输入输出缓冲区，处理收包发包逻辑。本发明通过安装库的方式进行配置即可使用于系统软件的开发。该事件库具有可扩展性，并且对短任务的处理有更明显的性能提升。

Description

一种事件库、可扩展数据管理系统及其管理方法

技术领域

本发明属于计算机技术领域，具体涉及一种事件库、可扩展数据管理系统及其管理方法。

背景技术

互联网应用的蓬勃发展产生了对海量数据存储和处理的更高要求，传统单机模式的数据库管理系统及其纵向扩展方式已经无法满足这样的需求。随着计算机网络与通信技术的发展，可扩展数据管理系统成为许多互联网企业的选择。可扩展数据管理系统采用集群式架构，与传统的数据库最大的区别在于其在逻辑上对数据库管理系统进行了分布。系统将数据分布存储在部分节点，又有另外的部分节点负责并行处理查询和事务。因此，在这样的数据库管理系统中，各节点间需要传输和处理的数据有很多，包括节点的一些控制信息、元数据，也包括各存储节点、查询处理节点以及事务处理节点上的用户数据。

大多数的数据库管理系统采用传统的网络服务器模型如单I/O线程模型或者I/O多路复用模型，让服务端将从网络接收到的请求压入队列，并等待工作线程取出请求再处。PostgreSQL则采用进程间通信配合工作线程的方式来处理网络请求。在可扩展数据管理系统架构下，这些方法实现的网络服务依然存在以下问题需要解决:

(1)阻塞型接口本质上没有很好地发挥大内存和多核的新硬件特点；

(2)对系统内所有需要传输和处理的数据采用一刀切的工作线程处理方式，会因为较多的I/O密集型短任务而增加网络等待以及上下文切换的资源开销。

可扩展数据管理系统中各节点职能分割清晰，节点间需要传输和处理的数据类型较多，其中包括很多可以快速被处理和返回的请求，需要一种网络传输机制支持这样的短任务不用经过网络排队即可在网络I/O线程处理。

基于上述需求，本发明提出了一种面向可扩展数据管理系统的事件库，该事件库采用异步非阻塞技术发挥大内存和多核的新硬件优势，并且支持对系统内不同长短的任务进行区别的处理，长任务压入队列交又工作线程处理减少网络阻塞，短任务就地处理节省等待时间减少上下文切换。

发明内容

本发明提出了一个面向可扩展数据管理系统的事件库，所述事件库以开源高效的libev为基础，封装读写与超时事件在socket上的观测与响应机制，管理网络连接的输入输出缓冲区，将网络请求包的编码解码接口和处理请求包的回调函数暴露给用户；所述事件库包括：用于实现发送网络请求、接收处理响应，管理输入缓冲区的客户端，和用于实现接收、处理网络请求，返回处理响应，管理输出缓冲区的服务端；所述客户端与所述服务端通信。

本发明提出的所述事件库中，在所述事件库作为收包服务端使用时，注册的用户实现的process回调函数中，用户可配置短任务直接处理，长任务压入其他工作线程的队列；所述收包服务端用于系统中的任意节点作为网络请求服务端时使用，支持用户配置网络I/O线程数，设置TCP参数，开启负载检查，注册相关用户实现的回调函数。

本发明提出的所述事件库中，在所述事件库作为发包客户端使用时，用户可配置网络包的编码解码回调函数，自定义网络包的同步或异步发送接口；所述发包客户端用于系统中任意节点作为网络请求客户端时使用，支持用户封装同步发包与异步发包接口，注册相关用户实现的回调函数。

本发明还提出了一种使用所述事件库的可扩展数据事件库的管理系统，其特征在于，包括主控节点、事务处理节点、基线数据存储节点以及用户端管理器；其中，主控节点负责管理集群内所有节点的状态信息，帮助各个节点协同工作，管理集群、数据分布以及副本；所述事务处理节点TNode负责处理写事务，并存储增量更新的数据；所述基线数据存储节点存储大部分的用户数据，提供对数据的读访问支持，能够自动合并基线数据和事务处理节点上的增量数据返回给用户；用户端管理器用来管理用户端通信，对外提供服务接口。

本发明还提出了一种所述可扩展数据管理系统的管理方法，包括收包服务器的收包阶段与发包客户端的的发包阶段；

其中，所述收包阶段包括以下步骤：

步骤a1：初始化网络I/O的线程池；

步骤a2：打开监听端口启动socket监听；

步骤a3：启动线程池中的所有线程，等待接受监听到的客户端连接；

步骤a4：某线程接受客户端连接，注册读写以及超时的事件处理函数；

步骤a5：事件发生时，回调相应的处理函数，读出socket文件描述符中的数据进行处理；

步骤a6：构建返回包，通过socket写出，返回给客户端；

其中，所述发包阶段包括以下步骤：

步骤b1：将请求编码封装后加入连接的发送队列然后返回。

步骤b2：客户端传输请求可以采用异步或同步两种方式。

步骤b3：收到服务端返回的响应包之后，将请求从队列中删除。

本发明提出的所述管理方法中，所述步骤a1中，使用CPU亲缘性，在网络I/O线程对应的线程执行函数中，将进程绑定到指定的cpu，避免缓存失效，以节省线程调度开销。

本发明提出的所述管理方法中，所述步骤a4中，超时事件的处理基于事件循环模型的观测机制，粒度实现在事件的请求包。

本发明提出的所述管理方法中，所述步骤a5中，可对长任务和短任务进行区分，I/O密集型短任务在网络I/O线程就地处理并返回，长任务压入队列后等待应用层的工作线程处理再返回。

本发明提出的所述管理方法中，所述步骤b2中，同步的请求传输方式基于信号量等待的异步非阻塞机制实现。

本发明提出的所述管理方法中，所述步骤b3中，采用哈希存储与查找的方式处理请求包。

本发明的有益效果包括：本发明允许小请求包可以在网络I/O线程处理并快速地返回，减少了系统整体在网络传输上的时间开销；基于异步非阻塞API的实现支持多个网络I/O线程同时传输和处理网络请求包，充分发挥CPU多核优势。

附图说明

图1为本发明所面向的可扩展数据管理系统的整体架构图。

图2为本发明一个面向可扩展数据管理系统的事件库的整体架构图。

图3为本发明一个面向可扩展数据管理系统的事件库的数据结构图。

图4为本发明一个面向可扩展数据管理系统的事件库的服务端处理流程图。

图5为本发明一个面向可扩展数据管理系统的事件库的资源管理图。

图6为本发明一个面向可扩展数据管理系统的事件库对短任务处理在时间上的消耗情况。

具体实施方式

结合以下具体实施例和附图，对发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。

图2显示的是一个面向可扩展数据管理系统的事件库，所述事件库以开源高效的libev为基础，封装读写与超时事件在socket上的观测与响应机制，管理网络连接的输入输出缓冲区，将网络请求包的编码解码接口和处理请求包的回调函数暴露给用户；所述事件库包括：用于实现发送网络请求、接收处理响应，管理输入缓冲区的客户端，和用于实现接收、处理网络请求，返回处理响应，管理输出缓冲区的服务端；所述客户端与所述服务端通信。

图3是事件库的主要数据结构图，其中onev_baseth_e定义了网络I/O线程，是事件库的入口结构体；onev_io_e定义了网络I/O，记录了网络I/O线程池的规模，并关联事件监听器，是事件库I/O的入口结构体；onev_io_thread_e在网络I/O线程上添加了连接对列、会话队列、请求队列以及超时事件观测器等；onev_connection_e是处理TCP连接的结构体，包括文件描述符、连接的地址、各事件的监听器即处理方法、属于该连接的消息队列等，是请求真正被处理独立内存载体；onev_message_e对应一个消息，可以包含若干个请求onev_request_e，而每一个请求对应用户自定义的完整的网络包，贯穿整个处理过程。

图4是事件库的服务端处理流程图，可读事件的回调处理函数onev_connection_on_readable是在onev_connection_on_accept_one中注册的，如果是第一次读数据，会创建一个消息结构体onev_message_e作为网络请求包的载体，读到数据后在服务端调用onev_connection_do_request处理读到的数据，包括依次回调网络包的解码函数、数据处理函数、以及最后响应包的编码函数，最终将结果写入socket。

图5是事件库的资源管理图，其上层显示事件库的各级资源以链表的形式进行维护，与上文的数据结构对应，底层内存池主要展示了大内存固定分配、小内存在大内存区域内动态申请的策略。内存池分配策略中的d对应内存池的数据块，large对应需要大块内存时申请的数据块。d中记录当前数据块分配结束的位置(last)、已用小内存结束的位置(end)、内存池分配失败的次数(failed)和下一个内存池数据的位置(next)。此外，max记录了数据块的大小；current记录了当前内存的指针；ref是引用计数器，用来管理内存的使用与释放；flag与lock处理资源互斥问题。

图1显示的是可扩展数据管理系统的整体架构图，该数据管理系统包括：主控节点MNode(Master-Node)负责管理集群内所有节点的状态信息，帮助各个节点协同工作，管理集群、数据分布以及副本；事务处理节点TNode(Transaction-Node)负责处理写事务，并存储增量更新的数据，是数据库集群中负载较高的节点之一；基线数据存储节点SNode(Storage-Node)存储大部分的用户数据，提供对数据的读访问支持，能够自动合并基线数据和事务处理节点上的增量数据返回给用户；用户端管理器CMgr(Client-Manager)用来管理用户端通信，对外提供服务接口。

实施例1：应用层服务端的使用

服务端首先通过事件库的onev_create_io来初始化onev_io_e的线程池，并且为每个线程添加监听观测器和线程观测器的回调函数。表1列举了事件库应用libev的观测器类型，各事件的回调函数通过对应观测器的操作箱来完成。向libev注册感兴趣的事件，比如socket可读事件，libev会对所注册的时间的源进行管理，并在事件发生时触发相应的程序。

开始一次连接之初，服务端线程池中的所有线程打开监听端口，设置事件循环体监听socket accept事件，当该事件到来时，线程池中的某个线程触发对监听文件句柄的accept操作，创建连接并初始化读写观测器和超时观测器，此时连接上的事件循环体监听读写事件，当有数据可读时，触发读回调读入数据，响应请求。

表1事件库用到的观测器类型

观测器类型	简介
		ev_io	IO可读可写，用于读写观测器
ev_async	激活线程，用于线程观测器
		ev_timer	定时器，用于监听观测器与超时观测器

线程在打开监听端口时，通过对监听观测器添加定时器事件，每100ms触发一次，对应的回调函数onev_connection_on_listen用定时器去抢监听的锁。如果抢到锁，就添加当前监听线程的可读事件。线程切换时，重置观测器并启动可以改变监听观测器的触发频率。

线程池中的某个线程触发对监听文件句柄做accept操作，接受socket连线成功后，会创建连接,初始化对这个文件句柄的超时观测器及读写超时事件。该请求后续所有的事件都会注册在这个线程的事件循环上。当文件句柄可读时触发读回调函数，将请求全部读到消息后，会判断当前是服务端还是客户端，两者将分别通过不同的方式来处理请求或响应。

在图3中，服务器端处理请求首先调用用户实现的解码函数进行解码，即从消息的缓冲区解析数据，将二进制数据转化为网络框架中传输的网络包。每一个解析后的请求都将被挂到输入队列当中去，最后将队列发送到服务端的工作线程，使用应用层在服务端实现的处理函数处理队列中的每一个请求。每次请求处理完成后，网络连接模块将进行最后的处理，将响应挂到请求的输出队列当中去。服务器则继续负责唤醒I/O线程发送响应给客户端。

表2关键数据结构

客户端得到响应时，输出队列不为空，则首先调用用户实现的编码函数，即将数据写入缓冲区，将网络包转化为二进制数据，完成处理之后，使用socket write将数据通过socket写出去。

实施例2:应用层客户端的使用

应用层客户端可以选择同步和异步两种方式发送请求。

在发包前，首先创建onev_session_e分配内存空间用于发送，并将请求包装入session，设session目标服务端的server地址，并将其与消息关联起来。这里注意每一个session包含一个请求，而每一个消息可以包含多个session，如图4.

之后调用onev_client_dispatch则表示应用层需要客户端异步发送请求，调用onev_client_send则表示应用层需要客户端同步发送请求。前者会在发送前通过onev_session_set_timeout宏设置session的超时时间，发送后事件库将从I/O线程池中选择I/O线程，向其添加session后唤醒该线程，线程被唤醒后对每一个session选择一个连接来进行发送并管理连接的输入输出缓冲区。后者在信号量等待的机制上调用了onev_client_dispatch来实现同步等待请求处理完成后再返回。

实施例3：资源管理中的内存分配

使用大内存固定分配、小内存不固定长度申请的内存池方案来管理内存，进而管理网络I/O、连接、请求等资源的分配与释放。各级资源以链表的方式来维护。内存管理以连接为单位，即以连接为单位释放内存，连接之间的资源互不干涉。

在图4中，每一个数据库请求对应于应用层一个具体的请求包，贯穿请求的输入、处理和输出的整个流程。客户端发送请求包时需要将请求封装到消息当中，设置用于解码的输入缓冲区，对应连接的输入缓冲区，设置处理函数和超时观测器。一个消息可以只包含一个请求也可以包含多个请求。消息最终交由一个TCP连接来进行发送。

实施例4：短任务处理对时间的消耗

通过本事件库，可扩展数据库的事务处理节点可以采用通常的排队机制处理网络上的所有请求，也可以采用事件库支持的网络I/O线程就地处理的方式来处理短任务，图6统计了两种方式在某种负载下处理短任务的时间的平均消耗。

可以看出，当I/O密集型短任务占负载的较大比重的情况下，采用通常的排队配合工作线程的方式时，短任务在网络线程的平均等待时间达到200微秒，因为短任务同长任务一起在任务队列中等待，被长任务阻塞的时间较长。而其加上工作线程的处理时间之后整体的平均处理(响应)时间大概在300微秒，即短任务在工作线程的处理时间远小于其在网络I/O上的等待时间。

为了节省短任务在网络I/O线程阻塞的时间，选择网络I/O就地处理，使得请求可以被快速处理并立即返回，整体平局处理(响应)时间几乎接近上述第一种方式下工作线程的平均处理时间。

对任务进行长短区分和不同线程处理的选择主要由应用层决定。本发明的事件库主要通过事件循环的方式来支持网络I/O线程可以同时作为工作线程。

本发明的保护内容不局限于以上实施例。在不背离发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。

Claims (10)

1.一个面向可扩展数据管理系统的事件库，其特征在于，所述事件库以开源高效的libev为基础，封装读写与超时事件在socket上的观测与响应机制，管理网络连接的输入输出缓冲区，将网络请求包的编码解码接口和处理请求包的回调函数暴露给用户；

所述事件库包括：用于实现发送网络请求、接收处理响应，管理输入缓冲区的客户端，和用于实现接收、处理网络请求，返回处理响应，管理输出缓冲区的服务端；所述客户端与所述服务端通信。

2.如权利要求1所述的事件库，其特征在于，在所述事件库作为收包服务端使用时，注册的用户实现的process回调函数中，用户可配置短任务直接处理，长任务压入其他工作线程的队列；所述收包服务端用于系统中的任意节点作为网络请求服务端时使用，支持用户配置网络I/O线程数，设置TCP参数，开启负载检查，注册相关用户实现的回调函数。

3.如权利要求1所述的事件库，其特征在于，在所述事件库作为发包客户端使用时，用户可配置网络包的编码解码回调函数，自定义网络包的同步或异步发送接口；所述发包客户端用于系统中任意节点作为网络请求客户端时使用，支持用户封装同步发包与异步发包接口，注册相关用户实现的回调函数。

4.一种使用如权利要求1‐3之任一项所述的事件库的可扩展数据事件库的管理系统，其特征在于，包括主控节点、事务处理节点、基线数据存储节点以及用户端管理器；其中，主控节点负责管理集群内所有节点的状态信息，帮助各个节点协同工作，管理集群、数据分布以及副本；所述事务处理节点TNode负责处理写事务，并存储增量更新的数据；所述基线数据存储节点存储大部分的用户数据，提供对数据的读访问支持，能够自动合并基线数据和事务处理节点上的增量数据返回给用户；用户端管理器用来管理用户端通信，对外提供服务接口。

5.一种如权利要求4所述可扩展数据管理系统的管理方法，其特征在于，包括收包服务器的收包阶段与发包客户端的的发包阶段；

其中，所述收包阶段包括以下步骤：

步骤a1：初始化网络I/O的线程池；

步骤a2：打开监听端口启动socket监听；

步骤a3：启动线程池中的所有线程，等待接受监听到的客户端连接；

步骤a4：某线程接受客户端连接，注册读写以及超时的事件处理函数；

步骤a5：事件发生时，回调相应的处理函数，读出socket文件描述符中的数据进行处理；

步骤a6：构建返回包，通过socket写出，返回给客户端；

其中，所述发包阶段包括以下步骤：

步骤b1：将请求编码封装后加入连接的发送队列然后返回。

步骤b2：客户端传输请求可以采用异步或同步两种方式。

步骤b3：收到服务端返回的响应包之后，将请求从队列中删除。

6.根据权利要求5所述的管理方法，其特征在于，所述步骤a1中，使用CPU亲缘性，在网络I/O线程对应的线程执行函数中，将进程绑定到指定的cpu，避免缓存失效，以节省线程调度开销。

7.根据权利要求5所述的管理方法，其特征在于，所述步骤a4中，超时事件的处理基于事件循环模型的观测机制，粒度实现在事件的请求包。

8.根据权利要求5所述的管理方法，其特征在于，所述步骤a5中，可对长任务和短任务进行区分，I/O密集型短任务在网络I/O线程就地处理并返回，长任务压入队列后等待应用层的工作线程处理再返回。

9.根据权利要求5所述的管理方法，其特征在于，所述步骤b2中，同步的请求传输方式基于信号量等待的异步非阻塞机制实现。

10.根据权利要求5所述的管理方法，其特征在于，所述步骤b3中，采用哈希存储与查找的方式处理请求包。