CN106713470A - 一种分布式缓存更新方法及缓存更新系统 - Google Patents

Abstract

本发明实施例提供了一种分布式缓存更新方法及缓存更新系统，该方法应用于缓存更新系统，所述缓存更新系统包括：数据组装服务器、数据缓存区、缓存更新服务器和缓存存储服务器，方法包括：数据组装服务器获得待缓存数据，按照预设规则将待缓存数据组装为缓存包，并发送给数据缓存区进行存储，从而，缓存更新服务器可以从数据缓存区中获得缓存包，根据缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。应用本发明实施例提高了分布式缓存更新系统的可靠性。

Description

一种分布式缓存更新方法及缓存更新系统

技术领域

本发明涉及分布式缓存领域技术领域，特别是涉及一种分布式缓存更新方法及缓存更新系统。

背景技术

在高并发环境下，为了应对海量数据与用户请求带来的挑战，解决大规模数据访问带来的网络瓶颈问题，分布式缓存技术应运而生。分布式缓存是指缓存数据部署在由多个服务器组成的集群中，以集群方式提供缓存服务。应用分布式缓存技术需要设计缓存更新策略，以提高缓存命中率，减轻后端服务压力。但是，随着业务的发展，跨机房网络通讯越来越频繁，在促进网络间数据交换的同时，也带来了系统可靠性的问题，因此，加强分布式缓存更新系统的可靠性变得尤为重要。

目前，常用的分布式缓存更新系统是基于主动更新策略的。具体做法是：首先，缓存更新系统接收消息中间件或者客户端发送的缓存更新通知，即消息通知；其次，根据消息通知组装缓存数据；最后，跨机房更新所有缓存服务器。现有的分布式缓存更新方法的整个执行过程是在同一个服务器中完成的，各个步骤按照顺序依次执行，任何一个步骤的失败，将导致整个更新过程失败，整个更新过程需要再次启动。比如：组装缓存数据失败，那么无论更新缓存服务器的步骤是否成功执行，由于用来更新缓存服务器的缓存数据未被成功组装，从而，导致更新缓存服务器是无效更新，整个更新过程需要再次启动。并且，每个步骤的执行都有可能由于网络环境的变化而导致失败，例如：接收消息通知时，由于系统重启升级，导致消息通知未被成功接收，或者，成功接收消息通知，但没成功完成消息通知的处理。组装缓存数据时，由于依赖服务出现异常，导致组装缓存数据失败；更新缓存服务器时，由于网络抖动或缓存服务出现异常，导致更新缓存服务器失败。

可见，在分布式缓存更新系统的更新过程中，每个步骤的执行都有可能由于网络环境的变化而失败，并且由于分布式缓存更新方法的整个执行过程是在同一个服务器中完成的，各个步骤相互关联，一个步骤的失败将导致整个更新过程的失败，从而导致分布式缓存更新系统的可靠性较低。

发明内容

本发明实施例的目的在于提供一种分布式缓存更新方法及缓存更新系统，以提高分布式缓存更新系统的可靠性。

为达到上述目的，本发明实施例提供了一种分布式缓存更新方法，应用于缓存更新系统，所述缓存更新系统包括：数据组装服务器、数据缓存区、缓存更新服务器和缓存存储服务器；所述方法包括：

所述数据组装服务器获得待缓存数据；按照预设规则将所述待缓存数据组装为缓存包；将所述缓存包发送给所述数据缓存区进行存储；

所述缓存更新服务器从所述数据缓存区中获得所述缓存包；根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

可选的，所述按照预设规则将所述待缓存数据组装为缓存包，包括：

对获得的待缓存数据进行过滤；

按照预设规则将过滤后的待缓存数据组装为缓存包。

可选的，所述按照预设规则将所述待缓存数据组装为缓存包，包括：

判断获得的待缓存数据的大小是否大于预设阈值；

如果是，将所述待缓存数据拆分为均不大于预设阈值的数据；

按照预设规则将拆分后的数据分别组装为缓存包。

可选的，所述缓存更新服务器从所述数据缓存区中获得所述缓存包，包括：

所述缓存更新服务器从所述数据缓存区中以pull方式获得所述缓存包。

可选的，缓存包中包含有机房标识信息；所述根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新，包括：

根据所述标识信息判断所述缓存包是否属于所述缓存更新服务器所处机房；

如果是，根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

可选的，所述缓存更新系统还包括：更新检测服务器；所述方法还包括：

所述更新检测服务器根据缓存更新日志中各个步骤的处理状态码，判断缓存是否更新成功；

如果否，向所述数据组装服务器发送缓存更新不成功消息，以重新更新缓存。

本发明实施例还公开了一种缓存更新系统，所述系统包括：数据组装服务器、数据缓存区、缓存更新服务器和缓存存储服务器；所述数据组装服务器包括：第一获得模块、组装模块和第一发送模块；所述缓存更新服务器包括：第二获得模块和更新模块，其中，

所述第一获得模块，用于获得待缓存数据；

所述组装模块，用于按照预设规则将所述待缓存数据组装为缓存包；

所述第一发送模块，用于将所述缓存包发送给所述数据缓存区进行存储；

所述第二获得模块，用于从所述数据缓存区中获得所述缓存包；

所述更新模块，用于根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

可选的，所述数据缓存区为：Kafka集群。

可选的，所述组装模块，包括：

过滤单元，用于对获得的待缓存数据进行过滤；

第一组装单元，用于按照预设规则将过滤后的待缓存数据组装为缓存包。

可选的，所述组装模块，包括：

第一判断单元，用于判断获得的待缓存数据的大小是否大于预设阈值；

拆分单元，用于在获得的待缓存数据的大小大于预设阈值的情况下，将所述待缓存数据拆分为均不大于预设阈值的数据；

第二组装单元，用于按照预设规则将拆分后的数据分别组装为缓存包。

可选的，所述第二获得模块，具体用于：

从所述数据缓存区中以pull方式获得所述缓存包。

可选的，缓存包中包含有机房标识信息；

所述更新模块，包括：

第二判断单元，用于根据所述标识信息判断所述缓存包是否属于所述缓存更新服务器所处机房；

更新单元，用于在所述缓存包属于所述缓存更新服务器所处机房的情况下，根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

可选的，所述系统还包括：更新检测服务器；所述更新检测服务器包括：判断模块和第二发送模块，其中，

所述判断模块，用于根据缓存更新日志中各个步骤的处理状态码，判断缓存是否更新成功；

所述第二发送模块，用于在缓存没有更新成功的情况下，向所述数据组装服务器发送缓存更新不成功消息，以重新更新缓存。

本发明实施例提供的分布式缓存更新方法及缓存更新系统，可以利用数据组装服务器获得待缓存数据，按照预设规则将待缓存数据组装为缓存包，并发送给数据缓存区进行存储，从而，缓存更新服务器可以从数据缓存区中获得缓存包，根据缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新，实现了将组装缓存数据的过程与更新缓存的过程从一个服务器里拆分出来，使得组装缓存数据的过程与更新缓存的过程相互独立，互不干扰，降低了网络环境对系统的影响，提高了分布式缓存更新系统的可靠性。

当然，实施本发明的任一产品或方法必不一定需要同时达到以上所述的所有优点。

附图说明

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

图1为本发明实施例提供的一种分布式缓存更新方法的流程示意图；

图2为本发明实施例提供的另一种分布式缓存更新方法的流程示意图；

图3为本发明实施例提供的一种缓存更新系统的结构示意图；

图4为本发明实施例提供的另一种缓存更新系统的结构示意图。

具体实施方式

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

本发明实施例公开了一种分布式缓存更新方法及缓存更新系统，以下分别进行详细说明。

参见图1，图1为本发明实施例提供的分布式缓存更新方法的一种流程示意图，应用于缓存更新系统，该缓存更新系统包括：数据组装服务器、数据缓存区、缓存更新服务器和缓存存储服务器，包括如下步骤：

S101，数据组装服务器获得待缓存数据；按照预设规则将待缓存数据组装为缓存包；将缓存包发送给数据缓存区进行存储。

在实际应用过程中，数据组装服务器获得待缓存数据的过程具体可以为：数据组装服务器接收消息中间件或者客户端发送的更新消息通知，根据更新消息通知以及业务逻辑，获得待缓存数据。整个获得待缓存数据的过程为现有技术，在此不再赘述。

示例性的，数据组装服务器接收到客户端A的发送更新消息通知，更新消息通知的内容为：{"type":"video","tvid":"132482349"}，则数据组装服务器根据业务逻辑获得客户端A中存储的type为video，tvid为132482349的数据内容，该数据内容即为待缓存数据。

在实际应用过程中，数据组装服务器获得待缓存数据的过程具体还可以为：数据组装服务器接收消息中间件或者客户端发送的更新消息通知，对接收到的更新消息通知进行消息去重，并过滤非法更新消息通知，根据过滤后的更新消息通知以及业务逻辑，获得待缓存数据。非法更新消息通知可以根据用户需求定义，本发明实施例在此不做限定，整个获得待缓存数据的过程为现有技术，在此不再赘述。

示例性的，非法更新消息通知是格式不正确的更新消息通知，假设更新消息通知的正确格式为：{"type":"属性值","tvid":"属性值"}，数据组装服务器接收到客户端A的发送更新消息通知a以及更新消息通知b，a和b的内容分别为：{"type":"video","tvid":"132482349"}、{"type":"video"}，则数据组装服务器将过滤掉更新消息通知b，根据更新消息通知a以及业务逻辑获得客户端A中存储的type为video，tvid为132482349的数据内容，该数据内容即为待缓存数据。

具体的，数据缓存区为：Kafka集群。Kafka是一种高吞吐量的分布式发布订阅消息系统，Kafka集群包含一个或多个服务器，对于每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic，在Kafka系统中，生成者将消息发送给Kafka集群，消费者从Kafka集群消费消息。Kafka集群作为数据缓存区，承担一个中间缓存和分发的作用，数据组装服务器将缓存包发送给Kafka集群，Kafka集群对缓存包进行存储，缓存更新服务器从Kafka集群获得缓存包，从而数据组装服务器为生产者，缓存更新服务器为消费者。使用Kafka集群作为缓存中间件，能够有利于提高系统的可靠性，主要体现在：Kafka集群支持消息持久化，并且采用主从复制机制能够保证数据不丢，从而保障了数据存储的可靠性；Kafka集群支持数据的可靠传输，通过ACK(Ackowledgemen，应答)机制和重试机制，能够保证缓存包发送和接收过程的可靠性，并且Kafka集群支持数据压缩，大大提高了网络传输效率，并且有利于降低网络压力。

需要说明的是，预设规则为预先设计并存储在数据组装服务器中的一段程序，按照该程序的执行方式将待缓存数据组装为缓存包，在实际应用中，可以根据用户需求定义程序的执行方式，本发明实施例在此不作限定。

具体的，按照预设规则将待缓存数据组装为缓存包，可以先对获得的待缓存数据进行过滤；然后，按照预设规则将过滤后的待缓存数据组装为缓存包。对获得的待缓存数据进行过滤可以采用多种方式，例如：去掉待缓存数据中的重复数据和非法数据。其中，非法数据是数据可以是数据长度异常的数据，也可以是数据类型异常的数据，在实际应用中，可以根据用户需求定义非法数据格式，本发明对此不作限定。

示例性的，将数据长度大于500M的数据定义为非法数据，则先将获得的待缓存数据中大于500M的数据过滤，然后按照预设规则将过滤后的不大于500M的待缓存数据组装为缓存包。

具体的，按照预设规则将待缓存数据组装为缓存包，还可以先判断获得的待缓存数据的大小是否大于预设阈值，并在获得的待缓存数据的大小大于预设阈值的情况下，将待缓存数据拆分为均不大于预设阈值的数据；然后，按照预设规则将拆分后的数据分别组装为缓存包。

示例性的，预设阈值为100M，获得的待缓存数据的大小为300M，则将待缓存数据拆分为三组数据，并且每组数据的大小都为100M，然后，按照预设规则将三组数据分别组装为缓存包。

需要说明的是，本发明实施例以将待缓存数据平均拆分为均不大于预设阈值的数据为例进行说明，仅为本发明的一个具体实例，并不构成对本发明的限定。在实际应用中，将待缓存数据拆分为均不大于预设阈值的数据可以根据用户需要进行设定拆分方法。

需要说明的是，缓存包的数据结构可以包括：header(控制信息)、items(缓存数据集)、message(消息通知)、module(业务名称)、time(系统处理时间)、status(系统处理状态码)。其中，header部分的数据结构包括：mid(消息标识)、rid(拆包标识)、dst(目标地址)、srcIp(源IP地址)、size(大小)、partKey(分区号)、priority(优先级)、topic(类别)；items部分的数据结构包括：opt(选项)、storageService(缓存服务类型)。在实际应用中，mid是数据组装服务器接收到消息通知后自动生成的，可以保证每次有唯一的mid与消息通知对应，即使每次接收到相同的消息通知也会生成不同的mid；rid是表示拆分后的每个缓存包的唯一性；dst表示目的机房集合；srcIp表示当前组装服务器的IP地址；size表示拆分前生成的key-value(键值对)集合大小，key-value集合是根据业务规则和消息通知组成的；partKey字段决定发送给topic下第几个分区；priority用于表示缓存包的级别，分为普通优先级(general)和高优先级(high)；topic表示Kafka topic名称，分为ONLINE-PUBLIC-TOPIC-GENERAL通道和ONLINE-PUBLIC-TOPIC-HIGH通道，分别对应普通优先级(general)和高优先级(high)；opt表示选择SET(重置)或DEL(删除)操作；time表示系统处理缓存包的时间；storageService表示缓存服务类型，表示缓存更新服务器具体写入缓存数据的缓存存储服务器类型，例如：memcache、redis、couchbase等等，可以同时指定多个缓存存储服务器类型；status表示在整个更新流程中系统的处理状态，可以用以标识整个更新流程中各个步骤执行的成功与否。

需要说明的是，数据组装服务器可以利用ONLINE-PUBLIC-TOPIC-GENERAL和ONLINE-PUBLIC-TOPIC-HIGH两种通道，将缓存包发送给Kafka集群，当数据组装服务器获得的消息通知是普通消息通知时，根据该消息通知组装的缓存包的priority级别为general，则利用ONLINE-PUBLIC-TOPIC-GENERAL通道，将缓存包发送给Kafka集群；当数据组装服务器获得的消息通知是重要消息通知时，根据该消息通知组装的缓存包的priority级别为high，则利用ONLINE-PUBLIC-TOPIC-HIGH通道，将缓存包发送给Kafka集群。需要解释的是，普通消息通知和重要消息通知可以根据用户需求的定义，本发明对此不做限定。并且，数据组装服务器采用Kafka ACK机制发送缓存包，同时利用Kafka重试机制设置重试次数，来保证缓存包的成功发送。Kafka ACK机制以及Kafka重试机制属于现有技术，在此不再赘述。

S102，缓存更新服务器从数据缓存区中获得缓存包；根据缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

具体的，缓存更新服务器从数据缓存区中以pull(拉)方式获得缓存包。因此，如果此时网络不稳定，那么此时缓存更新服务器将无法获得缓存包，缓存包仍然保存在Kafka集群中。等待网络恢复稳定后，缓存更新服务器可以继续从Kafka集群获得缓存包。在缓存更新服务器获得缓存包后，会更新在同一机房的缓存存储服务器。因为当缓存更新服务器与缓存存储服务器位于同一机房时，可以忽略网络因素，因此，将缓存更新服务器与缓存存储服务器部署在同一机房内，一个机房的缓存更新服务器只负责更新该机房内的缓存存储服务器。并且，一个机房的缓存更新服务器属于一个独立的Kafka消费者,这样保证了每个机房的缓存更新服务器都能独立的获得缓存包，相互不影响，可以避免由于一个机房的缓存更新失败而导致所有机房都需要重新更新缓存的情况发生，提高了系统的可靠性。

具体的，缓存包中包含有机房标识信息；根据缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新，可以为：根据标识信息判断缓存包是否属于缓存更新服务器所处机房；如果是，根据缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新，如果不是，就丢弃该缓存包。

示例性的，A机房的机房标识信息为a，当位于机房A的缓存更新服务器获得的缓存包中的机房标识信息包含a时，则根据该缓存包对位于A机房的缓存存储服务器进行缓存更新；当位于机房A的缓存更新服务器获得的缓存包中的机房标识信息不包含a时，则丢弃该缓存包。

需要说明的是，缓存更新服务器可以利用Low-level API(低标准接口)或High-level API(高标准接口)两种方式来获得缓存包。区别在于Low-levelAPI使用复杂，并且需要在每次写入到缓存服务后再主动提交offset(偏移量)。High-level API封装了对partition(分区)和offset的管理，默认设置定期自动提交offset。由于Low-level API会大大影响系统性能，并增加系统复杂度，因此，推荐使用High-level API。更新服务器在向缓存存储服务器写入缓存数据时，一般有两种写入模式：同步写入模式和异步写入模式。通常采用异步写入模式写入缓存存储服务器时，会提高网络吞吐量，但这样带来的问题是无法识别每次写操作是否成功。对于本发明实施例而言，将缓存更新服务器与缓存存储服务器部署于同一机房，可以减少网络影响概率，并采用引入重试机制的异步写入模式，来实现高可靠性与高吞吐量的平衡点。需要说明的是异步写入模式与重试机制为现有技术，本发明实施例在此不对其进行赘述。

可见，应用本发明实施例，实现了将组装缓存数据的过程与更新缓存的过程从一个服务器里拆分出来，使得组装缓存数据的过程与更新缓存的过程相互独立，互不干扰，降低了网络环境对系统的影响，提高了分布式缓存更新系统的可靠性。

具体的，在本发明的一个实施例中，缓存更新系统还包括：更新检测服务器，如图2所示，本发明图2所示实施例在图1所示实施例的基础上，增加S103和S104。

S103，更新检测服务器根据缓存更新日志中各个步骤的处理状态码，判断缓存是否更新成功；在缓存没有更新成功的情况下，执行S104。

需要说明的是，缓存更新日志包括组装服务器日志和更新服务器日志。缓存更新日志记录了分布式缓存更新方法整个执行过程中各个步骤的处理情况，并且按照预定义的处理状态码来标记各个更新步骤的处理状态。在实际应用中，处理状态码可以根据用户需要进行设定，本发明对此不作限定。

示例性的，处理状态码具体值可以为：0_all、0_fail、0_deny、1_ok、1_fail、2_parse_fail、2_deny、2_ok、2_fail，其中，0_all表示数据组装服务器接收到消息通知；0_fail表示数据组装服务器发生异常，丢弃消息；0_deny表示组装服务器不支持组装数据，或组装数据为空；1_ok表示数据组装服务器向Kafka集群发送缓存包成功；1_fail表示数据组装服务器向Kafka集群发送缓存包失败；2_parse_fail表示缓存更新服务器解析缓存包失败；2_deny表示缓存更新服务器从Kafka集群接收缓存包失败；2_ok表示缓存更新服务器更新缓存成功；2_fail表示缓存更新服务器更新缓存失败。

S104，向数据组装服务器发送缓存更新不成功消息，以重新更新缓存。

需要说明的是，在缓存没有更新成功的情况下，更新检测服务器向数据组装服务器发送缓存更新不成功消息，从而，数据组装服务器重新执行S101，缓存更新服务器重新执行S102。需要解释的是，为了保证系统优先处理重新更新缓存的过程，以使重新更新缓存的过程被更快处理，更新检测服务器发送的更新不成功消息的priority级别为high，因此，根据该消息组装的缓存包会通过ONLINE-PUBLIC-TOPIC-HIGH通道到达Kafka集群，整个重新更新缓存流程的处理会更快速。并且，为了避免重新更新缓存的次数太多，而影响系统运行效率，可以预先设置最大重试次数，当超过最大重试次数时，更新检测服务器将不再向数据组装服务器发送缓存更新不成功消息。

示例性的，预先设置最大重试次数为3，则当重新更新缓存的次数小于等于3次时，更新检测服务器向数据组装服务器发送缓存更新不成功消息，以重新更新缓存；当重新更新缓存的次数大于3次时，更新检测服务器不再向数据组装服务器发送缓存更新不成功消息。

可见，应用本发明实施例，实现了将组装缓存数据的过程与更新缓存的过程从一个服务器里拆分出来，使得组装缓存数据的过程与更新缓存的过程相互独立，互不干扰，降低了网络环境对系统的影响，进一步的，提高了系统的容错能力，从而提高了分布式缓存更新系统的可靠性。

与上述的方法实施例相对应，本发明实施例还提供一种缓存更新系统。

参见图3，图3为本发明实施例所提供的一种缓存更新系统的结构示意图，该系统包括：数据组装服务器301、数据缓存区302、缓存更新服务器303和缓存存储服务器304，数据组装服务器301包括：第一获得模块、组装模块和第一发送模块；缓存更新服务器303包括：第二获得模块和更新模块，其中，

第一获得模块，用于获得待缓存数据；

组装模块，用于按照预设规则将待缓存数据组装为缓存包；

第一发送模块，用于将缓存包发送给数据缓存区302进行存储；

第二获得模块，用于从数据缓存区302中获得缓存包；

更新模块，用于根据缓存包对与该缓存更新服务器303位于同一机房的缓存存储服务器304进行缓存更新。

其中，数据缓存区302为：Kafka集群。

其中，组装模块，包括：过滤单元和第一组装单元(图中未示出)。

过滤单元，用于对获得的待缓存数据进行过滤；

第一组装单元，用于按照预设规则将过滤后的待缓存数据组装为缓存包。

其中，组装模块，包括：第一判断单元、拆分单元和第二组装单元(图中未示出)。

第一判断单元，用于判断获得的待缓存数据的大小是否大于预设阈值；

拆分单元，用于在获得的待缓存数据的大小大于预设阈值的情况下，将待缓存数据拆分为均不大于预设阈值的数据；

第二组装单元，用于按照预设规则将拆分后的数据分别组装为缓存包。

其中，第二获得模块，具体用于：

从数据缓存区302中以pull方式获得缓存包。

其中，缓存包中包含有机房标识信息；

更新模块，包括：第二判断单元和更新单元(图中未示出)。

第二判断单元，用于根据标识信息判断缓存包是否属于缓存更新服务器303所处机房；

更新单元，用于在缓存包属于缓存更新服务器303所处机房的情况下，根据缓存包对与该缓存更新服务器303位于同一机房的缓存存储服务器304进行缓存更新。

可见，应用本发明实施例，实现了将组装缓存数据的过程与更新缓存的过程从一个服务器里拆分出来，使得组装缓存数据的过程与更新缓存的过程相互独立，互不干扰，降低了网络环境对系统的影响，提高了分布式缓存更新系统的可靠性。

参见图4，图4为本发明实施例所提供的另一种缓存更新系统的结构示意图；本发明图4实施例在图3所示实施例的基础上，增加更新检测服务器305，更新检测服务器包括：判断模块和第二发送模块，其中，

判断模块，用于根据缓存更新日志中各个步骤的处理状态码，判断缓存是否更新成功；

第二发送模块，用于在缓存没有更新成功的情况下，向数据组装服务器301发送缓存更新不成功消息，以重新更新缓存。

可见，应用本发明实施例，实现了将组装缓存数据的过程与更新缓存的过程从一个服务器里拆分出来，使得组装缓存数据的过程与更新缓存的过程相互独立，互不干扰，降低了网络环境对系统的影响，进一步的，提高了系统的容错能力，从而提高了分布式缓存更新系统的可靠性。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (14)

1.一种分布式缓存更新方法，其特征在于，应用于缓存更新系统，所述缓存更新系统包括：数据组装服务器、数据缓存区、缓存更新服务器和缓存存储服务器；所述方法包括：

所述数据组装服务器获得待缓存数据；按照预设规则将所述待缓存数据组装为缓存包；将所述缓存包发送给所述数据缓存区进行存储；

所述缓存更新服务器从所述数据缓存区中获得所述缓存包；根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

2.根据权利要求1所述的方法，其特征在于，所述数据缓存区为：

Kafka集群。

3.根据权利要求1所述的方法，其特征在于，所述按照预设规则将所述待缓存数据组装为缓存包，包括：

对获得的待缓存数据进行过滤；

按照预设规则将过滤后的待缓存数据组装为缓存包。

4.根据权利要求1所述的方法，其特征在于，所述按照预设规则将所述待缓存数据组装为缓存包，包括：

判断获得的待缓存数据的大小是否大于预设阈值；

如果是，将所述待缓存数据拆分为均不大于预设阈值的数据；

按照预设规则将拆分后的数据分别组装为缓存包。

5.根据权利要求1所述的方法，其特征在于，所述缓存更新服务器从所述数据缓存区中获得所述缓存包，包括：

所述缓存更新服务器从所述数据缓存区中以pull方式获得所述缓存包。

6.根据权利要求1所述的方法，其特征在于，缓存包中包含有机房标识信息；

所述根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新，包括：

根据所述标识信息判断所述缓存包是否属于所述缓存更新服务器所处机房；

如果是，根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

7.根据权利要求1所述的方法，其特征在于，所述缓存更新系统还包括：更新检测服务器；所述方法还包括：

所述更新检测服务器根据缓存更新日志中各个步骤的处理状态码，判断缓存是否更新成功；

如果否，向所述数据组装服务器发送缓存更新不成功消息，以重新更新缓存。

8.一种缓存更新系统，其特征在于，所述系统包括：数据组装服务器、数据缓存区、缓存更新服务器和缓存存储服务器；所述数据组装服务器包括：第一获得模块、组装模块和第一发送模块；所述缓存更新服务器包括：第二获得模块和更新模块，其中，

所述第一获得模块，用于获得待缓存数据；

所述组装模块，用于按照预设规则将所述待缓存数据组装为缓存包；

所述第一发送模块，用于将所述缓存包发送给所述数据缓存区进行存储；

所述第二获得模块，用于从所述数据缓存区中获得所述缓存包；

所述更新模块，用于根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

9.根据权利要求8所述的系统，其特征在于，所述数据缓存区为：

Kafka集群。

10.根据权利要求8所述的系统，其特征在于，所述组装模块，包括：

过滤单元，用于对获得的待缓存数据进行过滤；

第一组装单元，用于按照预设规则将过滤后的待缓存数据组装为缓存包。

11.根据权利要求8所述的系统，其特征在于，所述组装模块，包括：

第一判断单元，用于判断获得的待缓存数据的大小是否大于预设阈值；

拆分单元，用于在获得的待缓存数据的大小大于预设阈值的情况下，将所述待缓存数据拆分为均不大于预设阈值的数据；

第二组装单元，用于按照预设规则将拆分后的数据分别组装为缓存包。

12.根据权利要求8所述的系统，其特征在于，所述第二获得模块，具体用于：

从所述数据缓存区中以pull方式获得所述缓存包。

13.根据权利要求8所述的系统，其特征在于，缓存包中包含有机房标识信息；

所述更新模块，包括：

第二判断单元，用于根据所述标识信息判断所述缓存包是否属于所述缓存更新服务器所处机房；

更新单元，用于在所述缓存包属于所述缓存更新服务器所处机房的情况下，根据所述缓存包对与该缓存更新服务器位于同一机房的缓存存储服务器进行缓存更新。

14.根据权利要求8所述的系统，其特征在于，所述系统还包括：更新检测服务器；所述更新检测服务器包括：判断模块和第二发送模块，其中，

所述判断模块，用于根据缓存更新日志中各个步骤的处理状态码，判断缓存是否更新成功；

所述第二发送模块，用于在缓存没有更新成功的情况下，向所述数据组装服务器发送缓存更新不成功消息，以重新更新缓存。