一种数据库访问系统和方法与流程

1.本发明属于数据库访问领域，具体涉及一种数据库访问系统和方法。


背景技术：

2.本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.随着云计算、移动互联网、物联网的崛起与发展，大数据的时代已经来临。hdfs、mapreduce、hbase作为hadoop的核心组成部分，在大数据计算与存储领域处在无可替代的地位。
4.hbase(hadoop database)是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，一个分布式的、面向列的开源数据库，利用hbase技术可在廉价pc server上搭建起大规模结构化存储集群。该特性使得hbase适合企业级的海量数据存储及查询。
5.hbase提供的接口包括(1)native java api；(2)hbase shell；(3)thrift gateway；(4)rest gateway；(5)pig；(6)hive。其中，native java api是最常规和高效的访问方式，适合hadoop mapreduce job并行批处理hbase表数据。而thrift gateway和rest gateway这两种接口可以实现种语言的访问。其中，thrift gateway利用thrift序列化技术，可以支持c++，php，python等多种语言访问hbase。rest gateway则支持rest风格的http api访问hbase。
6.可以理解，在使用hbase时不能期待仅使用java开发的应用去访问hbase，而是希望可以多语言(例如c++)访问hbase，且依然保持高效可靠。现有技术中，以现有的thrift gateway举例，使用非java编程语言应用访问hbase仍然存在如下问题：(1)在使用时没有完整的官方文档；(2)bug修复及更新不及时；(3)任意一个大版本的升级，都有可能导致不兼容的问题出现，使用代码需要重新修改。
7.因此，如何不采用thrift技术而实现任意编程语言应用访问hbase数据库是一个亟待解决的问题。


技术实现要素：

8.针对上述现有技术中存在的问题，提出了一种方法、装置及计算机可读存储介质，利用这种方法、装置及计算机可读存储介质，能够解决上述问题。
9.本发明提供了以下方案。
10.第一方面，提供一种数据库访问系统，所述系统包括：客户端、以java语言开发的服务端和hbase数据库；所述客户端，用于生成针对hbase数据库的访问请求，并将所述访问请求发送至服务端；所述服务端，用于接收所述客户端发送的所述访问请求，解析所述访问请求以得到访问请求内容，根据所述访问请求内容调用所述hbase数据库的native java api以访问所述hbase数据库，并将从所述hbase数据库得到的访问结果返回所述客户端。
11.在一种可能的实施方式中，客户端是采用非java编程语言开发获得。
12.在一种可能的实施方式中，所述系统包括多个所述客户端和多个所述服务器，还包括：部署在多个所述客户端和多个所述服务器之间的分布式消息系统，以建立所述客户端和所述服务器之间的通讯连接，其中，所述分布式消息系统在多个所述客户端和多个所述服务器之间提供持久化的消息缓存机制。
13.在一种可能的实施方式中，所述分布式消息系统还包括：通讯服务代理，所述通讯服务代理利用负载均衡算法将所述客户端的所述访问请求分发到多个所述服务端中的目标服务端。
14.在一种可能的实施方式中，所述系统还包括：zookeeper组件，用于为所述分布式消息系统提供分布式协调服务。
15.第二方面，提供一种数据库访问方法，应用于如第一方面的系统，所述方法包括：客户端生成针对hbase数据库的访问请求，并将所述访问请求发送至服务端；所述服务端接收所述客户端发送的所述访问请求，解析所述访问请求以得到访问请求内容，根据所述访问请求内容调用所述hbase数据库的native java api以访问所述hbase数据库，并将从所述hbase数据库得到的访问结果返回所述客户端。
16.在一种可能的实施方式中，所述客户端是采用非java编程语言开发获得。
17.在一种可能的实施方式中，所述系统包括多个所述客户端和多个所述服务器，所述方法还包括：利用部署在多个所述客户端和多个所述服务器之间的分布式消息系统，建立所述客户端和所述服务器之间的通讯连接，其中，所述分布式消息系统在多个所述客户端和多个所述服务器之间提供持久化的消息缓存机制。
18.在一种可能的实施方式中，所述分布式消息系统还包括通讯服务代理，所述方法还包括：所述通讯服务代理利用负载均衡算法将所述客户端的所述访问请求分发到多个所述服务端中的目标服务端。
19.在一种可能的实施方式中，所述方法还包括：利用zookeeper组件为所述分布式消息系统提供分布式协调服务。
20.本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本实施例中，通过客户端和服务端之间的消息交互、服务端对hbase数据库的调用操作，无需利用thrift技术，即可支持诸如任意一种编程语言开发的客户端在线无感地访问hbase数据库。
21.应当理解，上述说明仅是本发明技术方案的概述，以便能够更清楚地了解本发明的技术手段，从而可依照说明书的内容予以实施。为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举例说明本发明的具体实施方式。
附图说明
22.通过阅读下文的示例性实施例的详细描述，本领域普通技术人员将明白本文所述的优点和益处以及其他优点和益处。附图仅用于示出示例性实施例的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的标号表示相同的部件。在附图中：
23.图1为根据本发明一实施例的数据库访问系统的结构示意图；；
24.图2为根据本发明另一实施例的数据库访问系统的结构示意图；
25.图3为根据本发明一实施例的数据库访问方法的流程示意图。
26.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
27.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
28.在本申请实施例的描述中，应理解，诸如“包括”或“具有”等术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不旨在排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在的可能性。
29.除非另有说明，“/”表示或的意思，例如，a/b可以表示a或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。
30.术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
31.本申请中的所有代码都是示例性的，本领域技术人员根据所使用的编程语言，具体的需求和个人习惯等因素会在不脱离本申请的思想的条件下想到各种变型。
32.另外还需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
33.图1为根据本申请一实施例的数据库访问系统100的结构示意图。
34.如图1所示，系统包括：以任意编程语言开发的客户端101、以java编程语言开发的服务端102和hbase数据库103。
35.客户端101，比如可以是诸如c++、php、python、go等任意一种非java编程语言开发的客户端应用，也可以是基于java编程语言开发的客户端应用，其具体可以用于生成针对hbase数据库的访问请求，该访问请求可以根据具体需执行的访问操作类型和访问操作对象等访问操作内容进行序列化后生成，并可以基于客户端101和服务端102的通讯连接将该访问请求发送至服务端102。
36.服务端102，其具体可以用于接收客户端101发送的访问请求，解析(反序列化)该访问请求以重新得到以上具体需执行的、诸如访问操作类型和访问操作对象等的访问操作内容，基于此，由于服务端102是以java编程语言开发的，其可以根据解析得到的访问操作内容进一步调用hbase数据库的native java api(原生java接口)以访问hbase数据库，并将从所述hbase数据库得到的访问结果返回所述客户端101。服务端102还可以对该访问结果进行与上述类似的序列化处理之后返回客户端101。
37.在本实施例中，将访问hbase数据库从原有的逻辑中进行拆分，变成(1)客户端将需要针对hbase数据库的访问操作内容以通讯的方式告知服务端；(2)服务端将客户端试图操作的访问操作内容以native java api的方式访问hbase；(3)服务端将访问hbase数据库得到访问结果返回客户端。通过这种方式，将操作内容和native java api进行解耦，解除了编程语言的限制。对于客户端101而言，其仅执行了发出访问请求和接收访问结果的操作，即可完成实现数据库访问，其对服务端102内部执行的操作和服务端和hbase数据库之
间的交互是无感的。
38.对于客户端101而言，其仅执行了发出访问请求和接收访问结果的操作，即可完成实现数据库访问，其对服务端102内部执行的操作和服务端和hbase数据库之间的交互是无感的。
39.native java api是hbase数据库提供的高效可靠的访问方式，利用该api，无需额外对hbase数据库进行改变，即可能够实现稳定高效的数据库访问。
40.在一种可能的实施方式中，客户端101可以是以非java编程语言开发得到的，非java编程语言可以是任意一种java以外的编程语言，比如c语言，c++语言、php语言、python语言、go语言等等。由此，可以实现跨语言的应用访问hbase数据库。
41.在一种可能的实施方式中，所述系统包括多个所述客户端和多个所述服务器，系统还包括：部署在多个所述客户端和多个所述服务器之间的分布式消息系统，以建立所述客户端和所述服务器之间的通讯连接。
42.分布式消息系统也可以称为分布式消息中间件系统或者分布式消息发布
‑
订阅系统(a distributed publish
‑
subscribe messaging system)。分布式消息系统通过利用消息队列可以使消息发布方(也可以称为消息生产者)和消息订阅方(也可以称为消息消费者)不需要同时与消息保持联系，消息发布方发布的消息被持久化存储于消息队列中，而消息订阅方可以在消息持久化存储的有效期内通过消息队列获取到消息发布方发布的消息。
43.在本实施例的示例中，客户端不断向消息队列发出访问请求，作为消息生产者。服务端不断从消息队列提取访问请求，作为消息消费者。可以理解，当服务端向客户端返回访问结果时，二者的身份可能调换。
44.目前，基于kafka的分布式消息系统由于其具有高吞吐量等优点而被广泛应用于各种业务场景中。
45.其中，分布式消息系统在多个客户端和多个服务器之间提供持久化的消息缓存机制。
46.例如，持久化的消息缓存机制具体可以指：该消息缓存机制会保留所有已被发布的消息记录，不论该记录是否被消费，当然也可通过配置更改日志保留的生存周期。比如，日志的生存周期策略设置为2天，当消息被发布到服务端后，在这之后的两天内，该消息可以被消费。之后，消息将被删除以释放磁盘空间。
47.每个消息消费者上保存的唯一元数据就是当前消息消费者在log中消费的偏移或者位置。消息消费者来对偏移进行控制：一般来说，一个消息消费者的偏移随着其不断消费消息而线性增加。但正由于消息消费者来控制对log消费的偏移量，因此消费者也可在其想要消费的任何位置开始进行消费。比如，消费者可以重置偏移到一个更老的偏移值，以便可以进行消息重消费。或者通过补偿跳到最近，并从当前开始消费。
48.在本实施例中，通过在客户端与服务端之间采用分布式的、多副本的分布式消息系统用以提高吞吐率，并增加消息持久化的缓存机制，可以增加服务的可靠性。
49.在一种可能的实施方式中，参考图2，分布式消息系统还可以包括：通讯服务代理，该通讯服务代理利用负载均衡算法将所述客户端的所述访问请求分发到多个所述服务端中的目标服务端。具体地，该目标服务端可以是多个服务端中负载最小的可运行服务端，由此该通讯服务代理可以实现多个服务端之间的负载均衡。
50.在一种可能的实施方式中，参考图2，系统还可以包括：zookeeper组件，用于为所述分布式消息系统提供分布式协调服务。
51.zookeeper组件是一个开源的分布式协调服务，目前由apache进行维护。zookeeper组件可以用于实现分布式系统中常见的发布/订阅、负载均衡、命令服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能。其具有以下特性：顺序一致性、原子性、单一视图、可靠性、实时性。zookeeper组件的具体协调原理和作用是已知的，本处不再赘述。
52.在一个示例中，通过在多个所述客户端和多个所述服务器之间采用以上所描述的基于zookeeper组件协调的分布式消息系统，可以实现：(1)可以用于java应用与多种非java语言应用之间进行byte调用；(2)也可以用于java应用与java应用之间进行rpc调用；(3)可以实现长链接、心跳、自动重连、负载均衡、容错、服务注册发现等功能；(4)分布式消息系统间调用采用网状结构。
53.图3为根据本申请一实施例的数据库访问方法300的流程示意图，其应用于如第一方面的系统。
54.如图3所示，所述方法300包括：
55.s301、客户端生成针对hbase数据库的访问请求。
56.s302、客户端将访问请求发送至服务端。
57.s303，服务端接收客户端发送的访问请求.
58.s304，服务端解析访问请求以得到访问请求内容，
59.s305，服务端根据访问请求内容调用hbase数据库的native java api以访问hbase数据库，
60.s306，服务端从hbase数据库得到访问结果
61.s307，服务端将访问结果返回客户端。
62.在一种可能的实施方式中，所述系统包括多个所述客户端和多个所述服务器，所述方法还包括：利用部署在多个所述客户端和多个所述服务器之间的分布式消息系统，建立所述客户端和所述服务器之间的通讯连接。
63.在一种可能的实施方式中，所述分布式消息系统还包括通讯服务代理，所述方法还包括：所述通讯服务代理利用负载均衡算法将所述客户端的所述访问请求分发到多个所述服务端中的目标服务端。
64.在一种可能的实施方式中，所述方法还包括：利用zookeeper组件为所述分布式消息系统提供分布式协调服务。
65.在一种可能的实施方式中，所述客户端是采用非java编程语言开发获得。
66.需要说明的是，本实施例中未作详细说明的步骤可以参考以上所示实施例中相关步骤中的描述，此处不再赘述。
67.关于本申请实施例的方法流程图，将某些操作描述为以一定顺序执行的不同的步骤。这样的流程图属于说明性的而非限制性的。可以将在本文中所描述的某些步骤分组在一起并且在单个操作中执行、可以将某些步骤分割成多个子步骤、并且可以以不同于在本文中所示出的顺序来执行某些步骤。可以由任何电路结构和/或有形机制(例如，由在计算机设备上运行的软件、硬件(例如，处理器或芯片实现的逻辑功能)等、和/或其任何组合)以
任何方式来实现在流程图中所示出的各个步骤。
68.本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以其描述进行了简化，相关之处可参见方法实施例的部分说明即可。
69.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
70.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
71.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
72.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
73.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
74.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
75.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd
‑
rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
76.虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。