一种数据分发和更新方法、装置、设备和存储介质

技术领域

本申请涉及分布式平台技术，尤其涉及一种数据分发和更新方法、装置、设备和存储介质。

背景技术

相关技术中，在业务服务调用过程中，服务平台的服务集群内服务在做业务校验时会从本地缓存中获取相应的业务数据，这些业务数据会至少存储在服务平台的一级缓存或二级缓存(一级缓存的读取速度大于二级缓存)中，以保证读取速度；因此，需要将服务平台的二级缓存中的数据分发给服务平台的本地缓存中。

在将服务平台的二级缓存中数据分发给服务平台的服务集群中的本地缓存的过程中，采用了缓存分类分发方案，在缓存分类分发的方案中，由于分发流程没有与业务服务器很好地进行解耦，在系统扩容加服务器时，也必须要使用各种方式去更改配置，无法满足动态自动可扩展性，同时若将其应用在高并发分布式平台的业务场景中，在高性能方面亦无法保障。

发明内容

本申请实施例期望提供一种数据分发方法、装置、设备和计算机存储介质。

第一方面，本申请实施例提供了一种数据分发方法，应用于数据分发设备，包括：

实时获取服务平台的二级缓存中特定类型的数据的变化信息；

根据所述特定类型的数据的变化信息确定所述特定类型的数据的变化类型；

基于所述数据的变化类型生成可靠消息数据；

向所述服务平台的服务集群分发所述可靠消息数据，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步。

第二方面，本申请实施例提供了一种数据更新方法，应用于服务平台的服务集群，包括：

接收数据分发设备发送的可靠消息数据，所述可靠消息数据是根据所述服务平台中的二级缓存中的变化数据生成的；

接收与所述可靠消息数据的数据类型相同的数据；

基于所述可靠消息数据对所述服务平台中本地缓存中的数据进行更新，使得更新后的所述本地缓存中的数据与所述二级缓存中的数据相同。

第三方面，本申请实施例提供了一种数据分发装置，包括：

获取模块，用于实时获取服务平台的二级缓存中特定类型的数据的变化信息；

第一确定模块，用于根据所述特定类型的数据的变化信息确定所述特定类型的数据的变化类型；

生成模块，用于基于所述数据的变化类型生成可靠消息数据；

分发模块，用于向所述服务平台的服务集群分发所述可靠消息数据，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步。

第四方面，本申请公开实施例还提供了一种数据分发设备，包括存储器和处理器，

所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项所述数据分发方法中的步骤。

第五方面，本申请实施例还提供了一种计算机可读存储介质，该计算机程序被处理器执行时实现上述任一项所述数据分发方法中的步骤和上述所述服务平台的本地缓存中的数据更新方法中的步骤。

在本申请实施例中，通过独立于服务平台的数据分发设备实时获取服务平台的二级缓存中特定类型的数据的变化信息，并基于根据特定类型的数据的变化信息所确定的数据变化类型生成可靠消息数据，并将可靠数据分发给服务平台，使得服务平台中的本地缓存与二级缓存中的数据同步的。由于二级缓存种数据的分发是由数据分发设备完成的，并不是由业务服务器本身来完成，分发流程与业务服务器很好地进行了解耦，在系统扩容服务器时无必须要使用各种方式去更改配置，可以满足动态自动可扩展性。同时，若将其应用在高并发分布式平台的业务场景中，在高性能方面亦可以得到保障。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。

图1为本申请实施例提供的一种数据分发方法的实现流程示意图；

图2为本申请实施例提供的另一种数据分发方法的实现流程示意图；

图3为本申请实施例提供的一种数据更新方法的实现流程图；

图4为本申请实施例提供的一种服务平台的缓存分发组网图；

图5为本申请实施例提供的一种本地换出器的组成结构示意图；

图6为本申请实施例提供的一种数据分发装置的组成结构示意图；

图7为本申请实施例提供的一种服务平台的本地缓存中的数据更新装置的组成结构示意图；

图8为本申请实施例提供的一种数据分发设备的结构示意图。

具体实施方式

以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本申请，并不用于限定本申请。另外，以下所提供的实施例是用于实施本申请的部分实施例，而非提供实施本申请的全部实施例，在不冲突的情况下，本申请实施例记载的技术方案可以任意组合的方式实施。

需要说明的是，在本申请实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其他要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分电路、部分处理器、部分程序或软件等等)。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，U和/或W，可以表示：单独存在U，同时存在U和W，单独存在W这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括U、W、V中的至少一种，可以表示包括从U、W和V构成的集合中选择的任意一个或多个元素。

为推动“大众创业，万众创新”，高并发分布式服务平台xxx聚合千百万内外开发者，聚拢了百万应用，同时为推进这些应用的快速孵化，高并发分布式服务平台xxx为这些应用提供包括语音服务、短彩信服务、位置服务、视频服务等。由于开发者众多，高并发分布式服务平台xxx针对各项业务服务进行了分布式部署，每项业务服务都对应一套服务器集群，便于更细化的扩缩容。

各项业务服务应用服务程序接口(Application Programming Interface，API)在被调用的过程中，高并发分布式服务平台xxx会做出诸如应用Key校验、码号校验、白名单校验、套餐使用校验等一系列校验过程，此类数据往往读多写少，一般至少会存储于在Redis集群(后续统称二级缓存)以保障读取速度。但尽管二级缓存速度已经够快，但读取时还是涉及到了网络IO，在各类购物节大促期间，容易对二级缓存造成太大的压力，若需满足万级一秒内成功完成的事务数(Trasaction Per Second，TPS)的吞吐要求，不仅仅需要对业务服务集群进行扩容，还需对二级缓存进行扩容，不仅仅浪费了资源，还影响到了系统的稳定性。引入分布式本地缓存，能保障读取缓存时的高速，降低了调用的延迟时间，大大提高整个高并发分布式服务平台xxx的吞吐量。

现有的分布式本地缓存相关的技术中，也提出了一些解决方案。其中，在缓存格式方面以及缓存分发的通信机制和协议方面都有适应不同业务场景的解决方案。例如，在一些技术方案中，本地缓存的构建与分发采用集群内服务器相互广播通知的机制外加缓存版本号校验的方式来保证集群内每一台服务器的本地缓存一致性。在另一些技术方案中，在数据分发方面分别采用了WebSocket直连分发、代理服务器分发、可配置数据分发归档的方式对缓存进行了分类处理，也采用了各种不同的容器对缓存进行了存储，方便使用时便捷快速地获取。对于高并发的分布式平台，为其建立的本地一级缓存需满足以下三大特性：

(1)、可靠可扩展，即一级缓存不能出现不在二级缓存范围内的脏数据，同时各大业务分布式集群可方便扩容且无需额外人工介入。

(2)、高速高性能，一级缓存虽然已经很快(因为直接在服务器本地内存中)，但我们需要最优的容器使得检索时速度达到最快，同时缓存分发动态变化的流程设计应尽量与业务流程解耦，防止占用过多业务服务器的资源，影响业务性能。

(3)、分类节能，现代服务平台均采用分布式部署，每套集群作用不一，一级缓存也应分类存储，减少每台服务器所需申请的总内存。

现有的技术中关于分布式本地缓存的方案均无法同时满足上述要求，一些技术方案尽管满足了可靠可扩展性，但其缓存的分发还是需由业务服务器本身来完成，同时也没有对缓存进行分类，在高速高性能和分类节能性方面便无法满足；另一些技术方案中存在各自有自己的协议与通信机制来满足缓存的分类分发，但没有去考虑分发的过程中是否存在脏数据(漏发、老数据重复发等)，数据不一定可靠(部分业务场景允许，而高并发分布式平台不允许)；大部分采取了缓存分类分发的方案中，由于分发流程没有与业务服务器很好地进行解耦，在系统扩容加服务器时，也必须要使用各种方式去更改配置，无法满足动态自动可扩展性，同时若将其应用在高并发分布式平台的业务场景中，在高性能方面亦无法保障。

基于上述高并发分布式平台所需解决的技术问题，本申请实施例在缓存模型的建立以及分发流程的设计方面均进行了完整的优化，同时满足上述所提的三大特性。

图1为本申请实施例提供的一种数据分发方法的实现流程示意图，如图1所示，所述流程包括：

步骤S101：实时获取所述服务平台的二级缓存中特定类型的数据的变化信息；

可以理解的是，服务平台可以是高并发分布式服务平台；服务平台的二级缓存可以是Redis集群。

这里，Redis集群中的数据的存储格式为键值存储的格式。

其中，key的结构可以分为两部分，apiType与apiFunction，通过冒号相连，形成{apiType}:{apiFunction}字符串结构，apiType表示分业务集群类型，不同的集群的apiType根据集群类型各有不同，是缓存分类的核心所在；例如，vioce表示语音类型；sms表示短彩信类型；position表示位置类型；vidio表示视频类型；apiFunction与具体业务功能相关；value的结构也分为两部分，lastUpdateTime与content，lastUpdateTime表示该条数据上一次更新时间，防止极端情况分发消息与本地缓存自更新数据冲突；content为具体的业务缓存值，如有效码号、订单、模板等等和自定义的业务数据，lastUpdateTime将在本地缓存以任意形式发生变化时进行时钟对比，防止出现脏数据。

一种可能的实施方式中，特定类型包括以下至少之一：语音类、视频类、短彩信类和位置类。

可以理解的是，特定类型的数据的变化信息可以是指定监听的key的正则表达式的动态变化信息。例如，特定类型的数据的变换信息可以通过监听语音类、视频类、短彩信类和位置类对应的正则表达式来提取出语音类、视频类、短彩信类和位置类数据的变化信息。

在一种可能的实施方式中，语音类、视频类、短彩信类和位置类数据的变化信息可以是语音类、视频类、短彩信类和位置类数据的键和值得变化数据。

步骤S102：根据所述特定类型的数据的变化信息确定所述特定类型的数据的变化类型；

在一些实施例中，变化类型包括以下至少之一：新增、删除和更新。

在一些可能的实施方式中，根据所述特定类型的数据的变化信息确定所述特定类型的数据的变化类型，可以是根据语音类、视频类、短彩信类和位置类数据的键和值得变化数据分别确定语音类、视频类、短彩信类和位置类数据的变化类型。例如，语音类、视频类、短彩信类和位置类数据的变化类型可以是分别是删除、新增、更新和删除。

步骤S103：基于所述数据的变化类型生成可靠消息数据；

在一些可能的实施方式中，可靠消息数据可以是由topic和value两部分构成的数据格式，其中，topic中的apiType与具体发生变化缓存的key部分的apiType一致，而可靠消息数据中的value，由三部分组成，opType、cacheKey、cacheValue，opType将根据操作类型对本地缓存进行对应的操作，而cacheKey、cacheValue对应发生变化缓存的key和value。

在一个示例中，基于所述数据的变化类型生成可靠消息数据，可以是根据数据的变换类型确定变化数据的操作类型，将变化数据的操作类型作为可靠消息数据的组成部分，生成可靠消息数据。

步骤S104：向所述服务平台的服务集群分发所述可靠消息数据，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步。

可以理解的是，服务平台可以是预先设置不同服务类型的服务集群；例如，服务平台的服务集群可以包括语音服务集群、短彩信服务集群、位置服务集群和视频服务集群等服务类型的服务集群。服务平台中的二级缓存中的数据需要更新到服务平台中的本地缓存中，即，将服务平台中的二级缓存中的数据更新到对应类型的服务集群的本地缓存中。

这里，服务器平台中的本地缓存可以是按照业务服务的类型对应设置的服务器集群中的本地缓存。例如，对于业务服务的类型为语音服务的情况，服务器平台中设置对应语音服务的服务器集群中的本地集群1；对于业务服务的类型为位置服务的情况，服务器平台中设置对应位置服务的服务器集群中的本地集群2。

在一些可能的实施方式中，向所述服务平台分的服务集群发所述可靠消息数据，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步，可以是数据分发设备根据可靠消息数据的topic中的apiType，自动将可靠消息数据推送至对应的集群的服务器内部，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步。这里，可靠消息数据推送可以通过分类广播的方式进行推送，且可以将保障缓存变化消息准确且绝对的送达。

在实际应用中，步骤101至步骤104可以利用数据分发设备的处理器实现，上述处理器可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital SignalProcessing Device，DSPD)、可编程逻辑装置(Programmable Logic Device，PLD)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、中央处理器(Central ProcessingUnit，CPU)、控制器、微控制器、微处理器中的至少一种。

本申请实施例中，通过独立于服务平台的数据分发设备实时获取服务平台的二级缓存中特定类型的数据的变化信息，并基于根据特定类型的数据的变化信息所确定的数据变化类型生成可靠消息数据，并将可靠数据分发给服务平台，使得服务平台中的本地缓存与二级缓存中的数据同步的。由于二级缓存种数据的分发是由数据分发设备完成的，并不是由业务服务器本身来完成，分发流程与业务服务器很好地进行了解耦，在系统扩容服务器时无必须要使用各种方式去更改配置，可以满足动态自动可扩展性。同时，若将其应用在高并发分布式平台的业务场景中，在高性能方面亦可以得到保障。

图2为本申请实施例提供的另一种数据分发方法的实现流程示意图，如图2所示，所述流程包括：

步骤S201：根据需求确定待存入服务平台中的本地缓存的数据的类型为特定类型；

在一些可能的实施方式中，根据需求确定待存入服务平台中的本地缓存的数据的类型为特定类型，可以是数据分发设备基于获取的外部需求输入指令，响应需求输入指令确定将待存入服务平台中的本地缓存的数据的类型，并将待存入服务平台中的本地缓存的数据的类型确定为特定类型。

在一个示例中，在外部需求输入指令对应语音类、视频类、短彩信类和位置类数据均为待存入服务平台中的本地缓存中的数据的情况下，确定语音类、视频类、短彩信类和位置类为特定类型。

在另一个示例中，在外部需求输入指令对应语音类和视频类数据均为待存入服务平台中的本地缓存中的数据的情况下，确定语音类和视频类为特定类型。

步骤S202：实时获取当前时刻和上一时刻所述服务平台的二级缓存中所述特定类型的数据；所述二级缓存中的数据存储格式为键值存储；

在一种可能的实施方式中，实时获取当前时刻和上一时刻所述服务平台的二级缓存中所述特定类型的数据，可以是在特定类型的数据为语音类数据和视频类数据的情况下，实时监听服务平台的二级缓存中的语音类数据和视频类数据，从而获取当前时刻和上一时刻服务平台的二级缓存中的语音类数据和视频类数据。

步骤S203：基于当前时刻和上一时刻所述二级缓存中所述特定类型的数据确定所述二级缓存中特定类型的数据的变化信息；

可以理解的是，特定类型的数据的变化信息可以是当前时刻和上一时刻的二级缓存中特定类型的数据中发生变化的数据。例如，在特定类型为语音类和位置类的情况下，特定类型的数据的变化信息是当前时刻的语音类数据和位置类数据中，与上一时刻的语音类类数据和位置类数据相比，发生变化的语音类数据和位置类数据。

在一些可能的实施方式中，基于当前时刻和上一时刻所述二级缓存中所述特定类型的数据确定所述二级缓存中特定类型的数据的变化信息，可以是在特定类型的数据为语音类数据和位置类数据的情况下，比较当前时刻和上一时刻的二级缓存中的语音数据，得到第一比较结果；比较当前时刻和上一时刻的二级缓存中的位置数据，得到第二比较结果；根据第一比较结果确定语音数据的变化信息；根据第二比较结果确定位置数据的变化信息；将语言数据的变换信息和位置数据的变化信息确定为二级缓存中特定类型的数据的变化信息。

步骤S204：根据所述特定类型的数据的变化信息确定所述特定类型的数据的变化类型；

步骤S205：根据所述特定类型的数据的变化信息确定变化数据的类型、键和值；

可以理解的是，变化数据的类型可以是特定类型的数据中发生变化的数据的类型。例如，特定类型的数据为语音类、视频类、短彩信类和位置类数据，但仅语音类数据和短彩信类数据发生变化的情况下，可以将语音类和短彩信类确定为变化数据的类型。

在一些可能的实施方式中，根据所述特定类型的数据的变化信息确定变化数据的类型、键和值，可以是在特定类型的数据为语音类、视频类、短彩信类和位置类数据，但仅语音类数据和短彩信类数据发生变化的情况下，将语音类和短彩信类确定为变化数据的类型，将发生变化的语音类数据和短彩信类数据的键和值，确定为变化数据的键和值。

可以理解的是，发生变化的语音类数据和短彩信类数据至少包括以下几种类型的变化：更新(语音类数据和短彩信类数据的键和值均发生变化、值不变键发生变化、键不变值发生变化)、新增(语音类数据和短彩信类数据新增的键和值)、删除(语音类数据和短彩信类数据删除的键和值)。

步骤S206：将所述变化数据的变化类型确定为所述变化数据的操作类型；

可以理解的是，通过比较当前时刻和上一时刻特定类型数据的变化可以确定特定类型数据中的变化数据的变化类型。例如，对于语音类数据和位置数据，当前时刻的语音数据不存在语音A，但存在位置B，而上一时刻的语音数据中存在语音A，但不存在位置B，因此，可以确定语音类变化数据的变化类型为删除操作，位置类变换数据的变化类型为新增操作。

在一些可能的实施方式中，将所述变化数据的变化类型确定为所述变化数据的操作类型，可以是在语音类变化数据的变化类型为删除操作类型，在位置类变化数据的变化类型为新增操作的情况下，确定语音类变化数据的操作类型为删除；确定位置类变化数据的操作类型为新增。

步骤S207：基于所述变化数据的类型、操作类型、键和值生成所述可靠消息数据；

在一些可能的实施方式中，基于所述变化数据的类型、操作类型、键和值生成所述可靠消息数据，可以是将变化数据的类型确定为可靠消息数据的topic中的apiType，将变化数据的操作类型确定为可靠消息数据中的value的opType；将变化数据的键确定为可靠消息数据中的value的cacheKey；将变化数据的值确定为可靠消息数据中的value的cacheValue，从而得到可靠消息数据。

步骤S208：向所述服务平台的服务集群分发所述可靠消息数据，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步。

本申请实施例中，根据需求确定待存入本地缓存的数据的类型为特定类型，基于实时获取的当前时刻和上一时刻二级缓存中特定类型的数据，确定二级缓存中特定类型的数据的变化信息，如此，可以基于确定的特定类型的数据的变化信息生成可靠消息数据，实现服务平台中的本地缓存与二级缓存中的数据的同步；根据特定类型的数据的变化信息确定变化数据的类型、键和值，所述变化数据的变化类型确定为所述变化数据的操作类型；基于所述变化数据的类型、操作类型、键和值生成可靠消息数据，基于生成的可靠消息数据可以实现对缓存数据的分类分发。

在一些实施例中，所述特定类型包括以下至少之一：语音类、视频类、短彩信类和位置类。

在一些实施例中，所述变化类型包括以下至少之一：新增、删除和更新。

在上述实施例的基础上，本申请实施例提供一种数据更新方法，应用于服务平台的服务集群，如图3所示，所述方法包括：

步骤S301：接收数据分发设备发送的可靠消息数据，所述可靠消息数据是根据所述服务平台中的二级缓存中的变化数据生成的；

步骤S302：接收与所述可靠消息数据的数据类型相同的数据；

在一些可能的实施方式中，接收与所述可靠消息数据的数据类型相同的数据，可以是于可靠消息数据中数据的类型对应的服务集群接收与可靠消息数据的数据类型相同的数据。

步骤S303：基于所述可靠消息数据对所述服务平台中本地缓存中的数据进行更新，使得更新后的所述本地缓存中的数据与所述二级缓存中的数据相同。

在一些实施方式中，所述本地缓存与所述二级缓存的数据存储格式均为键值存储。

本申请实施例为解决上述提出的三大特性，设计了一套新的缓存分发组件。缓存分发组件与业务服务平台呈解耦设计，方便业务服务平台的横向扩展与扩容，其主要由两部分组成：二级缓存监听集群以及可靠消息队列集群(为使得消息可靠不丢失，技术选型为RocketMq)。缓存分发组件能够监听二级缓存中指定数据(一般是根据Key的正则表达式)的动态变化信息，封装成可靠消息放置于消息队列中，而平台内不同的业务集群配置不同种类的缓存需求(消息topic的正则表达式)并连接消息队列，消息队列将完成自动分发。同时，本方案针对该流程设计了配套的缓存数据模型以及选型了最优的缓存容器，最大程度保障其达到生产级标准。

图4为本申请实施例提供的一种服务平台的缓存分发组网图，如图4所示，服务平台40中的平台业务服务集群分成了语音服务401、短彩信服务402、位置服务403、视频服务404四大类(举例)，每套集群内部的每台服务器均配置有本地缓存，本地缓存容器技术选型为caffeine，如图5所示，本地缓存容器50包含业务数据501和容器配置502两部分，容器配置502中包括初始容量配置502’、最大容量配置502”和超过最大容量逐出策略配置502”’。本地缓存容器50可根据服务器的内存配置适当的容量用于本地缓存，同时可配置本地缓存数据超出最大容量后的逐出策略(最近最少频率使用的业务数据条目被逐出)，这样，不仅仅能保障集群内存不会爆炸而使得服务终止，也能最大限度保障业务调用过程中，本地缓存的业务数据命中率。

同时为与二级缓存(Redis集群)保持数据的一致性且能保障与集群类型关联的分类性，如图4所示，本地缓存的业务数据格式采用与Redis数据存储格式一致的key&value结构，其中key的结构分为两部分，apiType与apiFunction，冒号相连，形成{apiType}:{apiFunction}字符串结构，不同的集群的apiType根据集群类型各有不同，是缓存分类的核心所在，apiFunction与具体业务功能相关；value的结构也分为两部分，lastUpdateTime与content，content为具体的业务数据，lastUpdateTime将在本地缓存以任意形式发生变化时进行时钟对比，防止出现脏数据。

另外为保障缓存分发组件能够将缓存正确得分发到对应的集群内部，如图1所示，该分发消息的topic将与具体发生变化缓存的key部分的apiType一致，而分发消息的消息value，由三部分组成，opType、cacheKey、cacheValue，其中opType将根据操作类型对本地缓存进行对应的操作，而cacheKey、cacheValue对应发生变化缓存的key、value。

图4中，缓存分发组件41包括二级缓存监听集群411和可靠消息队列412；下面将详细针对图4组网图的1-*、2-*、3-*部分详细阐述双创服务平台本地缓存的使用、分发、变化的过程。

1-*流程

1-*流程与大多一级缓存使用流程类似，在业务服务调用过程中，平台业务服务集群内服务在做业务校验时会从本地缓存中获取相应的业务数据，若不存在，将会从二级缓存405中获取，同时将获取到的数据更新至本地缓存容器中，更新的过程若发现已有数据(可能恰好缓存分发组件也将该条数据分发至对应集群内)，比较数据的lastUpdateTime字段，以最新的数据为准。该流程保障了各个集群扩容后新启动的服务器也能及时地填充所需数据至本地缓存容器。

2-*流程

2-*流程为缓存分发组件41的核心功能，缓存分发组件将根据需求监听所需缓存Key在二级缓存中的变化(如图4所述，将监听缓存键Key以voice:，sms:，position:，video:开头的数据)。变化包括新增、删除、更新，将变化的数据获取到后，截取Key的apiType部分作为分发消息的topic的apiType，将缓存与变化类型结合作为分发消息的内容，投递到可靠消息队列412中。

3-*流程

3-*流程中，服务平台40内不同的业务服务集群，根据业务服务集群的类型配置需要获取的apiType消息，并连接上可靠消息队列412，而可靠消息队列中的只要存在消息，就会根据消息的topic(此处为apiType)，自动将消息推送至对应的类型的业务服务集群的服务器内部，是一种分类广播的方式，可靠消息队列412将保障缓存变化消息准确且绝对的送达。业务服务集群内服务器在收到对应消息后根据消息内容，若消息内容中的操作类型为del，根据cacheKey，则将删除本地缓存容器中对应的key的相关数据；若消息内容中的操作类型为put，则将根据cacheValue中的lastUpdateTime与当前容器中的数据做对比，择新更新。同时在业务服务集群扩容的过程中无需额外配置，分类广播的方式将保障新扩容的服务器也能及时收到后续的更新消息。

其中，put表示新增或者更新；del表示删除。

基于前述的实施例，本申请实施例提供一种数据分发装置，该装置包括所包括的各单元、以及各单元所包括的各模块，可以通过商品知识扩展设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU)、微处理器(Microprocessor Unit，MPU)、数字信号处理器(DSP)或现场可编程门阵列(FPGA)等。

图6为本申请实施例提供的一种数据分发装置的组成结构示意图，如图6所示，所述数据分发装置600，包括：

获取模块601，用于实时获取所述服务平台的二级缓存中特定类型的数据的变化信息；

第一确定模块602，用于根据所述特定类型的数据的变化信息确定所述特定类型的数据的变化类型；

生成模块603，用于基于所述数据的变化类型生成可靠消息数据；

分发模块604，用于向所述服务平台的服务集群分发所述可靠消息数据，使得所述服务平台中的本地缓存与所述二级缓存中的数据同步。

在一种实施方式中，获取模块601，用于根据需求确定待存入所述本地缓存的数据的类型为所述特定类型；实时获取当前时刻和上一时刻所述二级缓存中所述特定类型的数据；基于当前时刻和上一时刻所述二级缓存中所述特定类型的数据确定所述二级缓存中特定类型的数据的变化信息。

在一些实施方式中，所述特定类型包括以下至少之一：语音类、视频类、短彩信类和位置类。

在一些实施方式中，所述二级缓存中的数据存储格式为键值存储；所述装置还包括：第二确定模块，用于根据所述特定类型的数据的变化信息确定变化数据的类型、键和值；

对应地，所述生成模块603，用于将所述变化数据的变化类型确定为所述变化数据的操作类型；基于所述变化数据的类型、操作类型、键和值生成所述可靠消息数据。

在一些实施方式中，所述变化类型包括以下至少之一：新增、删除和更新。

图7为本申请实施例提供的一种服务平台的本地缓存中的数据更新装置的组成结构示意图，如图7所示，所述数据更新装置700，包括：

第一接收模块701，用于接收数据分发设备发送的可靠消息数据；所述可靠消息数据是根据所述服务平台中的第二缓存中的变化数据生成的；

第二接收模块702，用于接收与所述可靠消息数据的数据类型相同的数据；

更新模块703，用于基于所述可靠消息数据对所述服务平台中本地缓存中的数据进行更新，使得更新后的所述本地缓存中的数据与所述第二缓存中的数据相同。

在一些实施方式中，所述本地缓存与所述第二缓存的数据存储格式均为键值存储。

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

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

一般来讲，本实施例中的一种数据分发方法和服务平台的本地缓存中的数据更新方法对应的计算机程序指令可以被存储在光盘，硬盘，U盘等存储介质上，当存储介质中的与一种数据分发方法和服务平台的本地缓存中的数据更新方法对应的计算机程序指令被一电子设备读取或被执行时，实现前述实施例的任意一种数据分发方法和服务平台的本地缓存中的数据更新方法。

基于前述实施例相同的技术构思，参见图8，其示出了本申请实施例提供的一种数据分发设备的结构示意图，所述数据分发设备800可以包括：存储器801和处理器802；其中，

所述存储器801，用于存储计算机程序和数据；

所述处理器802，用于执行所述存储器中存储的计算机程序，以实现前述实施例的任意一种数据分发方法。

在实际应用中，上述存储器801可以是易失性存储器(volatile memory)，例如RAM；或者非易失性存储器(non-volatile memory)，例如ROM，快闪存储器(flash memory)，硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；或者上述种类的存储器的组合，并向处理器802提供指令和数据。

上述处理器802可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的增强现实云平台，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作限定。

在一些实施例中，本申请实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

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

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的实施方式，上述的实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本申请的保护之内。