从库读取方法、相关装置和设备与流程

本发明涉及计算机领域，尤其涉及从库读取方法、相关装置和设备。

背景技术：

数据库(database)是按照数据结构来组织、存储和管理数据的仓库；随着信息技术和市场的发展，特别是二十世纪九十年代以后，数据管理不再仅仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。数据库有很多种类型，从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方面得到了广泛的应用。

由于考虑到数据的容灾、负载均衡以及数据集中和分发等等，现有技术中的数据库一般都建立主从数据库，即主库和从库。当前，在主库从库进行数据同步的过程中，为了避免对从库出现数据脏读等因素，往往对从库加全局锁，以控制这期间内从库不可读。

然而，由于全局锁的力度太大，导致在主库从库进行数据同步的过程中如果从库收到读请求的话，会阻塞直到数据同步结束，导致请求的延时明显升高，每秒查询率(querypersecond，qps)下降，从库上会出现很多慢日志，严重的话甚至影响业务的正常服务。

技术实现要素：

本发明实施例所要解决的技术问题在于，提供一种从库读取方法、一种从库读取装置、一种从库读取设备、以及一种计算机可读存储介质，解决由于全局锁的力度太大导致请求的延时明显升高，qps下降，从库上会出现很多慢日志的技术问题。

为了解决上述技术问题，本发明实施例第一方面公开了一种从库读取方法，包括：

启动主库从库进行数据同步；

当允许在主库从库进行数据同步时读取从库的情况下，接收对所述从库的读请求；

针对所述读请求，根据记录的底层存储引擎中事务的状态来读取所述从库，并输出读取结果。

本发明实施例第二方面公开了一种从库读取装置，包括执行如上述第一方面的方法的单元。

本发明实施例第三方面公开了一种从库读取设备，包括处理器、输入设备、输出设备和存储器，所述处理器、输入设备、输出设备和存储器相互连接，其中，所述存储器用于存储应用程序代码，所述处理器被配置用于调用所述程序代码，执行如上述第一方面所述的方法。

本发明实施例第四方面公开了一种计算机可读存储介质，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如上述第一方面的方法。

实施本发明实施例，启动主库从库进行数据同步时，通过当允许在主库从库进行数据同步时读取从库的情况下，接收对该从库的读请求；针对该读请求，根据记录的底层存储引擎中事务的状态来读取该从库，并输出读取结果，即在主库从库进行数据同步时去掉了全局锁，解决由于全局锁的力度太大导致请求的延时明显升高，qps下降，从库上会出现很多慢日志的技术问题，实现了在主从库数据同步的压力很大的情况下，不会对从库读造成影响，提高了qps，保证了业务的正常运行，同时也避免了对从库出现数据脏读。

附图说明

为了说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1是本发明实施例提供的主库从库进行数据同步的框架示意图；

图2是本发明实施例提供的从库读取方法的流程示意图；

图3是本发明实施例提供的记录事务的原理示意图；

图4是本发明提供的从库读取方法的另一种实施例的流程示意图；

图5是本发明实施例提供的配置从库snapshot读的原理示意图；

图6是本发明实施例提供的两次从库读取的测试结果示意图；

图7是本发明实施例提供的从库读取装置的结构示意图；

图8是本发明提供的从库读取装置的另一实施例的结构示意图；

图9是本发明实施例提供的从库读取设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。

还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。

还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

具体实现中，本发明实施例中描述的终端或设备或数据库服务器包括但不限于诸如台式计算机、膝上型计算机或平板计算机之类的设备。

为了更好的理解本发明实施例提供的一种从库读取方法、从库读取装置以及从库读取设备，下面先对本发明实施例适用的从库读取的框架进行描述。参阅图1，图1是本发明实施例提供的主库从库进行数据同步的框架示意图。如图1所示：

图1是以cmongo为例子进行说明，cmongo即cloudmongodbservice，是基于mongodb(基于分布式文件存储的数据库)打造的高性能nosql数据库管理平台。mongodb的replicaset(由一系列mongod实例(进程)组成的复制组)可以包含一个主库(primary)和若干个从库(secondary)，数据通过primary写入，primary与secondary之间通过操作日志(oplog)来同步数据，该oplog具体可以指大小固定的集合，存储对数据库的修改操作，用于主从同步。primary上的写操作完成后，会向local.oplog.rs特殊集合写入一条oplog，secondary负责从复制源replication(一般为primary，但是mongo也支持链式复制，即secondary也可以作为复制源)拉取oplog，在secondary上回放，从而保持主从之间数据的一致性。其中，图1是一个典型的replicaset，包括1个primary和2个secondary。

本实施例不限定基于mongodb的数据库管理平台，只要涉及到在主库从库进行数据同步的过程中，为对从库加全局锁的数据库管理平台，都可以应用本发明实施例的从库读取方法，通过在主库从库进行数据同步时，对从库的读请求根据预先记录的底层存储引擎中事务的状态来读取从库，并输出读取结果，以解决由于全局锁的力度太大导致请求的延时明显升高，qps下降，从库上会出现很多慢日志的技术问题。

下面结合图2示出的本发明实施例提供的从库读取方法的流程示意图，可以包括以下步骤：

步骤s200：启动主库从库进行数据同步；

具体地，当主库从库需要进行数据同步的时候，启动主库从库进行数据同步。

步骤s202：当允许在主库从库进行数据同步时读取从库的情况下，接收对该从库的读请求；

具体地，在启动主库从库进行数据同步后，可以判断是否允许在主库从库进行数据同步时读取从库。该判断方式可以为查看配置信息；该配置信息用于指示是否允许在主库从库进行数据同步时读取从库；在查看出该配置信息为第一标识的情况下，则允许在主库从库进行数据同步时读取从库，在查看出该配置信息为第二标识的情况下，则不允许在主库从库进行数据同步时读取从库。例如，第一标识可以为1，第二标识可以为0，那么当查看配置信息为1时，则指示允许在主库从库进行数据同步时读取从库，当查看配置信息为0时，则指示不允许在主库从库进行数据同步时读取从库。

在其中一种实施方式中，查看配置信息可以具体为查询预设的某个配置项的状态，例如配置项为1表明允许在主库从库进行数据同步时读取从库，配置项为0表明不允许在主库从库进行数据同步时读取从库，那么在查询到该预设的配置项为1时，则判断出允许在主库从库进行数据同步时读取从库，否则判断出不允许在主库从库进行数据同步时读取从库。

那么，当允许在主库从库进行数据同步时读取从库的情况下，针对接收到的对从库的读请求，可以执行步骤s204。

需要说明的是，本发明的其中一个实施例，技术人员可以预先分析数据库的数据读写量，来设置配置项的值；例如分析预测出数据库在进行主库从库数据同步时，业务写入压力会非常大，那么可以设置允许在主库从库进行数据同步时读取从库。

步骤s204：针对该读请求，根据记录的底层存储引擎中事务的状态来读取该从库，并输出读取结果。

具体地，本发明实施例会预先记录底层存储引擎中事务的状态，例如图3示出的本发明实施例提供的记录事务的原理示意图，假设记录的时刻为t时刻，图3中的事务区间0至t1为已经提交的事务区间，事务区间t1至t5为正在执行的事务区间，事务区间t5以后的为将要执行的事务区间，那么在t时刻记录的底层存储引擎中事务的状态只能是该t时刻之前的事务区间的事务状态，例如包括已经提交的事务的状态，即图3中已提交的事务区间0至t1的状态，以及事务区间t1至t5中已提交(commited)的事务区间t2的状态。

进一步地，在其中一个实施例方式中，可以在申请主库从库进行数据同步结束时，记录当前时刻的底层存储引擎中事务的状态，从而可以保证记录事务状态的过程中不会有新的写入。并且，在查找到所述当前时刻之前存在记录的底层存储引擎中事务的状态的情况下，将记录的当前时刻的底层存储引擎中事务的状态覆盖所述当前时刻之前的底层存储引擎中事务的状态，以更好地管理该记录的事务的状态。

本发明实施例通过根据记录的底层存储引擎中事务的状态来读取该从库，实现了在主库从库进行数据同步时可对从库进行读取，解决由于全局锁的力度太大导致请求的延时明显升高，qps下降，从库上会出现很多慢日志的技术问题，实现了在主从库数据同步的压力很大的情况下，不会对从库读造成影响，提高了qps，保证了业务的正常运行；由于该记录的底层存储引擎中事务的状态按照顺序来记录的，因此可以保证从库读的时候不会遗漏部分数据，从而避免了对从库读时出现脏读。

进一步的，下面以基于mongodb的数据库管理平台来举例说明，如图4示出的本发明提供的从库读取方法的另一种实施例的流程示意图，可以包括以下步骤：

步骤s400：判断从库是否拉取oplog；

具体地，在mongodb中，当判断出从库secondary从复制源拉取oplog后，表明secondary即将开始并行回放oplog，以进行主库从库的数据同步，然后执行步骤s402。若判断从库没有拉取oplog，则执行步骤s410。

步骤s402：判断是否开启了从库快照snapshot读；

具体地，技术人员在建立数据库时，可以预先分析数据库的数据读写量，设置是否开启从库snapshot读。例如可以如图5示出的本发明实施例提供的配置从库snapshot读的原理示意图，可以将这个功能做成可配置，例如在mongodb的启动配置文件中新加入了一个配置信息(即配置项)snapshotread，用来表示是否开启从库snapshot读，其中第一标识true表示开启，第二标识false或者默认为不开启。那么可以通过读取分析该配置项snapshotread的内容，来判断是否开启了从库snapshot读，若判断开启了，则执行步骤s404，若判断没有开启，则执行步骤s406。

其中，本发明实施例中的底层存储引擎为支持snapshot功能的引擎，例如mongodb中的底层存储引擎为wiredtiger(简称wt)；snapshot是wt实现事务的基础，就是事务开始或者进行操作之前对整个wt引擎内部正在执行或者将要执行的事务进行一次快照，保存当时整个引擎所有事务的状态，确定哪些事务是对自己见的，哪些事务都自己是不可见。也就是说，是一系列事务id区间；基于wt，一个snapshot可以理解为是对数据库某个点的状态。例如图3示出的本发明实施例提供的记录事务的原理示意图，在t时刻进行snapshot，那么图3中已提交的事务区间0至t1的状态，以及事务区间t1至t5中已提交(commited)的事务区间t2的状态，是可见的，其他事物区间不可见。

步骤s404：从库回放oplog，并创建snapshot；

具体地，对于支持snapshot功能的引擎，本发明实施例可以在从库每次申请oplog(applyoplog)结束的时候，去创建snapshot，从而保证在创建的过程中不会有新的写入。

进一步地，当写入很多的情况下，applyoplog会非常频繁，在其中的一个实施方式中，可以在申请主库从库进行数据同步结束时(即例如在从库每次applyoplog结束的时候时)，并在查找到该当前时刻之前存在记录的底层存储引擎中事务的状态的情况下，判断记录时间间隔是否大于阈值；其中该记录时间间隔包括所述当前时刻之前底层存储引擎中事务的状态的记录时刻到所述当前时刻的时间间隔；

当判断大于阈值时，则记录当前时刻的底层存储引擎中事务的状态；或者，当判断小于阈值时，该根据记录的底层存储引擎中事务的状态来读取该从库包括根据该当前时刻之前记录的底层存储引擎中事务的状态来读取该从库。

也就是说，例如阈值为1秒，那么若当前时刻之前的0.2秒存在记录的底层存储引擎中事务的状态，即时间间隔为0.2秒，小于阈值1秒，则可以将当前时刻之前的0.2秒存在记录的底层存储引擎中事务的状态作为当前时刻的底层存储引擎中事务的状态，即根据该将当前时刻之前的0.2秒存在记录的底层存储引擎中事务的状态来读取从库。若当前时刻之前的1.2秒存在记录的底层存储引擎中事务的状态，即时间间隔为1.2秒，大于阈值1秒，则可以记录当前时刻的底层存储引擎中事务的状态，并可以将记录的当前时刻的底层存储引擎中事务的状态覆盖所述当前时刻之前的1.2秒记录的底层存储引擎中事务的状态。

步骤s406：对从库加全局锁，从库回放oplog；

具体地，当没有开启从库快照snapshot读，那么将对对从库加全局锁，以阻塞这期间的所有读写，然后从库回放oplog，直到步骤s410。

步骤s408：接收对从库的读请求，并根据创建的snapshot来读取该从库，并输出读取结果；

具体地，在读请求包括外部读的请求的情况下，可以在外部读通过查询操作(op_query)或续查操作(op_getmore)的方式来查询请求的情况下，将从库读修改为从库snapshot读。由于mongo协议的特殊性，op_query中根据ns又分为命令(command)和查询(query)两种，对于这些读请求入口，从库读都需要配置成从库snapshot读(即从snapshot中读)。

在读请求包括内部读的请求的情况下，若设置了读优先级(readconcern)为读大多数(readmajority)时，将从库读修改为从库snapshot读。在mongo中，如果设置了readconcern为readmajority的话，mongo会开启一个后台线程，对已经同步到大多数节点的oplog做一个snapshot，来实现readmajority。而从库去读自己的oplog并不是通过命令的形式，而是调用内部的接口，所以为了保证从库在读取oplog时数据的一致性，也要改成从库snapshot读(即从snapshot中读)。

本发明实施例中的从库snapshot读即根据记录的对数据库某个点的所有事务的状态来进行从库读取。

步骤s410：从库回放oplog结束。

针对本发明实施例的从库读取方法的技术效果，进行了测试，以10g的wt缓存空间(cachesize)为例，测试从库读的延时和qps。如图6示出的本发明实施例提供的两次从库读取的测试结果示意图。原生mongo即为现有技术的从库读取的方式，snapshot版本即为采用本发明实施例的从库读取的方式，其中，两次测试的条件都相同，包括主库的写压力相同，并且压力足够大，模拟线上主库写入压力大，这样从库回放的写入也很高。每次测试的写入数据为5千万条，数据量大于wtcachesize。另外，在测试中不限制cpu。从图6可以得出，snapshot版本在4种不同单条数据大小的情况下，从库读的延时都有明显的减小，延时的减小带来的是qps的提高。从延时数据可以看出，假设在cpu使用相同并且写入压力相同的情况下，qps也是有一个很大的提升。

本发明实施例通过根据记录的底层存储引擎中事务的状态来读取该从库，实现了在主库从库进行数据同步时可对从库进行读取，解决由于全局锁的力度太大导致请求的延时明显升高，qps下降，从库上会出现很多慢日志的技术问题，实现了在主从库数据同步的压力很大的情况下，不会对从库读造成影响，提高了qps，保证了业务的正常运行；由于该记录的底层存储引擎中事务的状态按照顺序来记录的，因此可以保证从库读的时候不会遗漏部分数据，从而避免了对从库读时出现脏读。

为了便于更好地实施本发明实施例的上述方案，本发明还对应提供了一种从库读取装置，下面结合附图来进行详细说明：

如图7示出的本发明实施例提供的从库读取装置的结构示意图，从库读取装置7可以包括：启动单元700、接收单元702、读取单元704和输出单元706，其中，

启动单元700，用于启动主库从库进行数据同步；

接收单元702，用于当允许在主库从库进行数据同步时读取从库的情况下，接收对该从库的读请求；

读取单元704，用于针对该读请求，根据记录的底层存储引擎中事务的状态来读取该从库；

输出单元706，用于并输出读取结果。

具体地，启动单元700可以具体包括拉取判断单元和启动子单元，该拉取判断单元用于输出单元706，该启动子单元用于在判断出从库拉取oplog的情况下，则启动该从库回放oplog。

该底层存储引擎支持snapshot功能；如图8示出的本发明提供的从库读取装置的另一实施例的结构示意图，从库读取装置7包括启动单元700、接收单元702、读取单元704和输出单元706外，还可以包括：开启判断单元708、全局锁单元7010、记录单元7012、记录判断单元7014和记录覆盖单元7016，其中，

开启判断单元708，用于在启动单元700启动主库从库进行数据同步后，查看配置信息；所述配置信息用于指示是否允许在主库从库进行数据同步时读取从库；在查看出所述配置信息为第一标识的情况下，则允许在主库从库进行数据同步时读取从库。

具体地，开启判断单元708可以具体用于在启动单元700启动主库从库进行数据同步后，判断是否开启了从库snapshot读；在判断出开启了从库snapshot读时，则允许在主库从库进行数据同步时读取从库。

全局锁单元7010，用于在开启判断单元708查看出所述配置信息为第二标识的情况下，即判断出没有开启从库snapshot读时，则在主库从库进行数据同步时，对该从库加全局锁。

读取单元704具体用于在该读请求包括外部读的请求的情况下，在外部读通过op_query或op_getmore的方式来查询请求的情况下，将从库读修改为从库snapshot读；以及在该读请求包括内部读的请求的情况下，在设置了readconcern为readmajority的情况下，将从库读修改为从库snapshot读。

记录单元7012，用于在申请主库从库进行数据同步结束时，记录当前时刻的底层存储引擎中事务的状态；

记录判断单元7014，用于在申请主库从库进行数据同步结束时，并在查找到该当前时刻之前存在记录的底层存储引擎中事务的状态的情况下，判断记录时间间隔是否大于阈值；其中该记录时间间隔包括该当前时刻之前底层存储引擎中事务的状态的记录时刻到该当前时刻的时间间隔；当判断大于阈值时，则记录当前时刻的底层存储引擎中事务的状态；或者，当判断小于阈值时，该根据记录的底层存储引擎中事务的状态来读取该从库包括根据该当前时刻之前记录的底层存储引擎中事务的状态来读取该从库。

记录覆盖单元7016，用于在查找到该当前时刻之前存在记录的底层存储引擎中事务的状态的情况下，将记录的当前时刻的底层存储引擎中事务的状态覆盖该当前时刻之前的底层存储引擎中事务的状态。

需要说明的是，本发明实施例中的从库读取装置70为上述图1至图6实施例中的终端或设备或数据库服务器，该从库读取装置70中各模块的功能可对应参考上述各方法实施例中图1至图6实施例的具体实现方式，这里不再赘述。

为了便于更好地实施本发明实施例的上述方案，本发明还对应提供了一种从库读取设备，下面结合附图来进行详细说明：

如图9示出的本发明实施例提供的从库读取设备的结构示意图，从库读取设备90可以包括括处理器901、输入单元902、输出单元903、存储器904和通信单元905，处理器901、输入单元902、输出单元903、存储器904和通信单元905可以通过总线906相互连接。存储器904可以是高速ram存储器，也可以是非易失性的存储器(non-volatilememory)，例如至少一个磁盘存储器，存储器704包括本发明实施例中的flash。存储器904可选的还可以是至少一个位于远离前述处理器901的存储系统。存储器904用于存储应用程序代码，可以包括操作系统、网络通信模块、用户接口模块以及从库读取程序，通信单元905用于与外部单元进行信息交互；处理器901被配置用于调用该程序代码，执行以下步骤：

启动主库从库进行数据同步；

当允许在主库从库进行数据同步时读取从库的情况下，通过输入单元902接收对该从库的读请求；

针对该读请求，根据记录的底层存储引擎中事务的状态来读取该从库，并通过输出单元903输出读取结果。

具体地，处理器901启动主库从库进行数据同步，可以包括：

判断从库是否拉取oplog；

在判断出从库拉取oplog的情况下，则启动该从库回放oplog。

具体地，当允许在主库从库进行数据同步时读取从库的情况下，处理器901通过输入单元902接收对该从库的读请求，可以包括：

查看配置信息；所述配置信息用于指示是否允许在主库从库进行数据同步时读取从库；

在查看出所述配置信息为第一标识的情况下，则允许在主库从库进行数据同步时读取从库。

具体地，处理器901查看配置信息之后，还可以执行：

在查看出所述配置信息为第二标识的情况下，则在主库从库进行数据同步时，对所述从库加全局锁。

具体地，该底层存储引擎支持snapshot功能；在该读请求包括外部读的请求的情况下，处理器901根据记录的底层存储引擎中事务的状态来读取该从库，可以包括：

在外部读通过op_query或op_getmore的方式来查询请求的情况下，将从库读修改为从库snapshot读。

具体地，在该读请求包括内部读的请求的情况下，处理器901根据记录的底层存储引擎中事务的状态来读取该从库，可以包括：

在设置了readconcern为readmajority的情况下，将从库读修改为从库snapshot读。

具体地，处理器901启动主库从库进行数据同步之前，还可以执行：

在申请主库从库进行数据同步结束时，记录当前时刻的底层存储引擎中事务的状态。

具体地，处理器901启动主库从库进行数据同步之前，还可以执行：

在申请主库从库进行数据同步结束时，并在查找到该当前时刻之前存在记录的底层存储引擎中事务的状态的情况下，判断记录时间间隔是否大于阈值；其中该记录时间间隔包括该当前时刻之前底层存储引擎中事务的状态的记录时刻到该当前时刻的时间间隔；

当判断大于阈值时，则记录当前时刻的底层存储引擎中事务的状态；或者，当判断小于阈值时，该根据记录的底层存储引擎中事务的状态来读取该从库包括根据该当前时刻之前记录的底层存储引擎中事务的状态来读取该从库。

具体地，处理器901记录当前时刻的底层存储引擎中事务的状态之后，还可以执行：

在查找到该当前时刻之前存在记录的底层存储引擎中事务的状态的情况下，将记录的当前时刻的底层存储引擎中事务的状态覆盖该当前时刻之前的底层存储引擎中事务的状态。

需要说明的是，本发明实施例中的从库读取设备90为上述图1至图6实施例中的终端或设备或数据库服务器，具体可对应参考上述各方法实施例中图1至图6实施例的具体实现方式，这里不再赘述。上述从库读取设备90的结构仅为本发明实施例提供的一个例子，并且，从库读取设备90可具有比示出的部件更多或更少的部件，可以组合两个或更多个部件，或者可具有部件的不同配置实现。

本发明实施例通过根据记录的底层存储引擎中事务的状态来读取该从库，实现了在主库从库进行数据同步时可对从库进行读取，解决由于全局锁的力度太大导致请求的延时明显升高，qps下降，从库上会出现很多慢日志的技术问题，实现了在主从库数据同步的压力很大的情况下，不会对从库读造成影响，提高了qps，保证了业务的正常运行；由于该记录的底层存储引擎中事务的状态按照顺序来记录的，因此可以保证从库读的时候不会遗漏部分数据，从而避免了对从库读时出现脏读。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(read-onlymemory，rom)或随机存储记忆体(randomaccessmemory，ram)等。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。