CN111125175B - 业务数据的查询方法和装置、存储介质、电子装置 - Google Patents

Abstract

本申请公开了一种业务数据的查询方法和装置、存储介质、电子装置。其中，该方法包括：获取第一业务系统中第一设备的第一请求，其中，第一请求用于请求获取目标业务数据，目标业务数据来源于第二业务系统的数据库；通过中间插件从缓存中查找处于数据有效期内的目标业务数据，其中，数据有效期是按照中间插件的指示为从业务系统的数据库中获取的业务数据配置的在缓存中保存的有效期；响应于第一请求，将从缓存中查找到的目标业务数据返回给第一设备。本申请解决了相关技术中数据库发生故障导致的无法提供数据服务的技术问题。

Description

业务数据的查询方法和装置、存储介质、电子装置

技术领域

本申请涉及互联网领域，具体而言，涉及一种业务数据的查询方法和装置、存储介质、电子装置。

背景技术

随着信息技术的发展，企业越来越重视信息系统的建设，信息系统可靠性是信息系统建中不可避免的问题。任何小的硬件、软件故障均有可能引起系统的网络故障，造成业务的中断或者数据的丢失，由此会造成人力、物力、财产损耗。

数据库是信息系统中非常重要的组成部分，随着互联网应用越来越多，业务量成倍的增长，随之而来就会产生几何级的数据量的增长，应用的压力也会越来越大，对数据库依赖度也越来越高，譬如对实时性响应要求很高的应用数据库，需要支持大规模的并发访问且能高效响应，以避免由于数据库故障造成客户端不能为用户提供服务这一情形的出现，可见，数据库严重制约了应用的服务性能和可用性，一旦数据库出现故障就会造成客户端的服务受到影响。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种业务数据的查询方法和装置、存储介质、电子装置，以至少解决相关技术中数据库发生故障导致的无法提供数据服务的技术问题。

根据本申请实施例的一个方面，提供了一种业务数据的查询方法，包括：获取第一业务系统中第一设备的第一请求，其中，第一请求用于请求获取目标业务数据，目标业务数据来源于第二业务系统的数据库；通过中间插件从缓存中查找处于数据有效期内的目标业务数据，其中，数据有效期是按照中间插件的指示为从业务系统的数据库中获取的业务数据配置的在缓存中保存的有效期；响应于第一请求，将从缓存中查找到的目标业务数据返回给第一设备。

根据本申请实施例的另一方面，还提供了一种业务数据的查询装置，包括：获取单元，用于获取第一业务系统中第一设备的第一请求，其中，第一请求用于请求获取目标业务数据，目标业务数据来源于第二业务系统的数据库；查找单元，用于通过中间插件从缓存中查找处于数据有效期内的目标业务数据，其中，数据有效期是按照中间插件的指示为从业务系统的数据库中获取的业务数据配置的在缓存中保存的有效期；返回单元，用于响应于第一请求，将从缓存中查找到的目标业务数据返回给第一设备。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

在相关技术中，一旦数据库发生故障或者与数据库之间的网络发生故障，就会导致数据源无法提供用户所需数据。在本申请的技术方案中，可以通过缓存来保存从数据库获取的热点数据，在数据库故障时利用缓存来提供数据服务，且缓存不用按照自己为数据配置的时间较短的缓存有效期来删除数据，而是由中间插件为数据配置较长的保存时间，通过为数据设置较长的有效期可以保证数据库故障的时候缓存长时间稳定地对外提供数据服务，可以解决相关技术中数据库发生故障导致的无法提供数据服务的技术问题，避免由于数据库故障后而缓存自身缓存时间较短造成数据到时被删除。

附图说明

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

图1是根据本申请实施例的业务数据的查询方法的硬件环境的示意图；

图2是根据本申请实施例的一种可选的业务数据的查询方法的流程图；

图3是根据本申请实施例的一种可选的业务数据的查询系统的示意图；

图4是根据本申请实施例的一种可选的业务数据的查询方法的流程图；

图5是根据本申请实施例的一种可选的业务数据的查询装置的示意图；以及，

图6是根据本申请实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

API(Application Programming Interface，应用程序接口)是一些预先定义的函数，或指软件系统不同组成部分衔接的约定，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问原码，或理解内部工作机制的细节。

根据本申请实施例的一方面，提供了一种业务数据的查询方法的方法实施例。

可选地，在本实施例中，上述业务数据的查询方法可以应用于如图1所示的由终端101和服务器103所构成的硬件环境中。如图1所示，服务器103通过网络与终端101进行连接，可用于为终端或终端上安装的客户端提供服务(如业务服务、应用服务等)，可在服务器上或独立于服务器设置数据库105，用于为服务器103提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端101并不限定于PC、手机、平板电脑等。本申请实施例的业务数据的查询方法可以由服务器103来执行，也可以由服务器103和终端101共同执行。其中，终端101执行本申请实施例的业务数据的查询方法也可以是由安装在其上的客户端来执行。

图2是根据本申请实施例的一种可选的业务数据的查询方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，中间插件获取第一业务系统中第一设备的第一请求，第一请求用于请求获取目标业务数据，目标业务数据来源于第二业务系统的数据库。

上述第一设备属于第一业务系统，目标数据库所在的设备属于第二业务系统，换言之，第一设备是要跨系统访问数据库中的目标业务数据，例如在公司内部的多个业务团队(即业务系统)、或者不同公司的业务团队，每个业务团队不用自己落地全量业务数据，而是通过用户访问(如第一请求)触发去数据源(即所需数据所在的业务系统的数据库中)获取数据。

步骤S204，中间插件从缓存中查找处于数据有效期内的目标业务数据，数据有效期是按照中间插件的指示为从业务系统的数据库中获取的业务数据配置的在缓存中保存的有效期，换言之，业务数据在缓存中的写入是由中间插件完成的，数据有效期(即数据在缓存中保存的期限)也是中间插件来配置的，即使中间插件来管理数据的擦写。

上述方案中，在通过用户访问触发去数据源获取数据后，然后把获取到的业务数据(即热数据)缓存到相应的缓存组件中进行存储，这样做的好处是，不用关心全量海量数据的存储以及维护问题，只关心自己业务缓存的部分热数据即可，由于热数据一般会在短时间内被使用多次，采用缓存的方式可以避免短时间多次向数据库请求同一数据，降低数据库的压力，同时通过本地的缓存进行数据读取会明显提高请求的响应效率。

步骤S206，响应于第一请求，中间插件将从缓存中查找到的目标业务数据返回给第一设备。

在相关技术中，一旦数据库发生故障或者与数据库之间的网络发生故障，就会导致数据源无法提供用户所需数据。在本申请的技术方案中，可以通过缓存来保存从数据库获取的热点数据，在数据库故障时利用缓存来提供数据服务，且缓存不用按照自己为数据配置的时间较短的缓存有效期(在缓存有效期这个时间段内可认为缓存中的某一数据与数据源中相应的数据相同，这个时间段内可以直接获取缓存中的该数据来替代从数据源中获取相应的数据)来删除数据，而是由中间插件为数据配置较长的保存时间(即数据有效期，相对于缓存有效期要长很多)，通过为数据设置较长的有效期可以保证数据库故障的时候缓存长时间稳定地对外提供数据服务，可以解决相关技术中数据库发生故障导致的无法提供数据服务的技术问题，避免由于数据库故障后而缓存自身缓存时间较短造成数据到缓存有效期期时被删除。下面结合图2所示的步骤进一步详述本申请的技术方案：

在步骤S202提供的技术方案中，在接收到第一业务系统中第一设备的第一请求时，可以通过如下步骤1-步骤5实现：

步骤1，查看缓存中是否存在目标业务数据，若存在则执行步骤2，否则执行步骤4；

步骤2，判断缓存中的目标业务数据是否超过缓存有效期，若超过则执行步骤4，否则执行3；

步骤3，直接从缓存中读取目标业务数据，以返回给第一设备；

步骤4，尝试从数据源获取目标业务数据，在从数据源获取到目标业务数据的情况下直接返回给第一设备，并写入缓存，在从数据源获取目标业务数据失败(如网络故障、数据源故障导致获取失败)的情况下执行步骤5；

步骤5，在缓存中的目标业务数据位于数据有效期内的情况获取目标业务数据，后文结合步骤S204进行详述。

在步骤S204提供的技术方案中，中间插件可以API的形式存在，通过API与其它业务系统的数据库或本地缓存进行数据的交互，而不是由业务系统的业务逻辑直接对接缓存组件，实际数据源的确定(如是从缓存还是从业务系统的数据库中读取数据)、数据读取逻辑、数据有效期设置等逻辑均是有中间插件完成的，而非由缓存去完成，可以降低缓存的压力，提高其处理效率。

本申请的中间插件(或称API)缓存业务数据的时候，会对需要缓存的业务数据，设置到新的数据封装结构(即预设数据结构)中，同时设置该数据缓存时的时间戳，从而得到实际的数据对象，API再将这个数据封装结构(即数据对象)缓存到缓存组件，而不是直接把数据缓存到缓存组件，数据封装结构的缓存有效期统一配置，如永久缓存(而不是像缓存自身的缓存有效期那样有效时间过短，如1秒)，即数据有效期，如果考虑到缓存组件的存储空间问题，可根据情况配置长一点的时间即可如一天。通过中间插件从缓存中查找处于数据有效期内的目标业务数据时，可按照如下步骤1-步骤3确定目标业务数据是否位于数据有效期内：

步骤1，在获取为缓存中存储的目标业务数据设置的时间戳之前，在第二设备(可以是各种可能得设备，包括上述第一设备)获取到目标业务数据的情况下，将第二设备的获取时间作为时间戳与目标业务数据一起保存在缓存的目标数据对象中。

可选地，上述时间戳的保存形式包括多种：1)可以将时间戳保存在缓存的操作日志中，具体可以将时间戳与目标业务数据关联后进行保存；2)可以将时间戳保存在中间插件的日志中，具体可以将时间戳与目标业务数据关联后进行保存；3)还可以将时间戳与目标业务数据一起保存在缓存中，具体参见下文：

在第二设备获取到目标业务数据的情况下，将第二设备的获取时间作为时间戳与目标业务数据一起保存在缓存的目标数据对象中包括以下两种情况：在缓存中不存在目标业务数据且第二设备从第二业务系统的数据库获取到目标业务数据的情况下，将用于表示第二设备的获取时间的时间戳和目标业务数据转换为目标数据对象保存在缓存中；在第二业务系统的数据库发生故障且第二设备从缓存中获取到目标业务数据的情况下，为了延长数据有效期，保证后续设备请求该数据时有数据可用，可将缓存中目标数据对象的时间戳更新为第二设备的获取时间。

在上述实施例中，将用于表示第二设备的获取时间的时间戳和目标业务数据转换为目标数据对象保存在缓存中包括按照如下方式利用两个不同的字段来存储数据：在缓存中创建包括第一字段和第二字段的目标数据对象，并将目标业务数据保存在第一字段中、将时间戳保存在第二字段中。

步骤2，获取为缓存中存储的目标业务数据设置的时间戳，时间戳用于表示目标业务数据有效的起始时间，如通过中间插件从缓存中获取目标数据对象携带的时间戳。

步骤3，在时间戳与当前时间之间的差值小于等于第一阈值的情况下，确定缓存中的目标业务数据位于数据有效期内。

可选地，在第二业务系统的数据库恢复正常之后，可以按照如下方式对目标数据对象进行更新：在第三设备(可以是各种可能得设备，包括上述第一设备和第二设备)从第二业务系统的数据库获取到的目标业务数据与目标数据对象中的目标业务数据一致的情况下，将缓存中目标数据对象的时间戳更新为第三设备的获取时间；在第三设备从第二业务系统的数据库获取到的目标业务数据与目标数据对象中的目标业务数据不一致的情况下，将缓存中目标数据对象中的目标业务数据更新为第三设备获取到的目标业务数据，并将目标数据对象中的时间戳更新为第三设备的获取时间。

上述实施例提供了一种由用户访问触发的更新方式，在又一个可选的实施例中，可以由中间插件主动进行更新，由于热数据(即已缓存的业务数据)属于高频使用的数据，且这部分数据也是比较容易发生更新的数据(如用户的消费数据、观影数据等)，为了保证缓存中数据的真实性，对于在时长为N的时间段内从缓存中读取次数大于M(M和N的值可以根据需求设置)的业务数据(或称数据对象)，API可以在检测到缓存处于较空闲(即访问量小于某个阈值)的时候，主动从数据库读取相应的数据，若相应的业务数据未更新，则将数据对象中的时间戳更新为当前时间，若相应的业务数据发生更新，则在数据对象中将数据更新为从服务器获取到的业务数据，并将时间戳更新为当前时间。

在步骤S206提供的技术方案中，响应于第一请求，将从缓存中查找到的目标业务数据返回给第一设备。

可选地，将从缓存中查找到的目标业务数据返回给第一设备包括：在缓存中目标数据对象携带的时间戳与当前时间之间的差值小于等于第二阈值的情况下，获取缓存中目标数据对象携带的目标业务数据，第二阈值是小于第一阈值的缓存有效期，第一阈值相当于缓存中数据保存的数据有效期，而第二阈值即前述缓存有效期；在缓存中目标数据对象携带的时间戳与当前时间之间的差值大于第二阈值且第二业务系统的数据库发生故障的情况下，获取缓存中目标数据对象携带的目标业务数据。

若直接在缓存中设置有效期会带来一些问题，由于大量应用对数据源服务具有强依赖，一旦数据源服务出现异常甚至一段时间都无法恢复的情况，那么缓存在缓存组件中的热数据在过了有效期之后，服务将无数据可用。当然，若缓存组件直接支持数据永久缓存，但是不设置数据有效期又会带来数据更新的时效性问题，需要引入额外的消息同步组件，这无疑又增加了架构的复杂度，所以，本申请在热数据缓存架构中利用中间插件来完成数据的擦写，确保异常情况下的数据可用性。

而在本申请的上述实施例中，通过中间插件API获取数据的时候，API首先在缓存组件中获取数据封装结构。如果不存在，则调用数据源服务获取数据。如果存在缓存结构，则根据业务需要的缓存有效期，跟缓存结构中的时间戳以及当前时间比对，看是否缓存过期。如果缓存数据有效，则返回结果，如果缓存过期，也需要调用数据源服务获取数据。

在调用数据源服务获取数据的时候，一旦数据源服务出现异常，则会对该服务的请求执行熔断，由于数据封装结构在缓存组件中配置了较长的有效期，保证了缓存热数据不会由于缓存组件自身数据失效而数据丢失，也即对于缓存而言，并不会主动删除缓存数据；同时针对异常情况下，会更新缓存封装结构中的缓存时间戳，然后数据重新缓存，进一步减少了异常情况中对数据源服务的请求。

下面结合具体的实施方案进一步详述本申请的技术方案：

本申请的系统架构如图3所示，本申请的封装结构(或称预设数据结构)如下所示的代码，其中Object类型的data字段，是用来存储真实要缓存的业务数据，长整形(即Long)的cacheTime为缓存时的时间戳。

缓存数据的时候，不直接缓存数据本身，而是先构建一个CacheDataInfo对象，将缓存数据设置为data字段，将当前时间戳设置为cacheTime字段，然后在缓存中缓存整个CacheDataInfo对象(即数据对象)，并在缓存中为该CacheDataInfo对象设置较长的有效期，保证CacheDataInfo对象不会因为缓存组件内部的失效机制而轻易丢失，保证数据存储尽可能可控。

如下所示的代码的例子是应用在缓存组件couchbase上，result为需要缓存的数据对象，此时设置这个数据对象在couchbase上的有效期为1天。下面结合图4所示的步骤进行说明。

couchbaseCacheService.cache(cacheKey，new CacheDataInfo(result)

步骤S402，用户设备(即第一设备)通过API发起对业务数据的请求，通过API获取数据。

步骤S404，向缓存cash请求数据的封装结构(即目标数据对象)。

步骤S406，接收缓存返回的封装结构，即接收数据。

步骤S408，封装结构不存在或者经过对比时间戳后确定失效，则直接向数据源请求数据。

上述判断数据是否失效的步骤，不用依靠缓存组件内部机制控制，而是在获取数据时由中间插件程序自主判断，通过封装结构中的时间戳字段和当前时间的对比，判断数据是否失效，如果数据失效，再调用数据源服务获取数据。

判断数据是否失效时，首先从缓存组件中获取CacheDataInfo，获取方式如下代码所示；根据CacheDataInfo中的时间戳判断数据是否失效。

dataInfo＝couchbaseCacheService.get(cacheKey，CacheDataInfo.class)；

步骤S410，接收数据源返回的数据。

经过上述判断之后，如果CacheDataInfo不存在，或者数据已失效(即expired)，具体判断方式参见以下代码：

if(null!dataInfo&&!dataInfo.isExpired(expired))

result＝dataInfo.getData()；

如果失效，则通过数据源服务相应的数据加载方法获取数据，然后再将数据缓存，具体获取方式参见以下代码：

步骤S412，若接收到的数据正确，则创建新的封装结构。

步骤S414，若接收到的数据异常或者数据源异常，则将已过期的封装结构中的时间戳更新为当前时间。

如果数据源服务出现异常，那么数据加载方法将不会获得数据结果。此时由于缓存中设置的CacheDataInfo的缓存时间较长，还是存在之前的缓存数据的，这个数据可以保证业务处理流程中，不至于出现无数据可用的情况。

可以在异常情况下继续使用CacheDataInfo中的data字段，更新CacheDataInfo中的时间戳，并重新缓存，即直接请求没有得到数据，更新缓存时间，以防止一直请求引起接口超时。数据源服务异常时，延长数据有效期可以减少对数据源服务的请求数量，其实现的代码逻辑如下：

步骤S416，如果在判定在有效期内，则向缓存请求数据。

如执行CacheDataInfo.getData()操作，得到真实缓存对象。

步骤S418，接收缓存返回的数据对象。

步骤S420，将业务数据通过API返回给用户终端。

上述方案可以用于热数据缓存场景中的数据缓存，通过定制数据结构，保存缓存时间戳来判断缓存数据失效，解决了热数据缓存场景中，异常情况下，缓存数据不可用的问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

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

根据本申请实施例的另一个方面，还提供了一种用于实施上述业务数据的查询方法的业务数据的查询装置。图5是根据本申请实施例的一种可选的业务数据的查询装置的示意图，如图5所示，该装置可以包括：

获取单元501，用于获取第一业务系统中第一设备的第一请求，其中，所述第一请求用于请求获取目标业务数据，所述目标业务数据来源于第二业务系统的数据库；

查找单元503，用于通过中间插件从缓存中查找处于数据有效期内的所述目标业务数据，其中，所述数据有效期是按照所述中间插件的指示为从业务系统的数据库中获取的业务数据配置的在所述缓存中保存的有效期；

返回单元505，用于响应于所述第一请求，将从所述缓存中查找到的所述目标业务数据返回给所述第一设备。

需要说明的是，该实施例中的获取单元501可以用于执行本申请实施例中的步骤S202，该实施例中的查找单元503可以用于执行本申请实施例中的步骤S204，该实施例中的返回单元505可以用于执行本申请实施例中的步骤S206。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

在相关技术中，一旦数据库发生故障或者与数据库之间的网络发生故障，就会导致数据源无法提供用户所需数据。在本申请的技术方案中，可以通过缓存来保存从数据库获取的热点数据，在数据库故障时利用缓存来提供数据服务，且缓存不用按照自己为数据配置的时间较短的缓存有效期(在缓存有效期这个时间段内可认为缓存中的某一数据与数据源中相应的数据相同，这个时间段内可以直接获取缓存中的该数据来替代从数据源中获取相应的数据)来删除数据，而是由中间插件为数据配置较长的保存时间(即数据有效期，相对于缓存有效期要长很多)，通过为数据设置较长的有效期可以保证数据库故障的时候缓存长时间稳定地对外提供数据服务，可以解决相关技术中数据库发生故障导致的无法提供数据服务的技术问题，避免由于数据库故障后而缓存自身缓存时间较短造成数据到时被删除。

可选地，查找单元可按照如下方式确定目标业务数据位于数据有效期内：获取为缓存中存储的目标业务数据设置的时间戳，其中，时间戳用于表示目标业务数据有效的起始时间；在时间戳与当前时间之间的差值小于等于第一阈值的情况下，确定缓存中的目标业务数据位于数据有效期内。

可选地，本申请的装置还可包括保存单元，用于在获取为缓存中存储的目标业务数据设置的时间戳之前，在第二设备获取到目标业务数据的情况下，将第二设备的获取时间作为时间戳与目标业务数据一起保存在缓存的目标数据对象中。

可选地，查找单元还可用于通过中间插件从缓存中获取目标数据对象携带的时间戳。

可选地，本申请的保存单元还可用于：在缓存中不存在目标业务数据且第二设备从第二业务系统的数据库获取到目标业务数据的情况下，将用于表示第二设备的获取时间的时间戳和目标业务数据转换为目标数据对象保存在缓存中；在第二业务系统的数据库发生故障且第二设备从缓存中获取到目标业务数据的情况下，将缓存中目标数据对象的时间戳更新为第二设备的获取时间。

可选地，本申请的保存单元还可用于：在第二业务系统的数据库恢复正常之后，在第三设备从第二业务系统的数据库获取到的目标业务数据与目标数据对象中的目标业务数据一致的情况下，将缓存中目标数据对象的时间戳更新为第三设备的获取时间；在第三设备从第二业务系统的数据库获取到的目标业务数据与目标数据对象中的目标业务数据不一致的情况下，将缓存中目标数据对象中的目标业务数据更新为第三设备获取到的目标业务数据，并将目标数据对象中的时间戳更新为第三设备的获取时间。

可选地，本申请的保存单元还可用于：在缓存中创建包括第一字段和第二字段的目标数据对象，并将目标业务数据保存在第一字段中、将时间戳保存在第二字段中。

可选地，本申请的返回单元还可用于：在缓存中目标数据对象携带的时间戳与当前时间之间的差值小于等于第二阈值的情况下，获取缓存中目标数据对象携带的目标业务数据，其中，第二阈值小于第一阈值；在缓存中目标数据对象携带的时间戳与当前时间之间的差值大于第二阈值且第二业务系统的数据库发生故障的情况下，获取缓存中目标数据对象携带的目标业务数据。

在本申请的技术方案中，通过上述方案，若缓存中存有有效数据，在第一设备发起请求时中间插件可以直接从缓存获取并返回给第一设备，若缓存中未缓存有有效数据，第一设备同样是发起第一请求然后等待接收目标业务数据，由中间插件先向缓存发送请求、接收缓存返回的不存在目标业务数据的反馈信息、再向数据库发送请求、接收数据库返回的目标业务数据然后将目标业务数据返回给第一设备，并且将接收的目标业务数据写入缓存的操作也是由中间插件去执行，该方案中将“向缓存发送请求、接收缓存返回的不存在目标业务数据的反馈信息、再向数据库发送请求、向缓存写入数据”等处理逻辑交由中间插件去完成，可以降低设备获取数据的交互复杂度，进而降低对第一设备的资源消耗，提高其业务性能。

相关技术中对数据库频繁的读写访问严重影响了应用的服务性能和可用性，一些实时性响应要求很高的系统访问数据库来讲，由于需要支持大规模的并发访问且能高效响应，在数据库访问组件中，并不能让客户端对数据的请求阻塞掉服务，数据库的访问量限制或者故障制约着系统实时处理性能。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本申请实施例的另一个方面，还提供了一种用于实施上述业务数据的查询方法的服务器或终端。

图6是根据本申请实施例的一种终端的结构框图，如图6所示，该终端可以包括：一个或多个(图6中仅示出一个)处理器601、存储器603、以及传输装置605，如图6所示，该终端还可以包括输入输出设备607。

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

上述的传输装置605用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置605包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置605为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器603用于存储应用程序。

处理器601可以通过传输装置605调用存储器603存储的应用程序，以执行下述步骤：

获取第一业务系统中第一设备的第一请求，其中，第一请求用于请求获取目标业务数据，目标业务数据来源于第二业务系统的数据库；

通过中间插件从缓存中查找处于数据有效期内的目标业务数据，其中，数据有效期是按照中间插件的指示为从业务系统的数据库中获取的业务数据配置的在缓存中保存的有效期；

响应于第一请求，将从缓存中查找到的目标业务数据返回给第一设备。

处理器601还用于执行下述步骤：

在缓存中不存在目标业务数据且第二设备从第二业务系统的数据库获取到目标业务数据的情况下，将用于表示第二设备的获取时间的时间戳和目标业务数据转换为目标数据对象保存在缓存中；

在第二业务系统的数据库发生故障且第二设备从缓存中获取到目标业务数据的情况下，将缓存中目标数据对象的时间戳更新为第二设备的获取时间。

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

本领域普通技术人员可以理解，图6所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图6其并不对上述电子装置的结构造成限定。例如，终端还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图6所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行业务数据的查询方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

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

获取第一业务系统中第一设备的第一请求，其中，第一请求用于请求获取目标业务数据，目标业务数据来源于第二业务系统的数据库；

通过中间插件从缓存中查找处于数据有效期内的目标业务数据，其中，数据有效期是按照中间插件的指示为从业务系统的数据库中获取的业务数据配置的在缓存中保存的有效期；

响应于第一请求，将从缓存中查找到的目标业务数据返回给第一设备。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

在缓存中不存在目标业务数据且第二设备从第二业务系统的数据库获取到目标业务数据的情况下，将用于表示第二设备的获取时间的时间戳和目标业务数据转换为目标数据对象保存在缓存中；

在第二业务系统的数据库发生故障且第二设备从缓存中获取到目标业务数据的情况下，将缓存中目标数据对象的时间戳更新为第二设备的获取时间。

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

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (7)

1.一种业务数据的查询方法，其特征在于，包括：

获取第一业务系统中第一设备的第一请求，其中，所述第一请求用于请求获取目标业务数据，所述目标业务数据来源于第二业务系统的数据库；

通过中间插件从缓存中查找处于数据有效期内的所述目标业务数据，其中，所述数据有效期是按照所述中间插件的指示为从业务系统的数据库中获取的业务数据配置的在所述缓存中保存的有效期，通过如下方式确定所述目标业务数据位于数据有效期内：通过所述中间插件从所述缓存中获取目标数据对象携带的时间戳，所述时间戳用于表示所述目标业务数据有效的起始时间；在所述时间戳与当前时间之间的差值小于等于第一阈值的情况下，确定所述缓存中的所述目标业务数据位于数据有效期内；

响应于所述第一请求，将从所述缓存中查找到的所述目标业务数据返回给所述第一设备；

其中，在通过所述中间插件从所述缓存中获取所述目标数据对象携带的时间戳之前，所述方法还包括：在所述缓存中不存在所述目标业务数据且第二设备从所述第二业务系统的数据库获取到所述目标业务数据的情况下，将用于表示所述第二设备的获取时间的时间戳和所述目标业务数据转换为所述目标数据对象保存在所述缓存中；在所述第二业务系统的数据库发生故障且所述第二设备从所述缓存中获取到所述目标业务数据的情况下，将所述缓存中所述目标数据对象的时间戳更新为所述第二设备的获取时间。

2.根据权利要求1所述的方法，其特征在于，在所述第二业务系统的数据库恢复正常之后，所述方法还包括：

在第三设备从所述第二业务系统的数据库获取到的目标业务数据与所述目标数据对象中的目标业务数据一致的情况下，将所述缓存中所述目标数据对象的时间戳更新为所述第三设备的获取时间；

在所述第三设备从所述第二业务系统的数据库获取到的目标业务数据与所述目标数据对象中的目标业务数据不一致的情况下，将所述缓存中所述目标数据对象中的目标业务数据更新为所述第三设备获取到的目标业务数据，并将所述目标数据对象中的时间戳更新为所述第三设备的获取时间。

3.根据权利要求1所述的方法，其特征在于，将用于表示所述第二设备的获取时间的时间戳和所述目标业务数据转换为所述目标数据对象保存在所述缓存中包括：

在所述缓存中创建包括第一字段和第二字段的所述目标数据对象，并将所述目标业务数据保存在所述第一字段中、将所述时间戳保存在所述第二字段中。

4.根据权利要求1至3中任意一项所述的方法，其特征在于，将从所述缓存中查找到的所述目标业务数据返回给所述第一设备包括：

在所述缓存中目标数据对象携带的时间戳与当前时间之间的差值小于等于第二阈值的情况下，获取所述缓存中所述目标数据对象携带的所述目标业务数据，其中，所述第二阈值小于第一阈值；

在所述缓存中所述目标数据对象携带的时间戳与当前时间之间的差值大于所述第二阈值且所述第二业务系统的数据库发生故障的情况下，获取所述缓存中所述目标数据对象携带的所述目标业务数据。

5.一种业务数据的查询装置，其特征在于，包括：

获取单元，用于获取第一业务系统中第一设备的第一请求，其中，所述第一请求用于请求获取目标业务数据，所述目标业务数据来源于第二业务系统的数据库；

查找单元，用于通过中间插件从缓存中查找处于数据有效期内的所述目标业务数据，其中，所述数据有效期是按照所述中间插件的指示为从业务系统的数据库中获取的业务数据配置的在所述缓存中保存的有效期，通过如下方式确定所述目标业务数据位于数据有效期内：通过所述中间插件从所述缓存中获取目标数据对象携带的时间戳，所述时间戳用于表示所述目标业务数据有效的起始时间；在所述时间戳与当前时间之间的差值小于等于第一阈值的情况下，确定所述缓存中的所述目标业务数据位于数据有效期内；

返回单元，用于响应于所述第一请求，将从所述缓存中查找到的所述目标业务数据返回给所述第一设备；

保存单元，用于在通过所述中间插件从所述缓存中获取所述目标数据对象携带的时间戳之前，在所述缓存中不存在所述目标业务数据且第二设备从所述第二业务系统的数据库获取到所述目标业务数据的情况下，将用于表示所述第二设备的获取时间的时间戳和所述目标业务数据转换为所述目标数据对象保存在所述缓存中；在所述第二业务系统的数据库发生故障且所述第二设备从所述缓存中获取到所述目标业务数据的情况下，将所述缓存中所述目标数据对象的时间戳更新为所述第二设备的获取时间。

6.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至4任一项中所述的方法。

7.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行上述权利要求1至4任一项中所述的方法。