数据库的处理方法、装置、存储介质及电子装置与流程

本发明涉及通信领域，具体而言，涉及一种数据库的处理方法、装置、存储介质及电子装置。

背景技术：

现代的数据库中，都可以并行地处理事务，例如通用oltp(on-linetransactionprocessing，联机事务处理过程，也称为面向交易的处理过程)数据库包括如下标准特征：基于磁盘存储的一系列数据结构(如堆文件、b树等)、基于锁的并发控制以支持多条语句并发执行、基于日志的恢复机制、高效的缓存管理机制。所有现代数据库都广泛地支持多线程机制，包括一系列事务并发控制协议和代码中广泛存在的共享数据结构(如缓存池、索引页等)的互斥控制。传统多线程的动机是允许一个事务在等待磁盘返回数据时执行另外一个事务或者防止长事务阻塞短事务的执行。

因此随着业务应用的飞速发展传统oltp数据库的这种多线程并发控制方案的缺点逐渐凸显：1、对于用户数据的访问需要通过锁机制进行控制，尤其是满足事务的完全acid(原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability))特性时，读写都需要加锁，当业务请求并发度增大时，锁资源、控制逻辑复杂度、死锁检测等机制都需要消耗大量的cpu资源，对性能造成很大影响。2、数据库内部存在大量的共享数据结构如：锁管理器、索引页、日志管理器、缓存池等等，在多线程并发访问时必须通过latch或者mutex进行访问控制，这在并发数较高尤其是服务器cpu总数很多的情况下将会消耗更多的cpu资源同时增加事务处理的时延。

针对相关技术中存在的在数据库的多线程并发控制中随着cpu数目的增多，访问冲突越来越严重，从而造成大量的cpu资源浪费，增加事务处理的时延，进而降低业务处理能力的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种数据库的处理方法、装置、存储介质及电子装置，以至少解决相关技术中存在的在数据库的多线程并发控制中随着cpu数目的增多，访问冲突越来越严重，从而造成大量的cpu资源浪费，增加事务处理的时延，进而降低业务处理能力的问题。

根据本发明的一个实施例，提供了一种数据库的处理方法，包括：接收用于请求对数据库中的预定数据进行处理的处理请求；确定用于对所述预定数据进行处理的预定中央处理器cpu，其中，所述数据库中包括两个以上数据分片，不同的数据分片中包括的数据不同，且不同的数据分片对应的用于对数据分片中的数据进行处理的处理cpu不同；指示所述预定cpu按照所述处理请求对所述预定数据进行处理。

可选地，在确定用于对所述预定数据进行处理的预定cpu之前，所述方法还包括：获取数据分片与处理cpu的对应关系；确定用于对所述预定数据进行处理的预定cpu包括：确定所述预定数据所属的数据分片；根据所述对应关系确定与所述预定数据所属的数据分片对应的所述预定cpu。

可选地，获取数据分片与处理cpu的对应关系包括第一获取方式或第二获取方式，其中，所述第一获取方式包括：对所述数据库中的数据进行分片，其中，分片后的各数据分片之间无依赖关系；为各数据分片分别分配一个对应的处理cpu；建立数据分片与分配的处理cpu之间的对应关系；所述第二获取方式包括：接收来自管理cpu的所述对应关系。

可选地，在建立数据分片与分配的处理cpu之间的对应关系之后，还包括：在预定条件下执行以下操作至少之一，并基于执行后的操作重新建立数据分片与分配的处理cpu之间的对应关系：对所述数据库中的数据进行重新分片，并重新对分片后的各数据分片配置对应的处理cpu；为所述数据库中的数据分片重新分配对应的处理cpu；其中，重新分配的处理cpu中包括原有的处理cpu和/或新增加的处理cpu，所述预定条件包括以下至少之一：根据收集的各处理cpu的负载信息以及各数据分片中数据的处理信息确定存在处理cpu负载不均衡，接收到重新分配指令。

可选地，对所述数据库中的数据进行重新分片后的数据分片总数小于重新分片之前的数据分片总数；或者，对所述数据库中的数据进行重新分片后的数据分片总数等于重新分片之前的数据分片总数；或者，对所述数据库中的数据进行重新分片后的数据分片总数大于重新分片之前的数据分片总数。

可选地，当获取数据分片与处理cpu的对应关系包括所述第一获取方式时，接收用于请求对数据库中的预定数据进行处理的处理请求包括：接收来自应用app的所述处理请求。

可选地，指示所述预定cpu按照所述处理请求对所述预定数据进行处理包括：将所述处理请求放置于所述预定cpu对应的请求队列中，以指示所述预定cpu从所述请求队列中获取所述处理请求，并按照所述处理请求对所述预定数据进行处理。

可选地，在接收用于请求对数据库中的预定数据进行处理的处理请求之后，所述方法还包括：在确定所述数据库中不存在所述预定数据，或者不存在对所述预定数据进行处理的处理cpu时，返回错误响应。

根据本发明的另一个实施例，提供了一种数据库的处理装置，包括：接收模块，用于接收用于请求对数据库中的预定数据进行处理的处理请求；确定模块，用于确定用于对所述预定数据进行处理的预定中央处理器cpu；指示模块，用于指示所述预定cpu按照所述处理请求对所述预定数据进行处理。

可选地，所述装置还包括：获取模块，用于在确定用于对所述预定数据进行处理的预定cpu之前，获取数据分片与处理cpu的对应关系；所述确定模块包括：第一确定单元，用于确定所述预定数据所属的数据分片；第二确定单元，用于根据所述对应关系确定与所述预定数据所属的数据分片对应的所述预定cpu。

根据本发明的另一个实施例，提供了一种数据库的处理系统，包括：处理器，两个以上处理cpu，数据库，其中，所述处理器用于执行以下处理：接收用于请求对所述数据库中的预定数据进行处理的处理请求；从所述两个以上处理cpu中确定用于对所述预定数据进行处理的预定中央处理器cpu；指示所述预定cpu按照所述处理请求对所述预定数据进行处理；所述两个以上处理cpu用于根据来自所述处理器的请求对所述数据库中的数据进行处理。

可选地，所述两个以上处理cpu被分为两个以上处理服务器组，其中，每个处理服务器组具备组内的处理cpu扩缩容以及在组内的处理cpu间进行业务调度的能力，且不同的处理服务器组之间具备业务调度的能力。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本发明，由于数据库中包括多个数据分片，不同数据分片分别对应不同的处理cpu，由与其相对应的处理cpu处理该数据分片中的数据。避免了传统的多线程并发控制中，由于多核系统中的多个cpu共同访问数据库中的数据而带来当cpu数目的增多时，共同访问数据库中的数据的逻辑结构成倍上升，并由此增加了更多的操作成本。可以解决相关技术中存在的在数据库的多线程并发控制中随着cpu数目的增多，访问冲突越来越严重，从而造成大量的cpu资源浪费，增加事务处理的时延，进而降低业务处理能力的问题，进而达到了降低数据库的多线程并发控制的复杂度，降低数据库事务的请求响应时延，提高了业务处理能力的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的传统的多线程并发控制模型图；

图2是根据本发明实施例的分片式多线程并发控制模型图；

图3是根据本发明实施例的一种数据库的处理方法的移动终端的硬件结构框图；

图4是根据本发明实施例的一种数据库的处理方法的流程图；

图5是根据本发明实施例的一种用户数据分片示例图；

图6是根据本发明实施例的用户请求处理cpu工作队列图；

图7是根据本发明实施例的分片式并发处理实例图；

图8是根据本发明实施例的第一种分片式并发处理实例图；

图9是根据本发明实施例第一种分片式并发处理框架下的业务流程图；

图10是根据本发明可选实施例的第二种分片式并发处理实例图；

图11是根据本发明可选实施例的第二种分片式并发处理框架下的app分片元数据信息获取流程图；

图12是根据本发明可选实施例的第二种分片式并发处理框架下的业务流程图；

图13是根据本发明可选实施例的一种可动态伸缩的分片式并发处理框架实例图；

图14是根据本发明可选实施例的分布式环境下的一种分片式并发处理框架实例图；

图15是根据本发明可选实施例的一种数据库的处理装置的结构框图。

具体实施方式

首先对相关技术进行说明：

图1描述的是传统的多线程并发控制模型，具体描述如下：内存中维护两部分数据：第一部分是来自业务应用的用户数据；第二部分是共享数据结构，包括锁管理器、索引页、日志管理器、缓存池等等。多核系统下各cpu共享访问上述两部分数据，正是由于多个cpu共同操作访问相同的数据，因此引入了上述第二部分共享数据结构的维护。从图1中可以看出，为了正确的管理业务应用的用户数据，除了对用户数据本身的管理还需要增加大量的共享结构数据的维护，这无疑会增加很多额外的成本，当cpu数量增多的情况下带来的逻辑复杂度会成倍上升，花费在这类操作上的成本也随之增加。

《oltpthroughthelookingglass,andwhatwefoundthere》一文中显示hp实验室、耶鲁大学以及麻省理工大学共同进行了一项实验，对oltp型数据库进行了一次剖析。文中指出通过实验分解发现了4个影响数据库性能的最大组件，分别是：日志、lock、latch以及缓存管理。他们选取了一个典型的关系型数据库shore并以标准的tpcc业务模型进行实验(测试tpcc下的新增订单事务，统计的是运行该事务的cpu指令数)，记录逐一移除或优化上述特征对应的性能变化情况。最终的测试数据指出单cpu情况下，移除上述所有特征可以产生两个数量级以上的吞吐量提升。其中花费在lock和latch上的cpu指令数分别占总cpu指令数的16.3％和14.2％。

根据上述分析花费在lock和latch上的cpu指令总数占总cpu指令数的30.5％，这个测试数据还是在单cpu情况下的测试结果，当cpu的个数增加时，由于多cpu竞争共享资源将大幅增加lock和latch的cpu指令占总cpu指令数的比例。图2描述的是本发明实施例中的分片式多线程并发控制模型，本发明所述分片式多线程并发控制模型旨在消除上述lock和latch带来的代价。

本发明实施例中的方案主要针对高并发情况下的并发控制方法进行改进，旨在提升多核系统下oltp业务的吞吐量同时降低业务响应时延，并且能够随cpu资源的增加实现性能成线性扩展。

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例1

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图3是本发明实施例的一种数据库的处理方法的移动终端的硬件结构框图。如图3所示，移动终端30可以包括一个或多个(图3中仅示出一个)处理器302(处理器302可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)和用于存储数据的存储器304，可选地，上述移动终端还可以包括用于通信功能的传输设备306以及输入输出设备308。本领域普通技术人员可以理解，图3所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端30还可包括比图3中所示更多或者更少的组件，或者具有与图3所示不同的配置。

存储器304可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的一种数据库的处理方法对应的计算机程序，处理器302通过运行存储在存储器304内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器304可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器304可进一步包括相对于处理器302远程设置的存储器，这些远程存储器可以通过网络连接至移动终端30。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置306用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端30的通信供应商提供的无线网络。在一个实例中，传输装置306包括一个网络适配器(networkinterfacecontroller，简称为nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置306可以为射频(radiofrequency，简称为rf)模块，其用于通过无线方式与互联网进行通讯。

在本实施例中提供了一种可以运行于上述移动终端的一种数据库的处理方法，图4是根据本发明实施例的一种数据库的处理方法的流程图，如图4所示，该流程包括如下步骤：

步骤s402，接收用于请求对数据库中的预定数据进行处理的处理请求；

步骤s404，确定用于对所述预定数据进行处理的预定中央处理器cpu，其中，所述数据库中包括两个以上数据分片，不同的数据分片中包括的数据不同，且不同的数据分片对应的用于对数据分片中的数据进行处理的处理cpu不同；

步骤s406，指示所述预定cpu按照所述处理请求对所述预定数据进行处理。

在上述实施例中，数据库可以是oltp数据库，数据库中的数据被进行了分片，分片原则是消除各分片数据之间的依赖。

通过上述步骤，由于数据库中包括多个数据分片，不同数据分片分别对应不同的处理cpu，由与其相对应的处理cpu处理该数据分片中的数据，且，该对应处理cpu独立负责处理对应分片上的数据的所有操作访问请求，且对应处理cpu可以只负责对应的分片数据。避免了传统的多线程并发控制中，由于多核系统中的多个cpu共同访问数据库中的数据而带来当cpu数目的增多时，共同访问数据库中的数据的逻辑结构成倍上升，并由此增加了更多的操作成本。可以解决相关技术中存在的在数据库的多线程并发控制中随着cpu数目的增多，访问冲突越来越严重，从而造成大量的cpu资源浪费，增加事务处理的时延，进而降低业务处理能力的问题，进而达到了降低数据库的多线程并发控制的复杂度，降低数据库事务的请求响应时延，提高了业务处理能力的效果。

在一个可选实施例中，在确定用于对上述预定数据进行处理的预定cpu之前，所述方法还包括：获取数据分片与处理cpu的对应关系；确定用于对所述预定数据进行处理的预定cpu包括：确定所述预定数据所属的数据分片；根据所述对应关系确定与所述预定数据所属的数据分片对应的所述预定cpu。在本实施例中，为每个用户数据分片分配一个对应的处理cpu，该cpu独立处理该分片上的用户数据的所有操作访问请求，且该cpu只负责该分片数据。通过这种架构，将各cpu与用户数据分片进行对应，使得每个cpu独占式访问对应用户数据的并发控制方法，可以让各个cpu并行的处理各对应分片的用户请求，由于用户数据间无依赖关系，对单个用户数据分片的访问只有一个cpu处理，因此可以移除对用户数据进行加锁的控制。进一步，由于不需要对用户数据进行加锁控制，各个cpu之间也不再有交集，因此也无需进行共享数据结构的维护，从而彻底去除了lock和latch。

在一个可选实施例中，获取数据分片与处理cpu的对应关系包括第一获取方式或第二获取方式，其中，所述第一获取方式包括：对所述数据库中的数据进行分片，其中，分片后的各数据分片之间无依赖关系；为各数据分片分别分配一个对应的处理cpu；建立数据分片与分配的处理cpu之间的对应关系；所述第二获取方式包括：接收来自管理cpu的所述对应关系。在本实施例中，可以由管理cpu执行第一种获取方式，由应用app执行第二种获取方式。针对用户数据的分片方法和原则，图5给出了示例说明，具体描述如下：首先，分片的总体原则是去除分片间的依赖关系，各分片之间不存在访问依赖性，这需要结合业务逻辑考虑。第二，对用户数据按照分发键进行分片，分发键可以是表中的一列或者多列，或者多列上的表达式以及函数和自定义函数。第三，分片规则可以是一级分片，也可以是多级分片，如图5所示是一种二级分片方式，多级分片使得分片处理单元可根据实际负载情况动态的扩展和收缩。当图中用户分片1的数据量越来越大或者热点数据过多时，可以扩展分片处理cpun+1并将用户分片1的数据迁移一部分组成用户分片n+1，从而实现处理能力的动态扩展。第四，对于字典类数据(频繁被访问但很少更新的数据，通常这类数据量也比较小，比如部门信息)可以不进行分片，在每个处理单元内均进行全量保存，从而打破数据依赖。进一步，当同一个用户事务或操作涉及多个分片时，分片策略可以根据统计情况将频繁出现在同一事务或操作内的多个二级分片调度到同一个处理单元内，从而降低上层中间件或者应用app的实现复杂度，并进一步提升性能。

在一个可选实施例中，在建立数据分片与分配的处理cpu之间的对应关系之后，还包括：在预定条件下执行以下操作至少之一，并基于执行后的操作重新建立数据分片与分配的处理cpu之间的对应关系：对所述数据库中的数据进行重新分片，并重新对分片后的各数据分片配置对应的处理cpu；为所述数据库中的数据分片重新分配对应的处理cpu；其中，重新分配的处理cpu中包括原有的处理cpu和/或新增加的处理cpu，所述预定条件包括以下至少之一：根据收集的各处理cpu的负载信息以及各数据分片中数据的处理信息确定存在处理cpu负载不均衡，接收到重新分配指令。在本实施例中，当检测到处理cpu的负载不均衡时，也就是处理cup处理的分片数据分配不均衡时(例如，某些处理cpu处理的数据过多，有些处理cpu处理的分片数据过少)，可以对数据进行重新分片，然后为重新分片后的数据分片重新分配处理cpu，重新分配的处理cpu中可以包含原有的处理cpu也可以增加新的处理cpu。另外重分布也可能是人为发起的(如，dba(databaseadministrator，数据库管理员，简称dba))，例如，当数据库中的数据结构发生改变，或者由于所处理的业务改变，需要对数据进行重新的分片，此时由dba发起重新分配指令，对数据库中的数据进行重新分片，并重新分配处理cpu。

在一个可选实施例中，对上述数据库中的数据进行重新分片后的数据分片总数小于重新分片之前的数据分片总数；或者，对上述数据库中的数据进行重新分片后的数据分片总数等于重新分片之前的数据分片总数；或者，对上述数据库中的数据进行重新分片后的数据分片总数大于重新分片之前的数据分片总数。在本实施例中，当用户数据分片的数据量减少，或者用户数据分片的访问热点减少时，可以动态调整重新分片的数据分片总数小于重新分片之前的分片总数；同理，当用户数据分片的数据量增多，或者用户数据分片的访问热点增多时，可以动态调整重新分片的数据分片总数大于重新分片之前的分片总数。另外，当数据分片内部数据发生变化或者访问热点发生变化时，如数据分片1的内部数据访问量增多，而数据分片2的内部数据访问量减少，在用户数据(对应于上述的数据库)分片总数量不变的情况下，调整数据分片1和数据分片2内部的数据，如，将数据分片1中的一部分数据调整到数据分片2中，这样可以在数据分片总数不变的情况下，动态调整各个数据分片中的数据量。

在一个可选实施例中，当获取数据分片与处理cpu的对应关系包括所述第一获取方式时，接收用于请求对数据库中的预定数据进行处理的处理请求包括：接收来自应用app的所述处理请求。在本实施例中，各分片处理cpu执行的任务基本上100％都是app的实际用户请求，而不是系统调度、锁控制、缓存控制等不直接对应于用户请求的实际工作。从而大大降低了总的cpu指令数，提升了cpu的有效利用率。

在一个可选实施例中，指示上述预定cpu按照所述处理请求对上述预定数据进行处理包括：将所述处理请求放置于所述预定cpu对应的请求队列中，以指示所述预定cpu从所述请求队列中获取所述处理请求，并按照所述处理请求对所述预定数据进行处理。在本实施例中，图6所示为一个分片处理单元内部的工作原理，具体描述如下：首先将用户请求放在一个队列中，然后执行一个循环，不断地从队列中取请求并执行。显而易见的是此方法可以让单个处理cpu充分运转起来，当然有几纳秒的时间周期用于从命令队列中取命令和将响应放入响应队列中。在数据库应用中，用户的请求就是sql(stucturedquerylanguage，简称sql，结构化查询语言)执行计划、分布式分片上的执行计划、或者存储过程的调用等等，循环就对应于单个用户分片上的请求队列。

在一个可选实施例中，在接收用于请求对数据库中的预定数据进行处理的处理请求之后，所述方法还包括：在确定所述数据库中不存在所述预定数据，或者不存在对所述预定数据进行处理的处理cpu时，返回错误响应。

下面结合实施例对数据库的分片式并发处理方法进行整体说明：

图7描述的是本发明所述分片式并发处理方法，包括：

首先，针对业务应用场景对用户数据进行库表结构设计，各库表字段定义过程中需要根据结合用户数据本身特征以及具体的业务对用户数据的访问场景定义好分片规则。

第二，根据定义好的分片规则，用户数据被分为不同的多个数据分片，用户数据分片与分片之间去除依赖关系，用户数据分片数量需要考虑可用cpu的个数情况，确保可用cpu个数可以匹配实际用户数据分片数。

第三，针对每个数据分片绑定一个对应的处理cpu，该cpu处理对应用户分片数据上的所有读写请求，且每个cpu仅处理一个对应的用户分片。

下面结合具体实施例对本发明进行说明：

具体实施例1

如图8所示，提供了第一种分片式并发处理实例，包括如下设备：

数据库处理服务器，其中的cpu分为两类，管理/接入cpu(对应于上述的管理cpu)和分片处理单元cpu(对应于上述的处理cpu)。

管理/接入cpu负责维护用户数据(对应于上述的数据库)分片、以及分片与对应分片处理单元cpu的关系等元数据信息管理，同时接受app用户请求，并将各请求路由给对应的分片处理cpu，收集各处理单元cpu的响应并返回给app。

分片处理单元cpu，负责接收用户请求，处理用户请求完成对所负责用户分片数据的读写和计算。

图9给出了第一种分片式并发处理框架下的业务流程，包括如下步骤：

第一步(对应于图9中步骤92)，app发送用户请求至数据库处理服务器，请求中携带分片信息。

第二步(对应于图9中步骤94)，管理/接入cpu接收用户请求，对请求消息进行解析，从中获取分发键字段信息。

第三步(对应于图9中步骤96)，管理/接入cpu根据请求中的分发键信息以及元数据分片规则信息匹配对应的分片处理单元cpu，匹配成功，进入第四步。匹配失败，管理/接入cpu直接返回错误响应给app(对应于图9中步骤914)，流程结束。

第四步(对应图9中步骤910)，分片处理单元cpu依次从自己的用户请求队列里面获取请求，进行处理，处理完毕将响应放置于该cpu对应的响应队列中，继续取下一个请求进行处理。

第五步(对应于图9中步骤912)，管理/接入cpu获取各分片处理单元cpu的响应队列中的响应，回复给app。流程结束。

具体实施例2

如图10所示，提供了第二种分片式并发处理实例，包括如下设备：

数据库处理服务器，其中的cpu同样分为两类，元数据管理cpu(对应于上述的管理cpu)和分片处理单元cpu(对应于上述的处理cpu)。管理cpu负责维护用户数据(对应于上述的数据库)分片、用户分片与对应分片处理单元cpu的关系等元数据信息管理，同时接受app的元数据用户请求，并将所维护的元数据信息返回给app。分片处理单元cpu，负责接收app的实际用户数据操作请求，完成对所负责用户分片数据的读写和计算，返回响应给app。

图11给出了第二种分片式并发处理框架下的app分片元数据信息获取流程，包括如下步骤：

第一步(对应于图11中步骤112)，app启动模式，app发送分片信息获取请求至数据库处理服务器。

第二步(对应于图11中步骤114)，管理cpu接收app的分片信息获取请求，回复分片及对应处理单元信息给app。

第三步(对应于图11中步骤116)，app接收管理cpu返回的用户数据(对应于上述的数据库)分片及对应处理单元信息加载至缓存，之后进入工作模式。

图12给出了第二种分片式并发处理框架下的业务流程，包括如下步骤：

第一步(对应于图12中步骤122)，app应用程序接收客户端输入请求。

第二步(对应于图12中步骤124)，app读取本地缓存中的分片元数据信息获取本请求对应的分片处理单元cpu信息。若成功，进入第三步；若失败，直接返回客户端失败响应。

第三步(对应于图12中步骤126)，app调用数据库驱动组装数据库请求消息，发送至对应的分片处理单元cpu请求队列。

第四步(对应于图12中步骤128)，各分片处理单元cpu依次从自己的用户请求队列里面获取请求，进行处理，处理完毕将响应放置于该cpu对应的响应队列中，继续取下一个请求进行处理。

第五步(对应于图12中步骤1210)，app获取对应分片处理单元cpu的响应队列中的响应。

第六步(对应于图12中步骤1211)，app响应返回给用户，流程结束。

相比第一种分片式并发处理框架，第二种框架在处理真实的业务请求过程中减少了一级接入转发，更加高效，但缺点是app层驱动更加厚重，需要增加对分片元数据的管理和维护，灵活性有一定影响。

具体实施例3

在本实施例中提供了一种可动态伸缩的分片式并发处理实例：如图13所示，提供了一种cpu处理单元可动态伸缩的分片式并发处理框架实例，包括如下设备：

数据库处理服务器，其cpu包括但不限于如下四类：元数据分片管理cpu(对应于上述的管理cpu)、分片处理单元cpu(对应于上述的处理cpu)、监控管理类cpu以及空间cpu。元数据分片管理cpu负责维护用户数据(对应于上述的数据库)分片、用户分片与对应分片处理单元cpu的关系等元数据信息管理。元数据分片管理cpu，一方面接收app的元数据用户请求，并将所维护的元数据信息返回给app；另一方面接收监控管理cpu的监控报告，根据监控结果实现对分片规则的动态调整以及分片处理cpu的弹性伸缩，从而实现数据库处理能力的动态调整。分片处理单元cpu，负责接收app的实际用户数据操作请求，完成对所负责用户分片数据的读写和计算，返回响应给app。监控管理cpu，定期收集各分片处理单元运行负载情况以及各用户数据分片的访问情况，一方面提供给分片管理cpu进行数据库处理能力的动态伸缩，另一方面用于监控运维及性能报表。空闲cpu，预留分片处理资源，从而实现弹性伸缩。

具体实施例4

如图14所示，提供了分布式环境下的一种分片式并发处理框架实例，其中：

第一，分布式环境由数据库处理服务器和管理/接入中间件(对应于上述的管理cpu)组成。

第二，管理/接入中间件负责整个分布式集群下的用户分片元数据管理，同时负责接收各app的用户请求，根据分片信息路由至对应的处理服务器的对应分片处理单元。

第三，各处理服务器由一组分片处理单元cpu(对应于上述的处理cpu)组成，各分片处理单元cpu维护对应的用户分片数据信息。进一步，当用户数据分片数据量发生变化时，或者用户数据分片的访问热点发生变化时，一方面可以在处理服务器内部进行分片处理单元间的调度和扩缩容，另一方面可以在处理服务器之间进行分片处理单元的调度和扩缩容。更进一步，管理/接入中间件可以根据实际业务量情况选择集中式或分布式部署架构。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

在本实施例中还提供了一种数据库的处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图15是根据本发明实施例的数据库的处理装置的结构框图，如图15所示，该装置包括如下模块：接收模块152，用于接收用于请求对数据库中的预定数据进行处理的处理请求；确定模块154，连接至上述接收模块152，用于确定用于对所述预定数据进行处理的预定中央处理器cpu；指示模块156，连接至上述确定模块154，用于指示所述预定cpu按照所述处理请求对所述预定数据进行处理。

在一个可选实施例中，上述装置还包括：获取模块，用于在确定用于对上述预定数据进行处理的预定cpu之前，获取数据分片与处理cpu的对应关系；上述确定模块154包括：第一确定单元，用于确定上述预定数据所属的数据分片；第二确定单元，用于根据上述对应关系确定与该预定数据所属的数据分片对应的所述预定cpu。

在一个可选实施例中，上述获取模块可以通过第一获取方式或第二获取方式获取数据分片与处理cpu的对应关系，其中，所述第一获取方式包括：对所述数据库中的数据进行分片，其中，分片后的各数据分片之间无依赖关系；为各数据分片分别分配一个对应的处理cpu；建立数据分片与分配的处理cpu之间的对应关系；所述第二获取方式包括：接收来自管理cpu的所述对应关系。

在一个可选实施例中，上述装置还用于：在建立数据分片与分配的处理cpu之间的对应关系之后，在预定条件下执行以下操作至少之一，并基于执行后的操作重新建立数据分片与分配的处理cpu之间的对应关系：对所述数据库中的数据进行重新分片，并重新对分片后的各数据分片配置对应的处理cpu；为所述数据库中的数据分片重新分配对应的处理cpu；其中，重新分配的处理cpu中包括原有的处理cpu和/或新增加的处理cpu，所述预定条件包括以下至少之一：根据收集的各处理cpu的负载信息以及各数据分片中数据的处理信息确定存在处理cpu负载不均衡，接收到重新分配指令。

在一个可选实施例中，对上述数据库中的数据进行重新分片后的数据分片总数小于重新分片之前的数据分片总数；或者，对上述数据库中的数据进行重新分片后的数据分片总数等于重新分片之前的数据分片总数；或者，对上述数据库中的数据进行重新分片后的数据分片总数大于重新分片之前的数据分片总数。

在一个可选实施例中，当获取数据分片与处理cpu的对应关系包括所述第一获取方式时，上述接收模块152可以通过如下方式接收用于请求对数据库中的预定数据进行处理的处理请求：接收来自应用app的所述处理请求。

在一个可选实施例中，上述指示模块156用于通过如下方式指示所述预定cpu按照所述处理请求对所述预定数据进行处理：将上述处理请求放置于所述预定cpu对应的请求队列中，以指示上述预定cpu从所述请求队列中获取所述处理请求，并按照该处理请求对所述预定数据进行处理。

在一个可选实施例中，上述装置还用于：在接收用于请求对数据库中的预定数据进行处理的处理请求之后，在确定所述数据库中不存在所述预定数据，或者不存在对所述预定数据进行处理的处理cpu时，返回错误响应。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例3

在本实施例中提供了一种数据库的处理系统，该系统包括：处理器，两个以上处理cpu，数据库，其中，所述处理器用于执行以下处理：接收用于请求对所述数据库中的预定数据进行处理的处理请求；从所述两个以上处理cpu中确定用于对所述预定数据进行处理的预定中央处理器cpu；指示所述预定cpu按照所述处理请求对所述预定数据进行处理；所述两个以上处理cpu用于根据来自所述处理器的请求对所述数据库中的数据进行处理。

在一个可选实施例中，上述两个以上处理cpu被分为两个以上处理服务器组，其中，每个处理服务器组具备组内的处理cpu扩缩容以及在组内的处理cpu间进行业务调度的能力，且不同的处理服务器组之间具备业务调度的能力。

在一个可选实施例中，上述处理器还用于在确定用于对上述预定数据进行处理的预定cpu之前，获取数据分片与处理cpu的对应关系；上述处理器可以通过如下方式确定用于对上述预定数据进行处理的预定cpu：确定上述预定数据所属的数据分片；根据上述对应关系确定与上述预定数据所属的数据分片对应的所述预定cpu。

在一个可选实施例中，上述处理器可以通过第一获取方式或第二获取方式来获取数据分片与处理cpu的对应关系，其中，所述第一获取方式包括：对所述数据库中的数据进行分片，其中，分片后的各数据分片之间无依赖关系；为各数据分片分别分配一个对应的处理cpu；建立数据分片与分配的处理cpu之间的对应关系；所述第二获取方式包括：接收来自管理cpu的所述对应关系。

在一个可选实施例中，上述处理器还用于：在建立数据分片与分配的处理cpu之间的对应关系之后，在预定条件下执行以下操作至少之一，并基于执行后的操作重新建立数据分片与分配的处理cpu之间的对应关系：对所述数据库中的数据进行重新分片，并重新对分片后的各数据分片配置对应的处理cpu；为所述数据库中的数据分片重新分配对应的处理cpu；其中，重新分配的处理cpu中包括原有的处理cpu和/或新增加的处理cpu，所述预定条件包括以下至少之一：根据收集的各处理cpu的负载信息以及各数据分片中数据的处理信息确定存在处理cpu负载不均衡，接收到重新分配指令。

在一个可选实施例中，对上述数据库中的数据进行重新分片后的数据分片总数小于重新分片之前的数据分片总数；或者，对上述数据库中的数据进行重新分片后的数据分片总数等于重新分片之前的数据分片总数；或者，对上述数据库中的数据进行重新分片后的数据分片总数大于重新分片之前的数据分片总数。

在一个可选实施例中，当获取数据分片与处理cpu的对应关系包括所述第一获取方式时，上述处理器可以通过如下方式接收用于请求对数据库中的预定数据进行处理的处理请求：接收来自应用app的所述处理请求。

在一个可选实施例中，上述处理器可以通过如下方式指示上述预定cpu按照上述处理请求对所述预定数据进行处理：将所述处理请求放置于所述预定cpu对应的请求队列中，以指示所述预定cpu从所述请求队列中获取所述处理请求，并按照该处理请求对所述预定数据进行处理。

在一个可选实施例中，上述处理器还用于：在接收用于请求对数据库中的预定数据进行处理的处理请求之后，在确定所述数据库中不存在所述预定数据，或者不存在对所述预定数据进行处理的处理cpu时，返回错误响应。

实施例4

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

s1，接收用于请求对数据库中的预定数据进行处理的处理请求；

s2，确定用于对所述预定数据进行处理的预定中央处理器cpu，其中，所述数据库中包括两个以上数据分片，不同的数据分片中包括的数据不同，且不同的数据分片对应的用于对数据分片中的数据进行处理的处理cpu不同；

s3，指示所述预定cpu按照所述处理请求对所述预定数据进行处理。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(read-onlymemory，简称为rom)、随机存取存储器(randomaccessmemory，简称为ram)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

s1，接收用于请求对数据库中的预定数据进行处理的处理请求；

s2，确定用于对所述预定数据进行处理的预定中央处理器cpu，其中，所述数据库中包括两个以上数据分片，不同的数据分片中包括的数据不同，且不同的数据分片对应的用于对数据分片中的数据进行处理的处理cpu不同；

s3，指示所述预定cpu按照所述处理请求对所述预定数据进行处理。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

下面对本发明中可能涉及到的相关技术术语进行说明：

oltp：on-linetransactionprocessing，联机事务处理过程，也称为面向交易的处理过程，其基本特征是前台并发地接收的大量用户请求可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。

acid：指数据库事务正确执行的四个基本要素的缩写。包含：原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)。一个支持事务(transaction)的数据库，必需要具有这四种特性，否则在事务过程(transactionprocessing)当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

lock：锁，传统数据库架构下，多线程并发访问数据库为了保证数据库的acid特性，而引入的对用户数据的控制对象。根据锁的粒度可分为表锁、行锁、列锁、间隙锁等，根据表的类型可分为共享锁、排他锁、意向锁等等。

mutex：互斥量，在编程中，引入了对象互斥量的概念，来保证共享数据操作的完整性。每个对象都对应于一个可称为"互斥量"的标记，这个标记用来保证在任一时刻，只能有一个线程访问或操作该对象。

latch：栓，功能类似于mutex，也是一种互斥方式，与mutex的区别在于更加轻量。

cpu内核：cpu是计算机的中央处理器，cpu内核是cpu中间的核心芯片，用来完成所有的计算、接受/存储命令、处理数据等，是数字处理核心。随着cpu的技术的发展，一颗物理cpu包含的内核数也越来越多，目前一颗物理cpu最多包括24个物理内核，在未来一个cpu的物理内核数还将不断的提升。目前大部分服务器都支持超线程技术，可以将一个cpu物理内核超线程为两个cpu内核，在操作系统中看到的cpu内核数为实际物理内核数的两倍。本发明所述cpu，如无特殊说明，即指cpu内核，也即为操作系统中识别到的cpu内核。

通过上述具体实施例可以看出，本发明让各cpu并发无干扰的执行用户指令，相比传统的并发控制方案，本发明去掉了对用户数据的锁访问控制、对共享数据结构的互斥控制过程以及上下文切换开销，cpu指令总数大幅降低，使cpu专注于处理用户的真实请求，从而充分发挥了每颗cpu的处理能力，从而达到如下技术效果：提升了整个系统的用户请求吞吐量。降低了数据库事务(例如，oltp事务)的请求响应时延。去除了lock、latch的维护，大大简化了数据库的处理逻辑，降低了实现复杂度。大大降低了实现数据库完整acid特性的复杂度。大幅提升了系统的处理性能，并且能实现随着服务器cpu数的增加，整个系统的处理能力成线性扩展。提升了用户的投资费效比，即单位投资可获得更高的处理能力。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。