一种数据更新方法、装置、系统、计算机设备及存储介质与流程

本发明涉及信息处理技术，尤其涉及一种数据更新方法、装置、系统、计算机设备及存储介质。

背景技术：

目前，在客户端获取到后端服务器更新的某种业务的数据，通常采用的方法为，客户端或者客户端对应的接入层服务器直接从后端服务器进行数据提取。但是，接入层服务器由于并不知道后台哪些数据出现了更新，因此，就需要周期性的或者经常性的从后台提取某一个业务的数据，然后进行对比判断是否出现更新。

可以看出，前面的处理方式，客户端获取更新数据的过程较为复杂，使得用户侧无法及时得到更新后的数据，尤其无法应对实时性要求较高的业务。

技术实现要素：

有鉴于此，本发明实施例希望提供一种数据更新方法、装置、系统、计算机设备及存储介质，能至少解决现有技术中存在的上述问题。

本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种数据更新方法，所述方法包括：

接收服务器推送的至少一条更新后的数据，将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；

检测到接入层服务器发来的数据获取请求时，基于所述数据获取请求从所述存储队列中提取目标数据，将所述目标数据发送至所述接入层服务器所连接的终端。

本发明实施例提供了一种数据更新装置，所述装置包括：

存储单元，用于接收服务器推送的至少一条更新后的数据；将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；

提取单元，用于检测到接入层服务器发来的数据获取请求时，从所述存储队列中提取目标数据；

数据发送单元，用于将所述目标数据发送至所述接入层服务器所连接的终端。

本发明实施例提供了一种数据更新系统，所述系统包括：

分布式消息队列系统，用于接收服务器推送的至少一条更新后的数据，将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；检测到接入层服务器发来的数据获取请求时，基于所述数据获取请求从所述存储队列中提取目标数据，将所述目标数据发送至所述接入层服务器所连接的终端；

服务器，用于推送所述至少一条更新后的数据至分布式消息队列系统；

接入层服务器，用于从所述分布式消息队列系统的存储队列中提取目标数据。

本发明实施例提供了一种存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现前述所述方法的步骤。

本发明实施例提供了一种计算机设备，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，

其中，所述处理器用于运行所述计算机程序时，执行前述方法的步骤。

采用本发明实施例，就能够获取到主动推送来的发生更新的数据，在接入层服务器发来请求的时候，直接从存储队列中发送更新后的数据；从而摈弃了现有技术中“拉取-对比”的过程所带来的用户侧获取更新数据的时间延迟；并且，接入层服务器避免了从后端服务器直接获取数据的操作，从而节省了大量的服务器资源。

附图说明

图1-1为本发明实施例场景示意图1；

图1-2为本发明实施例数据更新方法流程示意图；

图2为本发明实施例场景示意图2；

图3为本发明实施例场景示意图3；

图4为本发明实施例数据更新装置组成结构示意图；

图5为本发明实施例数据更新系统组成结构示意图；

图6为本发明实施例数据更新系统中的服务器组成结构示意图；

图7为本发明实施例的计算机设备组成结构示意图。

具体实施方式

下面结合附图对技术方案的实施作进一步的详细描述。首先结合图1-1说明本申请的使用场景，在后台通过至少一个服务器组成的服务器集群提供多种业务的数据服务；通过中间的分布式消息队列系统获取后台更新后的数据并存储，由接入层从中间的分布式消息队列系统中获取存储队列中的数据；最后由接入层将存储队列中的数据发送到终端侧；终端侧可以有多种类型的设备，比如图中所示的智能手机、平板电脑、笔记本电脑等。

实施例一：

本发明实施例提供一种数据更新方法，如图1-2所示，包括：

步骤101：接收服务器推送的至少一条更新后的数据，将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；

步骤102：检测到接入层服务器发来的数据获取请求时，基于所述数据获取请求从所述存储队列中提取目标数据，将所述目标数据发送至所述接入层服务器所连接的终端。

这里，本实施例所提供的方法可以应用于服务器中，具体来说，可以应用于至少一个服务器组成的系统中，该系统可以具备以下功能：兼容amqp协议，amqp是应用层协议的一个开放标准，为面向消息的中间件设计；具有面向消息、队列、路由、可靠性、安全的主要特征。

本实施例提供的处理方法，可以参见图2的架构进行说明，后端数据一旦发生变化，主动通知给分布式消息队列系统，同时，在接入层，有个常驻的“准实时获取分布式消息队列系统变化数据的服务”，我们可以视为这个过程的时间差趋近为0。在接入层，可以准实时获取到变化数据，通过websocket推送给客户端。

其中，后端数据变化，后端服务只需要调用分布式消息队列系统的api，发送一个消息，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容。需要说明的是，后端的服务器数据发生变化由自身可以感知，一旦出现更新后的数据，就基于与中间的分布式消息队列系统中对应的写数据接口将更新后的数据发送到分布式消息队列系统中。

本申请中，获取推送的更新后的数据的消息的结构可以如下：

具体来说，上述business表征接入的业务；

actiontype表征消息的类型；比如，同一个业务下，会有多种消息类型；

data表征:变化的数据。前面的结构中并未给出具体的变化内容，仅为一个示例，在实际处理中data后面可以设置在某一个消息类型下发生变化的数据的具体内容，这里不进行举例说明。

服务端每次变化的数据，都包装成上述格式的消息并发出。

接入层，有一个常驻服务：“准实时获取crmq变化数据的服务”；其中，cmrp即分布式高可靠消息队列(cloudreliablemessagequeue)。通过前述服务能够准实时的获取crmq队列中的数据。因此，在接入层，能够及时的获取后端变化数据，从而通过websocket推送给用户侧。其中，实时获取crmq变化数据的服务可以通过以下方式来实现：一个while循环调用crmq体统的api，receivemsg。一旦取到了就继续取队列，直到取完这个队列的所有元素，当取不到的时候，就等待5毫秒(这样可以释放cpu,不至于这个程序卡死整个进程)；然后再重复上述过程。所以消息最大可能的延迟，就是5毫秒。

关于分布式消息队列系统，比如，可以为crmq即“分布式高可靠消息队列”(cloudreliablemessagequeue)，为分布式消息队列系统的一种实现方案。关于分布式消息队列系统内维护的存储队列建立方式可以包括以下几种：

第一种、即按照更新的数据到来的先后顺序，直接进行保存；

在第一种处理方式下，相应的，所述检测到接入层服务器发来的数据获取请求时，从所述存储队列中提取目标数据，还包括：

检测到接入层服务器发来的数据获取请求时，从所述数据获取请求中提取业务类型；基于所述业务类型，从所述存储队列中提取到与所述业务类型对应的目标数据。

第二种、基于所述至少一条更新后的数据中，每一条更新后的数据对应的业务类型，确定所述每一条更新后的数据的业务类型所对应的存储队列；将所述更新后的数据存储至其业务类型所对应的存储队列中。

在第二种方式中，根据不同的数据的业务类型(或者更细的划分为消息类型)，维护不同的业务类型的存储队列；那么相应的，在前端服务器需要获取业务的时候，就从所需获取的业务类型对应的存储队列中直接获取即可，避免了提取数据后再判断是否自己所需要的业务的过程，提升了处理效率。

具体来说，第二种方式下对应的，所述检测到接入层服务器发来的数据获取请求时，从所述存储队列中提取目标数据，还包括：

检测到接入层服务器发来的数据获取请求；从所述数据获取请求中提取得到所要获取的数据的业务类型；基于所述业务类型，选取对应的存储队列，从选取的所述存储队列中提取至少一条更新后的数据作为目标数据。

为了避免先来读取目标数据的接入层服务器将存储队列中的数据取走之后，其他接入层服务器无法读取数据的问题，本实施例提供了一旦接收到数据获取请求时就进行存储队列的复制，使得需要获取数据的接入层服务器从待用存储队列中提取目标数据；具体来说，所述检测到接入层服务器发来的数据获取请求时，基于所述数据获取请求从所述存储队列中提取目标数据，将所述目标数据发送至所述接入层服务器所连接的终端，包括：

检测到至少一个接入层服务器发来的数据获取请求时，基于所述数据获取请求，复制所述存储队列得到待用存储队列；

将所述待用存储队列中的至少一条更新后的数据作为所述目标数据，将所述目标数据发送至发来数据获取请求的接入层服务器所连接的终端。

比如，在第一时间接收到接入层服务器发来的数据获取请求时，就针对该请求进行存储队列的复制得到待用存储队列；将待用存储队列中的全部数据或至少部分数据作为目标数据发送给接入层服务器；在第二时间再次接收到其他接入层服务器的数据获取请求时，采用同样的操作进行目标数据的发送。

需要理解的是，为了识别是哪个接入层服务器发来的数据获取请求，还可以在数据获取请求中设置接入层服务器的标识信息，并将该数据获取请求与对应的待用存储队列进行关联。

另外，所述方法还包括：检测未接收到接入层服务器发来数据获取请求的时长；当所述时长超过预设门限值时，删除所述存储队列。也就是说，若当前保存的存储队列有超过一定时间未被读取时，可以删除存储队列，从而保证中间的分布式消息队列系统不会因为存储了较多的过期数据而影响其服务质量的问题。

与现有技术相比，比如，参见图3，在接入层去数据源“拉取数据”，并做“数据对比”(后面称之为“拉取-对比”)，发现变化数据后，通过websocket推送至用户客户端。所以后端数据变化后，需要等待接入层拉取数据后，并做对比，确定变化，才会触发websocket推送新数据到客户端。因为接入层不知道什么时候数据发生变化，所以要不断重复这个“拉取-对比”的过程。如果2次“拉取-对比”的间隔太长，那接入层感知后端数据变化的延迟就可能越高。如上图，如果后端在t01时刻发生数据变化，接入层在t12时刻发起“拉取-对比”，会经历t12-t01的间隔。接入层发现数据变化，推送到用户侧已经是t21，中间的网络传输花费t21-t12。所以最终耗时会是(t12-t01)+(t21-t12)。

这里的t12-t01存在最好和最坏情况：

最好情况是t01时刻后端发生数据变化，刚好紧接着接入层在t12时刻就做了一次“拉取-对比”，那t12-t01可以趋近于0。

最差情况是：接入层t11时刻做完“拉取-对比”，紧接着马上服务端在t01时刻发生数据变化。那t12-t01就趋近于(t12-t11)。

所以接入层“拉取-对比”间隔越长，那“最差情况”的间隔就越长，用户侧就可能越晚看到变化数据。

本申请是为了能够提供一种高效的通用的接入层数据变化推送方案。在实时网络应用中，数据是不断变化的，用户需要能够及时的看到数据的变化，所以一般在接入层采用websocket来推送实时数据。何时推送数据，推送什么数据，会涉及到去数据源拉取数据，并做对比的过程，这个过程需要多出几次机器之间的调用，消耗服务器资源，而且越要做到实时，需要更快频次的重复这个过程，所以，这里会存在一个冲突，要给服务器减压，就得牺牲一部分实时性。要增强实时性，就需要给服务器增加压力。并且这个过程在不同的业务形态下必定是有不同的实现，编码和维护的成本很高。

而本申请通过使用分布式消息队列系统作为中间存储媒介，后端数据变化，主动推送至分布式消息队列系统中，接入层直接获取分布式消息队列系统中存储的变化数据。这样的好处，是将数据获取，对比的过程直接移除了。接入层的逻辑更加简单了，而且，只要协议好消息的格式，这个过程，就能做成标准化，通用的模型，新业务接入，并不需要增加新的处理逻辑。

还需要指出的是，本实施例提供的分布式消息队列系统中可以为接入层服务器提供读取数据的接口，从而使得接入层服务器直接从读取数据的接口中获取存储队列中的目标数据即可。因此，本实施例由于可以提供较为简单的存储内容的寻址，使得需要寻址的设备通过较为简单的地址查询就可以获取到存储队列中的内容；而现有技术则需要通过较为复杂的路由从服务器中获取数据。

对比前述现有技术的方案，本实施例提供的方案，能够获取到主动推送来的发生更新的数据，在接入层服务器发来请求的时候，直接从存储队列中发送更新后的数据；从而摈弃了现有技术中“拉取-对比”的过程所带来的用户侧获取更新数据的时间延迟；并且，接入层服务器避免了从后端服务器直接获取数据的操作，从而节省了大量的服务器资源。

另外，本实施例还可以看出增加了后端服务器与中间的分布式消息队列系统中的消息的结构协议化；从而进一步的增加通用性，接入各种业务，适用的场景大大增加。

实施例二：

本发明实施例提供一种数据更新装置，如图4所示，包括：

存储单元41，用于接收服务器推送的至少一条更新后的数据；将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；

提取单元42，用于检测到接入层服务器发来的数据获取请求时，从所述存储队列中提取目标数据；

数据发送单元43，用于发送提取的所述目标数据至所述接入层服务器侧。

本实施例可以参见图2的架构进行说明，后端数据一旦发生变化，主动通知给分布式消息队列系统，同时，在接入层，有个常驻的“准实时获取分布式消息队列系统变化数据的服务”，我们可以视为这个过程的时间差趋近为0。在接入层，可以准实时获取到变化数据，通过websocket推送给客户端。

其中，后端数据变化，后端服务只需要调用分布式消息队列系统的api，发送一个消息，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容。需要说明的是，后端的服务器数据发生变化由自身可以感知，一旦出现更新后的数据，就基于与中间的分布式消息队列系统中对应的写数据接口将更新后的数据发送到分布式消息队列系统中。本申请中，获取推送的更新后的数据的消息的结构可以如下：

具体来说，上述business表征接入的业务；

actiontype表征消息的类型；比如，同一个业务下，会有多种消息类型；

data表征:变化的数据。前面的结构中并未给出具体的变化内容，仅为一个示例，在实际处理中data后面可以设置在某一个消息类型下发生变化的数据的具体内容，这里不进行举例说明。

服务端每次变化的数据，都包装成上述格式的消息并发出。

接入层，有一个常驻服务：“准实时获取crmq变化数据的服务”；其中，cmrp即分布式高可靠消息队列(cloudreliablemessagequeue)。它会准实时的获取crmq队列中的数据。因此，在接入层，能够及时的获取后端变化数据，从而通过websocket推送给用户侧。

关于分布式消息队列系统内维护的存储队列建立方式可以包括以下几种：

第一种、所述存储单元，用于即按照更新的数据到来的先后顺序，直接进行保存；

在第一种处理方式下，相应的，所述提取单元，用于检测到接入层服务器发来的数据获取请求时，从所述数据获取请求中提取业务类型；基于所述业务类型，从所述存储队列中提取到与所述业务类型对应的目标数据。

第二种、所述存储单元，用于基于所述至少一条更新后的数据中，每一条更新后的数据对应的业务类型，确定所述每一条更新后的数据的业务类型所对应的存储队列；将所述更新后的数据存储至其业务类型所对应的存储队列中。

在第二种方式中，根据不同的数据的业务类型(或者更细的划分为消息类型)，维护不同的业务类型的存储队列；那么相应的，在前端服务器需要获取业务的时候，就从所需获取的业务类型对应的存储队列中直接获取即可，避免了提取数据后再判断是否自己所需要的业务的过程，提升了处理效率。

具体来说，第二种方式下对应的，所述提取单元，用于检测到接入层服务器发来的数据获取请求；从所述数据获取请求中提取得到所要获取的数据的业务类型；基于所述业务类型，选取对应的存储队列，从选取的所述存储队列中提取至少一条更新后的数据作为目标数据。

为了避免先来读取目标数据的接入层服务器将存储队列中的数据取走之后，其他接入层服务器无法读取数据的问题，本实施例提供了一旦接收到数据获取请求时就进行存储队列的复制，使得需要获取数据的接入层服务器从待用存储队列中提取目标数据；具体来说，提取单元42，用于检测到至少一个接入层服务器发来的数据获取请求时，基于所述数据获取请求，复制所述存储队列得到待用存储队列；

数据发送单元43，用于将所述待用存储队列中的至少一条更新后的数据作为所述目标数据，将所述目标数据发送至发来数据获取请求的接入层服务器所连接的终端。

比如，在第一时间接收到接入层服务器发来的数据获取请求时，就针对该请求进行存储队列的复制得到待用存储队列；将待用存储队列中的全部数据或至少部分数据作为目标数据发送给接入层服务器；在第二时间再次接收到其他接入层服务器的数据获取请求时，采用同样的操作进行目标数据的发送。

需要理解的是，为了识别是哪个接入层服务器发来的数据获取请求，还可以在数据获取请求中设置接入层服务器的标识信息，并将该数据获取请求与对应的待用存储队列进行关联。

另外，存储单元41，用于检测未接收到接入层服务器发来数据获取请求的时长；当所述时长超过预设门限值时，删除所述存储队列。也就是说，若当前保存的存储队列有超过一定时间未被读取时，可以删除存储队列，从而保证中间的分布式消息队列系统不会因为存储了较多的过期数据而影响其服务质量的问题。

与现有技术相比，比如，参见图3，在接入层去数据源“拉取数据”，并做“数据对比”(后面称之为“拉取-对比”)，发现变化数据后，通过websocket推送至用户客户端。所以后端数据变化后，需要等待接入层拉取数据后，并做对比，确定变化，才会触发websocket推送新数据到客户端。因为接入层不知道什么时候数据发生变化，所以要不断重复这个“拉取-对比”的过程。如果2次“拉取-对比”的间隔太长，那接入层感知后端数据变化的延迟就可能越高。如上图，如果后端在t01时刻发生数据变化，接入层在t12时刻发起“拉取-对比”，会经历t12-t01的间隔。接入层发现数据变化，推送到用户侧已经是t21，中间的网络传输花费t21-t12。所以最终耗时会是(t12-t01)+(t21-t12)。

这里的t12-t01存在最好和最坏情况：

最好情况是t01时刻后端发生数据变化，刚好紧接着接入层在t12时刻就做了一次“拉取-对比”，那t12-t01可以趋近于0。

最差情况是：接入层t11时刻做完“拉取-对比”，紧接着马上服务端在t01时刻发生数据变化。那t12-t01就趋近于(t12-t11)。

所以接入层“拉取-对比”间隔越长，那“最差情况”的间隔就越长，用户侧就可能越晚看到变化数据。

对比前述现有技术的方案，本实施例提供的方案，能够获取到主动推送来的发生更新的数据，在接入层服务器发来请求的时候，直接从存储队列中发送更新后的数据；从而摈弃了现有技术中“拉取-对比”的过程所带来的用户侧获取更新数据的时间延迟；并且，接入层服务器避免了从后端服务器直接获取数据的操作，从而节省了大量的服务器资源。

另外，本实施例还可以看出增加了后端服务器与中间的分布式消息队列系统中的消息的结构协议化；从而进一步的增加通用性，接入各种业务，适用的场景大大增加。

实施例三：

本发明实施例提供一种数据更新系统，如图5所示，包括：

分布式消息队列系统51，用于接收服务器推送的至少一条更新后的数据，将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；

服务器52，用于推送所述至少一条更新后的数据至分布式消息队列系统；

接入层服务器53，用于从所述分布式消息队列系统的存储队列中提取目标数据。

本实施例可以参见图2的架构进行说明，后端数据一旦发生变化，主动通知给分布式消息队列系统，同时，在接入层，有个常驻的“准实时获取分布式消息队列系统变化数据的服务”，我们可以视为这个过程的时间差趋近为0。在接入层，可以准实时获取到变化数据，通过websocket推送给客户端。

如图6所示，所述服务器，包括：

检测单元61，用于检测至少一个业务类型中每一个业务类型是否出现发生变化的数据内容；

更新单元62，用于检测到业务类型对应的数据发生变化时，基于发生变化的数据的内容、以及所述业务类型生成更新后的数据；

推送单元63，用于基于预设的消息结构对更新后的数据进行封装，主动将封装的更新后的数据推送至分布式消息队列系统。

其中，后端数据变化，后端服务只需要调用分布式消息队列系统的api，发送一个消息，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容。本申请中，获取推送的更新后的数据的消息的结构可以如下：

具体来说，上述business表征接入的业务；

actiontype表征消息的类型；比如，同一个业务下，会有多种消息类型；

data表征:变化的数据。前面的结构中并未给出具体的变化内容，仅为一个示例，在实际处理中data后面可以设置在某一个消息类型下发生变化的数据的具体内容，这里不进行举例说明。

服务端每次变化的数据，都包装成上述格式的消息并发出。

接入层，有一个常驻服务：“准实时获取crmq变化数据的服务”。它会准实时的获取crmq队列中的数据。因此，在接入层，能够及时的获取后端变化数据，从而通过websocket推送给用户侧。

关于分布式消息队列系统内维护的存储队列建立方式可以包括以下几种：

第一种、所述存储单元，用于即按照更新的数据到来的先后顺序，直接进行保存；

在第一种处理方式下，相应的，所述提取单元，用于检测到接入层服务器发来的数据获取请求时，从所述数据获取请求中提取业务类型；基于所述业务类型，从所述存储队列中提取到与所述业务类型对应的目标数据。

第二种、所述存储单元，用于基于所述至少一条更新后的数据中，每一条更新后的数据对应的业务类型，确定所述每一条更新后的数据的业务类型所对应的存储队列；将所述更新后的数据存储至其业务类型所对应的存储队列中。

在第二种方式中，根据不同的数据的业务类型(或者更细的划分为消息类型)，维护不同的业务类型的存储队列；那么相应的，在前端服务器需要获取业务的时候，就从所需获取的业务类型对应的存储队列中直接获取即可，避免了提取数据后再判断是否自己所需要的业务的过程，提升了处理效率。

具体来说，第二种方式下对应的，所述提取单元，用于检测到接入层服务器发来的数据获取请求；从所述数据获取请求中提取得到所要获取的数据的业务类型；基于所述业务类型，选取对应的存储队列，从选取的所述存储队列中提取至少一条更新后的数据作为目标数据。

与现有技术相比，比如，参见图3，在接入层去数据源“拉取数据”，并做“数据对比”(后面称之为“拉取-对比”)，发现变化数据后，通过websocket推送至用户客户端。所以后端数据变化后，需要等待接入层拉取数据后，并做对比，确定变化，才会触发websocket推送新数据到客户端。因为接入层不知道什么时候数据发生变化，所以要不断重复这个“拉取-对比”的过程。如果2次“拉取-对比”的间隔太长，那接入层感知后端数据变化的延迟就可能越高。如上图，如果后端在t01时刻发生数据变化，接入层在t12时刻发起“拉取-对比”，会经历t12-t01的间隔。接入层发现数据变化，推送到用户侧已经是t21，中间的网络传输花费t21-t12。所以最终耗时会是(t12-t01)+(t21-t12)。

这里的t12-t01存在最好和最坏情况：

最好情况是t01时刻后端发生数据变化，刚好紧接着接入层在t12时刻就做了一次“拉取-对比”，那t12-t01可以趋近于0。

最差情况是：接入层t11时刻做完“拉取-对比”，紧接着马上服务端在t01时刻发生数据变化。那t12-t01就趋近于(t12-t11)。

所以接入层“拉取-对比”间隔越长，那“最差情况”的间隔就越长，用户侧就可能越晚看到变化数据。

对比前述现有技术的方案，本实施例提供的方案，能够获取到主动推送来的发生更新的数据，在接入层服务器发来请求的时候，直接从存储队列中发送更新后的数据；从而摈弃了现有技术中“拉取-对比”的过程所带来的用户侧获取更新数据的时间延迟；并且，接入层服务器避免了从后端服务器直接获取数据的操作，从而节省了大量的服务器资源。

另外，本实施例还可以看出增加了后端服务器与中间的分布式消息队列系统中的消息的结构协议化；从而进一步的增加通用性，接入各种业务，适用的场景大大增加。

本发明实施例还提供了一种计算机设备，可以如图7所示，包括：处理器701和用于存储能够在处理器上运行的计算机程序的存储器703。

其中，存储器703可用于存储软件程序以及模块，如本发明实施例中的提取单元；

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

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

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

处理器701可以通过调用存储器703存储的应用程序，以执行下述步骤：接收服务器推送的至少一条更新后的数据，将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；基于所述数据获取请求从所述存储队列中提取目标数据，将所述目标数据发送至所述接入层服务器所连接的终端。

处理器701还用于执行下述步骤：检测到至少一个接入层服务器发来的数据获取请求时，基于所述数据获取请求，复制所述存储队列得到待用存储队列；

将所述待用存储队列中的至少一条更新后的数据作为所述目标数据，将所述目标数据发送至发来数据获取请求的接入层服务器所连接的终端。

处理器701还用于执行下述步骤：检测未接收到接入层服务器发来数据获取请求的时长；

当所述时长超过预设门限值时，删除所述存储队列。

处理器701还用于执行下述步骤：基于所述至少一条更新后的数据中，每一条更新后的数据对应的业务类型，确定所述每一条更新后的数据的业务类型所对应的存储队列；

将所述更新后的数据存储至其业务类型所对应的存储队列中。

处理器701还用于执行下述步骤：检测到接入层服务器发来的数据获取请求；

从所述数据获取请求中提取得到所要获取的数据的业务类型；

基于所述业务类型，选取对应的存储队列，从选取的所述存储队列中提取至少一条更新后的数据作为目标数据。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以存储用于执行数据更新方法的程序代码。

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

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

接收服务器推送的至少一条更新后的数据，将所述至少一条更新后的数据保存至存储队列中；其中，所述至少一条更新后的数据中包含有业务类型、以及发生变化的数据的内容；

检测到接入层服务器发来的数据获取请求时，基于所述数据获取请求从所述存储队列中提取目标数据，将所述目标数据发送至所述接入层服务器所连接的终端。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：检测到至少一个接入层服务器发来的数据获取请求时，基于所述数据获取请求，复制所述存储队列得到待用存储队列；

将所述待用存储队列中的至少一条更新后的数据作为所述目标数据，将所述目标数据发送至发来数据获取请求的接入层服务器所连接的终端。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：检测未接收到接入层服务器发来数据获取请求的时长；

当所述时长超过预设门限值时，删除所述存储队列。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：基于所述至少一条更新后的数据中，每一条更新后的数据对应的业务类型，确定所述每一条更新后的数据的业务类型所对应的存储队列；

将所述更新后的数据存储至其业务类型所对应的存储队列中。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：检测到接入层服务器发来的数据获取请求；

从所述数据获取请求中提取得到所要获取的数据的业务类型；

基于所述业务类型，选取对应的存储队列，从选取的所述存储队列中提取至少一条更新后的数据作为目标数据。

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

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

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。