CN110618996A - 一种应用于分布式数据库的函数库热更新方法 - Google Patents

Abstract

本发明涉及一种应用于分布式数据库的函数库热更新方法，包括以下步骤：将动态库存放到hadoop分布式文件系统上；将所需信息写入配置文件中；将配置文件同步到指定的zookeeper配置监听目录；当所述指定的zookeeper配置监听目录下有修改，通知各节点；所述各节点接收到zookeeper的消息后，更新配置文件，同时重新加载配置文件，完成函数库的更新。本发明实现了应用于分布式数据库的可即插即用函数库技术，无需重新编译，无需重新启动，无需对每个节点冗余更新。

Description

一种应用于分布式数据库的函数库热更新方法

技术领域

本发明涉及分布式数据库技术领域，具体来说，涉及一种应用于分布式数据库的函数库热更新方法。

背景技术

数据库管理系统（英语：Database Management System，简称DBMS）是为管理数据库而设计的电脑软件系统，具有存储、截取、安全保障、备份等基础功能。一般通过SQL语句进行增加、修改、查询数据，而为了能够获取所需的数据或结果，在查询数据的过程中，使用不同功能函数对数据进行加工处理也是必不可少的。由于经常需要增加一些新的需求功能，故在数据库管理系统的设计中，函数库的设计应当具备高可扩展性。

现有函数库设计方式主要有以下两种：

1、将函数直接编译成静态库.a

这是最基本的实现方式，实现起来最为简单，但弊端也很明显，每次增加新函数，必须重新编译，生成可执行程序。

2、将函数编译成动态库.so

为了避免重新编译这一弊端，已有采用动态函数库的方式，这样新增一个功能函数时，不需要重新编译，只需重新加载配置文件（用于运行时读取函数的信息）。

现有的动态函数库这种方式，仍存在一些缺点：

缺点1：虽然解决了重新编译的问题，但对于分布式数据库来说，需要对各个节点进行更新配置文件、添加动态库的操作，这一操作是繁琐冗余的。

缺点2：采用一次读取配置文件，即配置文件在程序运行时只会被读取一次，这样就导致每次更新配置文件后，需要重启程序，无法实现热更新。

针对相关技术中的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中的上述技术问题，本发明提出一种应用于分布式数据库的函数库热更新方法，能够避免以上两个缺点，实现应用于分布式数据库的可即插即用函数库技术，无需重新编译，无需重新启动，无需对每个节点冗余更新。

为实现上述技术目的，本发明的技术方案是这样实现的：

一种应用于分布式数据库的函数库热更新方法，其特征在于，包括以下步骤：

S1、将动态库存放到hadoop分布式文件系统上；

S2、将所需信息写入配置文件中；

S3、将配置文件同步到指定的zookeeper配置监听目录；

S4、当所述指定的zookeeper配置监听目录下有修改，通知各节点；

S5、所述各节点接收到zookeeper的消息后，更新配置文件，同时重新加载配置文件，完成函数库的更新。

进一步的，所述S1步骤中的动态库为在linux下使用编译指令将新增函数编译成的.so动态库。

进一步的，所述.so动态库存放在hadoop分布式文件系统上的任意位置。

进一步的，所述S2步骤中的所需信息包括函数的基本信息及动态库在hadoop分布式文件系统上的存放路径。

进一步的，所述S3步骤具体为：将配置文件保存到zookeeper的任一目录节点下，分布数据库的所有节点都对该目录节点进行监听。

进一步的，所述S4步骤具体为：当配置文件被更改时，zookeeper会通知分布数据库的各节点。

进一步的，所述S5步骤具体为：分布数据库的各节点接收zookeeper的消息后，获取最新的配置文件内容，同时重新加载配置文件中的函数信息，完成函数库的更新。

进一步的，还包括S6步骤：当函数调用时，从hadoop分布式文件系统上动态加载并调用。

进一步的，所述S6步骤具体为：当调用函数时，根据已加载的函数信息和.so动态库存放路径，从hadoop分布式文件系统上读取，然后动态加载函数库并调用相应函数。

本发明的有益效果：函数库支持多节点共享的基础上，在新增函数功能时，分布式数据库的所有节点不需要重新编译、重新启动，实时进行更新、应用。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例所述的一种应用于分布式数据库的函数库热更新方法的流程图。

图2是根据本发明实施例所述的设计概念图。

图3是根据本发明实施例所述的配置更新图。

其中，hdfs为hadoop分布式文件系统的缩写。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，根据本发明实施例所述的一种应用于分布式数据库的函数库热更新方法，包括以下步骤：S1、函数实现编译成动态库；S2: 将动态库存放到hdfs；S3: 修改配置文件；S4: 将配置文件同步到指定的zookeeper配置监听目录；S5: 当指定的zookeeper配置监听目录下有修改，通知各节点；S6: 各节点接收到zookeeper的消息后，更新配置文件，同时重新加载配置文件；S7: 函数调用时，从hdfs上动态加载并调用。

在本优选实施例中，上述方法具体过程如下：

连接zookeeper：zk = new zookeeper(ip:port, time_out, 监听事件处理watcher)。

S1：在linux下，使用编译指令将新增函数编译成.so动态库。

S2：将该.so动态库存放到hdfs上的指定位置（随意）：存放hadoop fs -put /{本地文件路径} /{目标文件路径}。

S3：将函数的基本信息及在hdfs上的存放路径写入配置文件中。

S4：将配置文件保存到zookeeper的某一目录节点（随意）下：创建目录zk.create(目录路径”/conf”,，初始数据”data0”)、修改配置zk.setData(目录路径”/conf”，待写入数据”data1”)。

分布数据库的所有节点都对该目录节点进行监听：监听配置zk.exist(目录路径”/conf”，是否监控true)。

S5：当配置文件被更改时，zookeeper会通知分布数据库的各节点。

S6：分布数据库的各节点接收zookeeper的消息后，获取最新的配置文件内容，同时重新加载配置文件中的函数信息。

在监听事件处理watcher中添加：获取数据zk.getData(目录路径“/conf”，是否监控false，null)。

S7：当调用函数时，根据已加载的函数信息和.so动态库存放路径，从hdfs上读取，然后动态加载函数库并调用相应函数。

为了方便理解本发明的上述技术方案，以下通过具体设计思路与原理上对本发明的上述技术方案进行详细说明。

在具体设计时，为弥补现有技术的不足，本发明提供一种应用于分布式数据库的函数库热更新方法，分布式数据库主要使用hdfs（Hadoop分布式文件系统）提供文件管理，使用zookeeper（一个分布式应用程序协调服务）提供配置管理、集群管理、分布式锁、队列管理。

分布数数据库启动的每个节点都会在zookeeper中注册一个临时目录用于集群管理（zookeeper原理）；将动态函数库存放在hdfs上；将配置文件存放在zookeeper，分布式数据库的各个节点通过zookeeper进行配置管理，始终获取最新的配置文件，从配置文件中获取函数的描述信息以及其在hdfs上的存放路径，然后动态加载函数，进行调用。

从而增加新函数功能时，只需要添加动态函数库到hdfs上，更改配置文件，其分布式数据库的各节点实现实时更新、应用。

设计概念图如图2所示；配置更新图如图3所示。

以下为HDFS与Zookeeper的基本说明

HDFS：Hadoop分布式文件系统

HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。

Zookeeper文件系统：

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

最基本的有四种类型znode：

1、PERSISTENT-持久化目录节点

客户端与zookeeper断开连接后，该节点依旧存在。

2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号。

3、EPHEMERAL-临时目录节点

客户端与zookeeper断开连接后，该节点被删除。

4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号。

Zookeeper通知机制：

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

综上所述，本发明以函数库共享为基础，以函数配置信息文件实时热更新为核心，采用zookeeper为分布式应用提供配置管理,从而使数据库新增函数功能时，方便快捷。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种应用于分布式数据库的函数库热更新方法，其特征在于，包括以下步骤：

S1、将动态库存放到hadoop分布式文件系统上；

S2、将所需信息写入配置文件中；

S3、将配置文件同步到指定的zookeeper配置监听目录；

S4、当所述指定的zookeeper配置监听目录下有修改，通知各节点；

S5、所述各节点接收到zookeeper的消息后，更新配置文件，同时重新加载配置文件，完成函数库的更新。

2.根据权利要求1所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述S1步骤中的动态库为在linux下使用编译指令将新增函数编译成的.so动态库。

3.根据权利要求2所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述.so动态库存放在hadoop分布式文件系统上的任意位置。

4.根据权利要求3所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述S2步骤中的所需信息包括函数的基本信息及动态库在hadoop分布式文件系统上的存放路径。

5.根据权利要求4所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述S3步骤具体为：将配置文件保存到zookeeper的任一目录节点下，分布数据库的所有节点都对该目录节点进行监听。

6.根据权利要求5所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述S4步骤具体为：当配置文件被更改时，zookeeper会通知分布数据库的各节点。

7.根据权利要求6所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述S5步骤具体为：分布数据库的各节点接收zookeeper的消息后，获取最新的配置文件内容，同时重新加载配置文件中的函数信息，完成函数库的更新。

8.根据权利要求7所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，还包括S6步骤：当函数调用时，从hadoop分布式文件系统上动态加载并调用。

9.根据权利要求8所述的一种应用于分布式数据库的函数库热更新方法，其特征在于，所述S6步骤具体为：当调用函数时，根据已加载的函数信息和.so动态库存放路径，从hadoop分布式文件系统上读取，然后动态加载函数库并调用相应函数。