组装基础数据缓存的方法及装置与流程

本申请涉及数据库技术领域，特别是涉及组装基础数据缓存的方法及装置。

背景技术：

数据库技术在许多系统中有着广泛的应用，如网站相关的多种数据可以有组织的存储在数据库中，并通过数据库管理软件进行管理和使用，从而为站点提供各种数据服务。随着互联网应用的不断发展，互联网数据的规模也在迅速膨胀，如何对大规模数据进行更加高效的存储和应用，成为技术人员不断进行深入研究的重要课题。尤其是对于一些数据量相对集中的站点，诸如电子商务网站，其数据规模相当庞大，能否对数据库中的大规模数据进行有效的组织和调用，成为影响站点业务处理效率的重要因素。在站点业务数据的规模相对较小时，数据可以随需要直接在数据库中读取。但是，当站点的数据规模到达一定数量级后，如果仍依靠读取接口直接读取数据库，直接调用数据的访问可能导致系统开销过大，例如，磁盘IO、网络吞吐量、网卡占用、数据库连接池占用等都可能会承受较高的压力，数据的调用效率就会降低，从而对上层应用的执行造成不同程度的影响，例如，可能产生严重的超时甚至系统崩溃。

为了尽量避免数据库系统成为网站系统的瓶颈，在软件层面上，可以通过改进数据的管理和使用方法来提高数据库的应用效率。例如，可以根据数据的使用或更新频度，对不同数据分别使用不同方法进行应用。如可以将经常使用并且不经常变化的基础数据，加载到访问效率更高的缓存中，这样，当业务层系统的需要使用这部分基础数据时，只需从缓存中读取即可而不需直接访问数据库，从而提高数据的访问效率，减少磁盘读取等开销。

缓存基础数据方法的早期方案是，在初始化业务层系统的缓存时直接从数据库服务器中加载数据，但随着业务层系统的增加，多个业务系统常常会因同时加载或更新数据缓存而访问数据库服务器，造成数据库服务器的瞬间压力过大。为了尽量减少数据库服务器的这种瞬间压力，各业务层系统只能选择在业务流量较低时加载数据缓存，给缓存基础数据的应用造成了很大的局限性。

技术实现要素：

本申请提供了组装基础数据缓存的方法及装置，解决了数据库服务器的瞬间压力过大的问题，以及，防止业务服务器因基础数据间存在依赖关系，导致的组装任务挂起，或强制访问数据库服务器等问题，具有更强的适应性和实用性。

本申请提供了如下方案：

一种的组装基础数据缓存的方法，业务服务器预先从推送中心服务器订阅多份基础数据，所述方法包括：

业务服务器接收到推送中心服务器推送的基础数据以及调用预置回调函数的触发请求时，调用所述回调函数，以便通过所述回调函数执行以下步骤：

将接收到的基础数据暂存在本地存储中；

判断是否已经将订阅的各份基础数据全部接收到；

如果是，则根据所述本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。

一种的组装基础数据缓存的装置，业务服务器预先从推送中心服务器订阅多份基础数据，所述装置包括：

函数调用单元，用于在接收到推送中心服务器推送的基础数据以及调用预置回调函数的触发请求时，调用所述回调函数，所述回调函数包括以下模块：

数据存储模块，用于将接收到的基础数据暂存在本地存储中；

完整性判断模块，用于判断是否已经将订阅的各份基础数据全部接收到；

缓存组装模块，用于如果所述完整性判断模块的判断结果为是，则根据所述本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请，可以在业务服务器接收到推送中心服务器推送的基础数据，以及调用预置回调函数的触发请求时，调用预置的回调函数，进而通过回调函 数将接收到的基础数据暂存在本地存储中，在判断已经将订阅的各份基础数据全部接收到的条件下，则根据本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。解决了多个业务服务器因同时加载或更新数据缓存而访问数据库服务器，造成数据库服务器的瞬间压力过大的问题，同时，也防止了业务服务器因基础数据间存在依赖关系，而被依赖的基础数据未能及时接收所导致的组装任务挂起，或强制访问数据库服务器等问题，使得本组装基础数据缓存的方法具有更强的适应性和实用性。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例的基础数据的传输示意图；

图2是本申请实施例提供的组装基础数据缓存的方法的流程图；

图3是本申请实施例提供的另一组装基础数据缓存的方法的流程图；

图4是本申请实施例提供的又一组装基础数据缓存的方法的流程图；

图5是本申请实施例提供的组装基础数据缓存的装置的示意图。

具体实施方式

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

互联网业务规模的不断增长，需要处理的数据规模也变得非常庞大，在一些数据规模较大的站点中，常常使用专用的服务器或者服务器集群来实现数据库业务。对于基础数据的缓存处理，现有技术中是在业务服务器产生业务初始化或者刷新缓存等需求时，由业务服务器从数据库服务器中直接获取数据。在业务服务器规模或所需基础数据规模较大等情况下，这种实现方式就会暴露出 数据库服务器瞬时访问压力过大，基础数据的传输、加载延迟等缺陷，最终使缓存基础数据成为系统的瓶颈。为适应大规模缓存数据处理的效率需求，本申请实施例提出了一种组装基础数据缓存的方法，该方法依托于在数据库服务器与业务服务器之间架设了一层推送中心服务器。如图1所示，为本申请实施例的基础数据的传输示意图。其中数据库服务器110，推送中心服务器120，以及业务服务器130分别可以由单一服务器实现，也可以分别基于服务器集群实现；服务器或服务器集群可以基于虚拟化技术实现。

在产生基础数据缓存需求时，例如，当按照预置的周期对业务服务器进行缓存数据的更新时，可以首先由推送中心服务器从数据库服务器中获取所需的缓存数据，各业务服务器所需的缓存数据可包括多个基础数据文件，每个基础数据文件对应一份基础数据。推送中心服务器只需一次性访问数据库服务器，即可将所有业务服务器所需的基础数据下载下来，进而再根据各业务服务器的需要，向各业务服务器推送其所需的数据。这样，通过专用于文件推送的推送中心服务器的“代理”，可以将基础数据的推送与其他数据库管理任务剥离开来，这样不但可有效的减轻数据库服务器的数据管理压力，而且还提高了基础数据推送的效率。

在一种实现方式下，推送中心服务器可以实时的根据各业务服务器的请求，向各业务服务器推送所需的基础数据。但发明人在实施本方法的过程中发现，通常情况下，业务服务器组装缓存所需的基础数据内容类型通常是固定的，另外，业务服务器组装缓存的时机也常常是固定的，如业务系统启动时，或为了便于管理的目的而定时刷新缓存内容时，因而，业务服务器组装缓存的任务可以定时触发。这样，在另一种实现方式下，推送中心服务器向各业务服务器推送其所需的基础数据时，推送中心服务器可以根据与业务中心服务器的“约定”进行固定时机、固定内容类型的基础数据推送，如业务服务器可以预先从推送中心服务器订阅多份基础数据。而对应的，业务中心服务器接收所需的基础数据文件可以是“被动式”的。这种推送中心服务器主动推送，业务服务器被动接收的实现方式，一方面可以满足实际的应用需求，另外可以使推送中心服务器不必处理业务服务器的数据请求，避免因大量请求并发而产生阻塞的风险，同时，推送中心服务器可以自主地、更加灵活的安排推送任务。除了解决了现 有缓存基础数据技术中，大量业务服务器访问直接数据库造成的瞬时压力主要问题，提高了基础数据缓存技术的灵活性之外，本申请实施例提供的方法还解决了基础数据缓存技术实现的一些其他问题，详情请参见实施例的具体阐述。

下面以推送中心服务器主动推送，业务服务器被动接收的实现方式为例，对本申请实施例提供的组装基础数据缓存的方法的具体的实现方式进行详细介绍。请参看图2，其为本申请实施例提供的组装基础数据缓存的方法的流程图，业务服务器接收到推送中心服务器推送的基础数据以及调用预置回调函数的触发请求时，调用该回调函数，以便通过该回调函数执行以下步骤：

S210：将接收到的基础数据暂存在本地存储中；

在本申请实施例提供的实现方式下，业务服务器预先从推送中心服务器订阅多份基础数据，不同业务服务器可以根据其应用需要，在推送中心服务器中订阅相同或不同的基础数据。推送中心服务器在推送业务发起后，根据业务服务器的订阅向业务服务器推送基础数据。在业务服务器中预置有回调函数，该预置的回调函数可通过推送中心服务器触发，如可以伴随每份基础数据的推送触发，并在业务服务器端执行。推送中心服务器在向业务服务器推送基础数据时，可以同时发送调用业务服务器执行预置回调函数的请求，业务服务器接收到推送中心服务器推送到基础数据，以及调用预置回调函数的请求时，可以调用本地的预置回调函数，通过该回调函数，首先完成将接收到的基础数据暂存在本地存储中。如前所述，基础数据可以以文件作为载体，每个基础数据文件对应一份基础数据。业务服务器可以通过预置的回调函数，将接收到的各个基础数据文件存储暂存在本地缓存中。具体进行暂存时，可以保存在业务服务器的硬盘中，如保存在硬盘的临时数据存放区，或者也可以在内存中申请空间，将接收到的基础数据保存在所申请的内存空间中，便于完成快速的写入和后续的读取。

S220：判断是否已经将订阅的各份基础数据全部接收到；

在通过预置的回调函数将接收到的基础数据暂存在本地存储中后，接下来可以判断是否已经将订阅的各份基础数据全部接收到，以便于业务服务器根据多接收到的基础数据进行缓存组装。如前所述，本方法通过推送中心服务器代 理基础数据分发的方式，解决了数据库服务器访问压力过大的问题。在进行基础数据缓存的组装的过程中，一种实现方式是，根据所接收到的缓存数据的顺序依次组装，即接收到一份缓存数据，就进行一次基础数据缓存的组装，在所接收到的多份缓存数据之间没有依赖关系的情况下，这种实现方式具有较高的组装效率，但在所接收到的多份缓存数据之间存在依赖关系的情况下带来了新的问题，以下进行具体的说明。

在实际应用中，在所接收到的多份缓存数据之间没有依赖关系的情况下，可以根据所接收到的缓存数据的顺序依次组装，例如，当基础数据a接收完成时，可以将其组装为缓存A并加载，当另一份基础数据b接收完成时，可以将其组装为缓存B并加载。但在所接收到的多份缓存数据之间存在依赖关系的情况下，例如，当基础数据b接收完成要进行缓存B的组装时，同时又需要依赖于基础数据a，而此时基础数据a因为种种原因还未完成接收，例如，因为基础数据a的数据量较大造成传输时间拉长，或推送中心服务器集群中某服务器向当前业务服务器推送基础数据a的任务还未开始等等，此时业务服务器只能将组缓存B的组装任务挂起，或产生向数据库服务器强制访问数据的请求。而一般情况下，业务服务器作为对外业务的提供者，因为缓存组装挂起造成业务服务的暂停的情况不可接受的，其挂起时间也难以控制，因而在缓存组装挂起后，业务服务器通常会选择强制访问数据库服务器，进而造成数据库服务器的压力增加。为了避免这种情况的出现，本申请实施例提供的方法中，在根据接收到的基础数据进行缓存的组装之前，可以判断是否已经将订阅的各份基础数据全部接收到，进而可以在所订阅到各份基础数据全部接收到的情况下，才进行缓存的组装。通过这种方式，避免了因基础数据间存在依赖关系，而被依赖基础数据未能及时接收导致的强制访问数据库服务器问题。

如图3所示，其为本申请实施例提供的另一种实现方式下的组装基础数据缓存的方法的流程图，如图所示，在判断是否已经将订阅的各份基础数据全部接收到时，该方法可以包括步骤S310：在每接收到一份基础数据时，对预置的计数器进行加一操作。该计数操作可以由前述的回调函数触发或执行。以及步骤2201：判断计数器的值是否与订阅的基础数据份数相等，如果是，则确定已经将订阅的各份基础数据全部收到。在进行基础数据的接收时，可能偶尔 会由于一些原因接收到重复的数据，例如因重复订阅，重复发送，网络错误导致的重新传输等原因，造成业务服务器接收基础数据的重复。为了避免这种基础数据的重复，在对计数器进行累加之前，可以对接收到的基础数据进行重复接收的判断，具体的，可以利用文件名，文件大小，文件特征值等标识进行判断。

如图4所示，其为本申请实施例提供的又一种实现方式下的组装基础数据缓存的方法的流程图，其中可包括步骤S410：获取并记录所接收到的基础数据的标识；如可以获取基础数据文件的文件名，文件大小或文件特征值作为所接收到的基础数据的标识，例如根据接收到的基础数据文件计算得到其哈希值作为标识。在实现每接收到一份所述基础数据，对预置的计数器进行加一操作时，可以包括步骤S3101：在每接收到一份基础数据时，根据该基础数据的标识判断是否已接收过该份基础数据，如果是，则将该份基础数据丢弃，否则触发计数器加一操作。此外，在缓存组装完成后，可以将该预置的计数器清零，以便于下次缓存组装任务时，重新利用该计数器进行缓存数据的计数。

S230：如果是，则根据所述本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。

在全部接收到所订阅到各份基础数据后，可以按照预置的组装策略，根据本地存储中暂存的各份基础数据进行缓存组装。其中，预置的组装策略可以根据实际的应用进行指定。例如可以一次性将所有接收完整的基础数据组装为缓存，也可以根据业务系统的实际需要，进行分批次的组装。

在实际应用中，推送中心服务器在向业务服务器推送一份基础数据之后，就会业务服务器中预置回调函数的一次执行，因而在业务服务器中，常常会启动多个线程，没个线程中都会调用预置的回调函数。在推送并发的情况下，多线程会操作一下共享数据，因而，在这种并发的情况下，需要保护共享数据的一致性。在本申请实施例中，需要保护其一致性的共享数据可以至少包括两种，其一是前述的预置计数器的值，另外一种是保存基础数据标识的数据结构(如保存基础数据标识的链表)，在多线程访问的情况下，这两种共享数据都可能会被多线程并发访问。为了保持共享数据的一致性，可以在回调函数中使用同 步方法，例如当回调函数使用java语言编写时，回调函数中访问计数器的值的方法，以及访问保存基础数据标识的数据结构的方法，可以是加入synchronized关键字的同步方法，当多个线程并发访问共享数据时，通过同步方法访问共享数据，可以保证在同一时刻只有一个线程调用的同步方法能够访问共享数据，以便保持所述共享数据在多线程访问下的一致性。

此外，在业务服务中，可以通过预置的回调函数启动一计时线程，对基础数据的接收以及缓存的组装过程进行计时，并在接收及组装过程超过预设时长后返回超时信息，便于管理人员根据超时信息对及时排查超时原因。在按照预置的组装策略进行缓存组装完成后，可以将本地存储中暂存的基础数据删除，以释放其所占用的存储空间，以便于其他应用继续使用这部分存储空间。根据基础数据完成缓存的组装后，可以加载所组装的缓存，以供业务系统的其他应用进行读写访问。

以上对本申请实施例提供的组装基础数据缓存的方法进行了详细的介绍，通过该方法，可以在业务服务器接收到推送中心服务器推送的基础数据，以及调用预置回调函数的触发请求时，调用预置的回调函数，进而通过回调函数将接收到的基础数据暂存在本地存储中，在判断已经将订阅的各份基础数据全部接收到的条件下，则根据本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。该方法解决了多个业务服务器因同时加载或更新数据缓存而访问数据库服务器，造成数据库服务器的瞬间压力过大的问题，同时，推送中心服务器可以不必根据基础数据间的依赖关系设计更复杂的推送方式，避免了业务服务器因基础数据间存在依赖关系，而被依赖的基础数据未能及时接收所导致的组装任务挂起，或强制访问数据库服务器等问题，使得本组装基础数据缓存的方法具有更强的适应性和实用性。

与本申请实施例提供的组装基础数据缓存的方法相对应，还提供了组装基础数据缓存的装置，如图5所示，其为本申请实施例提供的组装基础数据缓存的装置的示意图，业务服务器预先从推送中心服务器订阅多份基础数据，所述装置包括：

函数调用单元510，用于接收到推送中心服务器推送的基础数据以及调用 预置回调函数的触发请求时，调用回调函数。该回调函数包括：

数据存储模块520，用于将接收到的基础数据暂存在本地存储中；

完整性判断模块530，用于判断是否已经将订阅的各份基础数据全部接收到；

缓存组装模块540，用于如果是，则根据本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。

此外，该回调函数还可以包括：

数据计数模块，在每接收到一份基础数据时，对预置的计数器进行加一操作；

在这种实现方式下，完整性判断模块530可以包括：

完整性判断子模块，用于判断计数器的值是否与订阅的基础数据份数相等，如果是，则确定已经将订阅的各份基础数据全部收到。

在另一种实现方式下，该回调函数还可以包括：

标识获取模块，用于获取并记录所接收到的基础数据的标识；

此时，数据计数模块可以包括：

数据计数子模块，用于在每接收到一份基础数据时，根据该基础数据的标识判断是否已接收过该份基础数据，如果是，则将该份基础数据丢弃，否则，触发计数器加一操作。

另外，该回调函数还可以包括：

计数器清零模块，用于在缓存组装完成后，将预置的计数器清零。

为了便于进行超时管理，该组装基础数据缓存的装置还可以包括：

超时处理单元，用于启动一计时线程，对基础数据的接收以及缓存的组装过程进行计时，并在接收及组装过程超过预设时长后返回超时信息。

为了保持多线程下共享数据的一致性，在回调函数中可以使用同步方法，装置还可以包括：

数据一致性保持单元，当调用多个线程并发访问共享数据时，通过同步方法访问共享数据，以便保持共享数据在多线程访问下的一致性。

在缓存组装完成后，可以对接收到基础数据进行清理，该组装基础数据缓存的装置还可以包括：

基础数据清理单元，用于在按照预置的组装策略进行缓存组装完成后，将本地存储中暂存的基础数据删除。

以上对本申请实施例提供的组装基础数据缓存的装置进行了详细的介绍，通过该装置，可以在业务服务器接收到推送中心服务器推送的基础数据，以及调用预置回调函数的触发请求时，调用预置的回调函数，进而通过回调函数将接收到的基础数据暂存在本地存储中，在判断已经将订阅的各份基础数据全部接收到的条件下，则根据本地存储中暂存的各份基础数据，按照预置的组装策略进行缓存组装。解决了多个业务服务器因同时加载或更新数据缓存而访问数据库服务器，造成数据库服务器的瞬间压力过大的问题，同时，也防止了业务服务器因基础数据间存在依赖关系，而被依赖的基础数据未能及时接收所导致的组装任务挂起，或强制访问数据库服务器等问题，使得本组装基础数据缓存的装置具有更强的适应性和实用性。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元， 即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的组装基础数据缓存的方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。