CN107103068A - 业务缓存的更新方法及装置 - Google Patents

Abstract

本发明揭示了一种业务缓存的更新方法及装置。所述方法包括：通过监听数据库中数据表的变化获取数据表变更记录；根据所述数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，所述更新状态结果用于指示所述数据表缓存中的数据表是否更新成功；在所述更新状态结果指示所述数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录；根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中。即通过监听数据库中数据表的变化实时的获取数据表变更记录，然后得到业务记录，并根据业务记录更新业务缓存，由此，实现了业务缓存的实时更新，进而保证了网络服务的准确性，提高了网络服务的准确率。

Description

业务缓存的更新方法及装置

技术领域

本发明涉及数据库领域，特别涉及一种业务缓存的更新方法及装置。

背景技术

随着网络技术的快速发展，用户对网络服务的访问速度和准确性提出了更高的要求，为了满足海量用户的访问需求，一般采用在数据库的基础上增加缓存的方法。然而，随着网络环境中业务内容的丰富、用户数量的增加，单层缓存技术已经无法应对数据量的激增。当前被广泛使用的缓存技术是分层缓存技术，即第一级缓存是数据表缓存，即对数据库表进行缓存，第二级缓存是业务缓存，即对业务数据进行缓存。

目前，业务缓存的更新方案有两种，第一种是热点更新缓存方案，该方案仅在业务缓存中设置的时间过期用户访问所需的业务数据时才进行更新，第二种是全量定时更新缓存方案，该方案是定时地对业务缓存中的全部业务数据进行更新。

由此可知，在数据库表发生变化时，上述两种方案均无法做到实时地更新业务缓存，这将导致业务缓存中的业务数据和数据库表中的数据存在不一致的现象，进而影响网络服务的准确率。

发明内容

为了解决相关技术中存在的在分层缓存中无法实时更新业务缓存的问题，本发明提供了一种业务缓存的更新方法及装置。

一种业务缓存的更新方法，所述方法包括：

通过监听数据库中数据表的变化获取数据表变更记录；

根据所述数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，所述更新状态结果用于指示所述数据表缓存中的数据表是否更新成功；

在所述更新状态结果指示所述数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录；

根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中。

一种业务缓存的更新装置，所述装置包括：

获取模块，用于通过监听数据库中数据表的变化获取数据表变更记录；

指示模块，用于根据所述数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，所述更新状态结果用于指示所述数据表缓存中的数据表是否更新成功；

生成模块，用于在所述更新状态结果指示所述数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录；

更新模块，用于根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中。

本发明的实施例提供的技术方案可以包括以下有益效果：

本方案先通过监听数据库中数据表的变化获取数据表变更记录，根据该数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，这个更新状态结果用于指示所述数据表缓存中的数据表是否更新成功，在更新状态结果指示数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录，根据业务记录进行数据组装得到业务数据，将业务数据更新至业务缓存中。由此，在数据库表发生变化时，数据表缓存中的数据表和业务缓存中的业务数据同时得到了更新，以此实现了分层缓存中业务缓存的实时更新，进而保证了网络服务的准确性，提高了网络服务的准确率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并于说明书一起用于解释本发明的原理。

图1是根据本发明所涉及的实施环境的示意图；

图2是根据一示例性实施例示出的一种业务缓存的更新方法的流程图；

图3是根据另一示例性实施例示出的一种业务缓存的更新方法的流程图；

图4是根据另一示例性实施例示出的一种业务缓存的更新方法的流程图；

图5根据另一示例性实施例示出的一种业务缓存的更新过程示意图；

图6是根据一示例性实施例示出的一种业务缓存的更新装置的框图；

图7是根据一示例性实施例示出的添加模块的细节进行描述的框图；

图8是是根据另一示例性实施例示出的一种业务缓存的更新装置的框图；

图9是根据一示例性实施例示出的一种装置600的硬件结构框图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

目前，业务缓存的更新方案有两种，第一种是热点更新缓存方案，该方案仅在业务缓存中用户访问所需的业务数据并且该业务数据超过预设的时间期限时才进行更新，第二种是全量定时更新缓存方案，该方案是定时地对业务缓存中的全部业务数据进行更新。

通过以上两种方式，虽然在数据库表发生变化时，数据表缓存都能在短时间内得以更新，但是都无法实时更新业务缓存。其中，热点更新缓存方式的业务缓存需要等待缓存失效(如超过预先设置的过期时间)之后并有客户端请求时，业务缓存才会被更新，而全量定时更新缓存方式，只有在时间达到设定的更新周期时，业务缓存才会被更新。因此通过这两种方式，在分层缓存中都无法实时更新业务缓存，直接降低了网络服务的准确率。

图1是根据本发明所涉及的实施环境的示意图。该实施环境可以包括：至少一个客户端110和至少一个服务器130。

其中，客户端110根据业务需求情况向服务器130执行读请求和写请求。

服务器130可以是安装有数据库的服务器，服务器通过运行的数据库，来响应客户端110的读请求或写请求。

根据数据库规模大小和稳定性的要求，可以将数据库，业务缓存，数据表缓存分别放在不同的服务器上，也可以将数据库，业务缓存，数据表缓存放在同一个服务器上而且数据库，业务缓存，数据表缓存之间是能相互能访问的。

客户端110与服务器130之间的关联方式，包括有线或无线的网络关联方式，以及二者之间往来的数据关联方式，具体的关联方式不受本实施例的限制。

图2是根据一示例性实施例示出的一种业务缓存的更新方法的流程图。如图2所示，该业务缓存的更新方法可以包括以下步骤。

在步骤S210中，通过监听数据库中数据表的变化获取数据表变更记录。

其中，数据库是指按照数据结构来组织、存储和管理数据的仓库，数据表则是包含数据库中所有数据的集合。

数据库中数据表的变化是指数据表中的数据进行了***(insert)、删除(delete)、修改(update)等操作。相应地，数据表变更记录则是记录了对数据表中数据进行的操作属于***、删除还是修改。

本实施例中，数据表变更记录的获取是通过监听数据表的变化实现的。

当数据库中数据表发生变化时，数据表变更记录会被写入到一个专用的数据表中，如表名为DateUpdate的数据表，或是写入到一个第三方的消息队列中，如ActiveMQ。通过监听数据库中数据表的变化，对数据表DateUpdate或是ActiveMQ消息队列进行遍历，如果发现数据表DateUpdate或是ActiveMQ消息队列发生了变化，则说明数据库中数据表发生了变化，进而由数据表DateUpdate或是ActiveMQ消息队列中获取到数据表变更记录。

进一步地，在获取到数据表变更记录后，可以将该数据表变更记录由数据表DateUpdate或是ActiveMQ消息队列中删除，以此减轻服务器的存储压力。

在步骤S230中，根据数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，更新状态结果用于指示数据表缓存中的数据表是否更新成功。

其中，更新状态结果用于指示数据表缓存中的数据表是否更新成功。

具体而言，根据该变更记录在数据库中查询出数据表更新的相关信息，或者从该变更记录中提取得到数据表变更的相关信息。其中，该相关信息可以包括数据表名、表关键值、操作标志、状态等。

利用数据表变更的相关信息对数据表缓存中的数据表进行更新，在更新完成后，即得到更新状态结果，例如，更新状态结果为1，表示数据表更新成功，更新状态结果为0，则表示数据表更新失败。

在步骤S250中，在更新状态结果指示数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录。

具体的，在更新状态结果指示数据表缓存中的数据表更新成功时，根据前述变更记录中的数据对更新成功的数据表中的数据进行处理后生成相关的业务记录。

在步骤S270中，根据业务记录进行数据组装得到业务数据，将业务数据更新至业务缓存中。

例如，应用ID为10000的应用修改了一张图片，对应到数据库里执行一条update语句，由于数据库中数据表发生了变化，因此数据表DateUpdate或者消息队列ActiveMQ会生成一条数据表变更记录，如：

根据该数据表变更记录对数据表缓存中的数据表进行更新后，根据更新结果还会对表里的状态值进行相应的修改。如果更新状态结果为1则说明更新成功。

更新成功后生成相应的业务记录，其中业务记录中还包括该应用的引用关系，业务标识，业务类型等，可以根据不同的应用场景或者应用环境，然后从数据表缓存中获取与所述业务记录对应的数据，对数据进行组装得到业务数据，最后根据业务数据对业务缓存进行更新。

进一步的，在对数据表缓存执行更新或删除操作后，如果该更新或删除操作的状态值为0，这说明数据表缓存的更新并未成功，因此业务缓存也无需更新。

另外，由于对业务缓存进行更新后会生成业务记录，业务记录里面记录了业务类型，业务标识等信息。

由于数据表缓存中的数据与业务缓存中的业务数据的数据格式或者封装并不一致，因此需要对数据表缓存中的数据进行处理后方可对业务缓存进行更新。

利用如上所述的过程，通过监听数据库中数据表的变化获取数据表变更记录，根据该数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，这个更新状态结果用于指示所述数据表缓存中的数据表是否更新成功，在更新状态结果指示数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录，根据业务记录进行数据组装得到业务数据，将业务数据更新至业务缓存中。由此，在数据库表发生变化时，数据表缓存中的数据表和业务缓存中的业务数据同时得到了更新，以此实现了分层缓存中业务缓存的实时更新，进而保证了网络服务的准确性，提高了网络服务的准确率。

在另一个示例性实施例示出的业务缓存的更新方法中，在步骤S210之前，该方法还包括以下步骤。

接收客户端发起的写请求，通过响应所述写请求生成所述数据表变更记录。

其中，客户端发起的写请求是指对数据库执行***、删除、修改等操作，根据该写请求，生成相应的数据表变更记录。

具体的，可以在数据库中设置触发器，当数据库存在增加、删除、修改等操作时，由数据库的触发器生成一条变更记录，可以包括数据表名，表关键值，第一保留字段，第二保留字段，操作标志，状态等，数据表名用做标记是哪个数据表发生了变化，表关键值是该业务对应的KEYID(KEY identification，关键标识)，操作标志字段表示该记录是增加、删除、修改等操作中的一种，可以用0/1/2这样的值进行约定。

利用如上所述的过程，通过对数据库的变化进行监听，实时的获取变更记录，为实现在分层缓存中对业务缓存进行实时更新提供了便利条件。

在另一个示例性实施例示出的业务缓存的更新方法中，在步骤S270之前，该方法还包括以下步骤。

将业务记录添加至业务更新集合中。

具体的，业务更新集合是用来存储业务记录的一个集合，也可以是业务更新队列。

图3是根据另一示例性实施例示出的一种业务缓存的更新方法的流程图。如图3所示，该步骤将业务记录添加至业务更新集合中还可以包括以下步骤。

在步骤S261中，判断业务记录中的业务标识是否存在于预先创建的业务标识集合中，业务标识集合用于存储业务缓存中业务数据对应的业务标识。

具体的，业务标识是业务记录的标记，相同的业务记录具有同样的业务标识，一般可以有表关键值等信息来组成，业务记录中包括多项内容，如业务标识，业务类型等，。业务标识集合是用来根据业务标识存储业务记录的一个集合，也可以表示为注册队列，可以根据业务标识将该集合或队列中的业务记录进行排序。

在步骤S263中，如果不存在，则将业务记录过滤。

如果该业务记录的业务标识在业务标识集合中不存在，则直接将该业务记录丢弃，即说明该业务记录不需要更新。

在步骤S265中，否则，将业务标识存在于所述业务标识集合中的业务记录添加至所述业务更新集合中。

如果该业务记录的业务标识在业务标识集合中存在，则直接将该业务记录加入到业务更新集合中，即说明该业务记录需要更新。

具体的，在开始的时候，由于业务缓存中没有任何业务数据，所以业务标识集合中也是空的，随着业务缓存中业务数据的不断增多，业务标识集合中的业务标识也会越来越多。当然相同的业务标识不用重复增加，即每个业务标识在注册队列中是唯一的，而且可以根据业务标识出现的频率进行相应的统计，用以标识这些业务标识被请求的次数，根据该次数，可以对业务标识进行排序。当业务标识集合中的业务标识过多时，可以将排名靠后的业务标识直接删除掉，删除掉业务标识的同时可以将与该业务标识对应的业务缓存中的业务数据也删除掉。

例如，目前注册队列中存在Hisense2351、Hisense2361、Hisense2381、Hisense2351四种业务标识，其中Hisense2351代表的是在游戏A中将角色B增加一个特征C，Hisense2361代表的是在游戏A中将角色B去掉一个特征D。监听模块根据监听获取到的变更记录后，生成的业务记录中的业务标识是Hisense2361，结果是该业务记录符合过滤条件。

通过过滤可以将不符合条件的业务记录直接去掉。即将更新经常会用到的业务缓存，不常用的业务缓存暂时不更新，这样能有效降低业务缓存的负担，通过业务缓存的处理效率，降低业务缓存占用的内存空间。同时，可以根据过滤的频率对业务记录进行统计，将频率高的业务记录排在靠前的位置，这样过滤的时候可以按照这个先后顺序来过滤，从而进一步提高过滤的效率，提高业务缓存更新的效率。

在另一个示例性实施例示出的业务缓存的更新方法中，在将业务记录添加至业务更新集合中的步骤之前，该方法还包括以下步骤。

根据所述业务记录中的业务标识对所述业务记录进行去重处理，删除业务标识重复的所述业务记录，并将去重处理后的业务记录添加至所述业务更新集合中。

其中，去重处理是指将相同的业务记录去掉，只留一个来对业务缓存进行更新，将经过去重处理后的业务记录添加至业务更新集合中。由于业务缓存在更新的时间段内，可能会产生多个相同的业务记录，而且这种概率是比较高的，这时候业务缓存会对这些业务记录进行轮流更新，但实际上的更新内容并没有发生变化，因此增加了业务缓存的负担。这时候就需要对业务记录进行去重处理。

另外，由于需要更新缓存的业务记录通常会比较多，所以可以将这些业务记录加入到一个业务更新队列或者业务更新集合中，然后根据业务记录的频率进行排序，从队列或集合中按照排序的顺序对业务缓存进行更新。

其中，去重处理，是指将相同的业务记录先进行处理，即只留下一个即可。

例如，现在有5个客户端写请求导致生成了多个业务标识为Hisense2361的业务记录，即说明，有5个客户端在游戏A中将角色B去掉一个特征D，这时候如果不经过去重处理，那么会对业务缓存进行5次更新，可以看出这直接影响了业务缓存的更新效率。按照业务标识，进行去重处理后，原本需要更新5次业务缓存的情况，现在只需更新一次即可，大大提高了业务缓存的效率。

如上所述的例子，有5个客户端写请求导致生成了多个业务标识为Hisense2361的业务记录，因此通过去重处理后，只需获取这个5个业务记录中的一个即可。

具体的，根据业务记录的业务标识是否存在与注册队列中，可以初步过滤出需要更新业务缓存的业务记录，从而提高了业务缓存更新的效率。

图4是根据另一示例性实施例示出的一种业务缓存的更新方法的流程图。如图4所示，该业务缓存更新方法还可以包括以下步骤。

在步骤S281中，接收客户端发送的读请求，并通过响应读请求返回业务数据至所述客户端。

其中，客户端读请求是指向业务缓存请求业务数据的请求，在收到客户端读请求后，会对该请求进行响应，并在业务缓存中查询是否存在与该请求对应的业务数据，如果查询到相应的业务数据，则直接向客户端返回该业务数据，如果未能查询到相应的业务数据，则根据所述客户端读请求从数据表缓存中获取相关的数据，然后将该数据进行数据组装得到业务数据，最后把业务数据写入业务缓存中并返回至客户端。

在步骤S283中，将返回的业务数据对应的业务标识存储至业务标识集合中。

其中，在返回业务数据后，从该业务数据提取相应的业务标识，并将该业务标识存储至业务标识集合中。

进一步的，可以根据业务数据更新的次数，在业务标识集合中，按照业务标识进行相应的统计和排序，这样更新次数越多的业务记录就排在业务标识集合的前面，少更新的就排在业务标识集合的后面，如果业务标识集合满时，直接可以将排在后面业务记录和与该业务记录对应的业务缓存删除掉，这样更有利于后续的业务缓存更新和业务记录的过滤，以及减少缓存的内存占用空间。

进一步的，通常同一业务记录会涉及到多个业务类型，例如同一个游戏，在不同的平台或者设备上运行的时候，虽然业务记录是一样的，但是由于平台或者设备的不同，最终的业务数据也会不一样，这时候可以对业务记录中的数据或者从数据表缓存中获取的数据根据这个业务类型对该数据进行组装，最终形成符合各个平台或者设备的业务数据。

进一步的，可以根据不同的应用场景或者应用环境，将数据进行组装得到业务数据，然后根据该业务数据对业务缓存进行更新。

利用如上所述的过程，根据返回的业务数据，对业务标识和业务标识集合进行处理，为分层缓存中业务缓存的更新提供了便利。

在另一个示例性实施例示出的业务缓存的更新方法中，在将返回的业务数据对应的业务标识存储至业务标识集合中之后的步骤之后，该方法还包括以下步骤。

在业务标识集合的存储状态指示业务标识集合已存满时，删除业务标识集合中存储时间最长的业务标识，并在业务缓存中删除该业务标识对应的业务数据。

其中，在业务标识集合的存储状态指示业务标识集合已存满时，是指该业务标识集合中业务标识已经存满了，也就是说没有更多的空间来继续增加新的业务标识，这时候可以根据业务标识的更新次数、存储时间或者最新更新时间等对业务标识集合进行相应的排序处理，队列满时，即可将排在最后的业务标识以及该业务标识对应的业务缓存中的业务数据进行删除。

利用如上所述的过程，通过对业务标识集合的优化处理，在业务标识集合无法继续添加业务标识的情况下，经常更新的业务标识排在集合的前面，这样更有利于加快实施更新，而且将使用频率较少或者长时间未使用，又或者长时间未更新的业务标识删除掉，删除掉该业务标识的同时将该业务标识对应的业务缓存中的业务数据进行删除，这样有效减少了业务缓存的更新所占用的内存空间。

图5是根据另一示例性实施例示出的一种业务缓存的更新过程示意图。

其中，客户端写请求440是指对数据库430中的数据库表会进行增加、删除或者修改数据的操作。可以在数据库430中设置数据库的触发器，当数据库430存在增加、删除或者修改数据的操作时，该触发器自动生成与该操作相应的记录，并将生成的记录写入到一个专用的表，如记录表。还可以将记录写到一个第三方的消息队列中，如ActiveMQ，监听模块410可以遍历数据库430中的记录表或是ActiveMQ消息队列，若存在消息记录则从中读到必要的数据后删除相应的记录。

其中，记录表中的字段可以包括有数据表名，表关键值，第一保留字段，第二保留字段，操作标志，状态等内容。其中表名用于标记具体是哪个表的数据发生了变化，表关键值是该记录表中的主键ID，操作标志字段表示该记录是增加/修改/删除中的一种操作，通常情况下，可以用0/1/2这样的值进行约定。

例如，如果是删除操作，这说明数据库430中的数据已被删除，这时候如果可能还需要使用其它的值来标识执行删除缓存的操作，可以使用记录表中的第一保留字段或第二保留字段。

具体的，当数据库430执行了一个删除操作时，数据库430中的触发器生成了一条删除记录，监听模块410监听到该数据库430中数据库表的变化后，将该删除记录发送给表缓存更新模块421，表缓存更新模块421根据该删除记录查询数据库430或直接从该删除记录中提取必要的信息对数据表缓存进行更新，再根据更新的结果设置该删除记录的状态值并生成相应的业务记录，并将该业务记录发给监听模块410，监听模块410根据该状态值得到更新结果后，将该业务记录发送给过滤模块463，过滤模块463从该业务记录中获取到业务标识后，将该业务标识跟注册队列453中的业务标识进行比较，如果注册队列453中存在该业务标识，则将该业务记录加入到业务更新队列462中，业务更新队列462可以对该队列中的业务记录根据业务标识进行去重处理，业务缓存更新模块461会按照业务更新队列中的先后顺序，根据业务记录将从数据表缓存中获取的数据组装成业务数据，最后把该业务数据更新到对业务缓存中。

下述为本发明装置实施例，可以用于执行本发明上述业务缓存的更新方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明业务缓存的更新方法实施例。

图6是根据一示例性实施例示出的一种业务缓存的更新装置的框图。该业务缓存的更新装置可以用于图1所示的实施环境中，执行图2所示的业务缓存的更新方法的全部或部分步骤。如图6所示，该业务缓存的更新装置500包括但不限于：获取模块510、指示模块530、生成模块550和更新模块570。

获取模块510，用于通过监听数据库中数据表的变化获取数据表变更记录。

指示模块530，用于根据数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，更新状态结果用于指示数据表缓存中的数据表是否更新成功。

生成模块550，用于在更新状态结果指示数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录。

更新模块570，用于根据业务记录进行数据组装得到业务数据，将业务数据更新至业务缓存中。

图7是根据一示例性实施例示出的添加模块的细节进行描述的框图。如图7所示，该添加模块可以包括但不限于：判断单元561、过滤单元563和添加单元565。

判断单元561，用于判断业务记录中的业务标识是否存在于预先创建的业务标识集合中，业务标识集合用于存储业务缓存中业务数据对应的业务标识。

过滤单元563，用于如果不存在，则将业务记录过滤。

添加单元565，用于否则，将业务标识存在于业务标识集合中的业务记录添加至业务更新集合中。

在另一个示例性实施例中，该业务缓存的更新装置，还可以包括但不限于：去重处理模块。

该去重处理模块用于根据业务记录中的业务标识对所述业务记录进行去重处理，删除业务标识重复的业务记录，并将去重处理后的业务记录添加至业务更新集合中。

图8是是根据另一示例性实施例示出的一种业务缓存的更新装置的框图。如图8所示，该业务缓存的更新装置还包括但不限于：响应模块581和存储模块583。

响应模块581，用于接收客户端发送的读请求，并通过响应读请求返回业务数据至客户端。

存储模块583，用于将返回的业务数据对应的业务标识存储至业务标识集合中。

在另一个示例性实施例中，该业务缓存的更新装置，还可以包括但不限于：删除模块。

该删除模块用于在业务标识集合的存储状态指示所述业务标识集合已存满时，删除业务标识集合中存储时间最长的业务标识，并在业务缓存中删除该业务标识对应的业务数据。

图9是根据一示例性实施例示出的一种装置600的硬件结构框图。该装置600可以是服务器，例如，在一示例性实施例中，该装置600可以是图1实施环境中的服务器130，可以用来安装、存储、运行图5中的数据库430、数据表缓存420和业务缓存460等。

参照图9，该装置600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processing units，CPU)622(例如，一个或一个以上处理器)和存储器632，一个或一个以上存储应用程序642或数据644的存储介质630(例如一个或一个以上海量存储设备)。其中，存储器632和存储介质630可以是短暂存储或持久存储。存储在存储介质630的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对装置600中的一系列指令操作。更进一步地，中央处理器622可以设置为与存储介质630通信，在装置600上执行存储介质630中的一系列指令操作。装置600还可以包括一个或一个以上电源626，一个或一个以上有线或无线网络接口650，一个或一个以上输入输出接口658，和/或，一个或一个以上操作***641，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。上述图2、图3和图4所示实施例中执行的步骤可以基于该图9所示的装置结构。

在示例性实施例中，本公开还提供另一种业务缓存的更新装置，该业务缓存的更新装置可以用于图9所示的装置600中，执行方法实施例中的全部或者部分步骤。所述装置包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行：

通过监听数据库中数据表的变化获取数据表变更记录；

根据所述数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，所述更新状态结果用于指示所述数据表缓存中的数据表是否更新成功；

在所述更新状态结果指示所述数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录；

根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中。

可选的，还提供了一种存储介质，该存储介质为计算机可读存储介质，例如可以为包括指令的临时性和非临时性计算机可读存储介质。该存储介指例如包括指令的存储器，上述指令可由装置的处理器执行以完成上业务缓存的更新方法。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围执行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (12)

1.一种业务缓存的更新方法，其特征在于，所述方法包括：

通过监听数据库中数据表的变化获取数据表变更记录；

根据所述数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，所述更新状态结果用于指示所述数据表缓存中的数据表是否更新成功；

在所述更新状态结果指示所述数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录；

根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中。

2.根据权利要求1所述的方法，其特征在于，所述通过监听数据库中数据表的变化获取数据表变更记录的步骤之前，所述方法还包括：

接收客户端发起的写请求，通过响应所述写请求生成所述数据表变更记录。

3.根据权利要求1所述的方法，其特征在于，所述根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中的步骤之前，所述方法还包括：

将所述业务记录添加至业务更新集合中；

相应地，所述将所述业务记录添加至业务更新集合中的步骤，包括：

判断所述业务记录中的业务标识是否存在于预先创建的业务标识集合中，所述业务标识集合用于存储业务缓存中业务数据对应的业务标识；

如果不存在，则将所述业务记录过滤；

否则，将业务标识存在于所述业务标识集合中的业务记录添加至所述业务更新集合中。

4.根据权利要求3所述的方法，其特征在于，所述将所述业务记录添加至业务更新集合中的步骤，包括：

根据所述业务记录中的业务标识对所述业务记录进行去重处理，删除业务标识重复的所述业务记录，并将去重处理后的业务记录添加至所述业务更新集合中。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收客户端发送的读请求，并通过响应所述读请求返回业务数据至所述客户端；

将返回的所述业务数据对应的业务标识存储至业务标识集合中。

6.根据权利要求5所述的方法，其特征在于，所述将返回的所述业务数据对应的业务标识存储至业务标识集合中的步骤之后，所述方法还包括：

在所述业务标识集合的存储状态指示所述业务标识集合已存满时，删除所述业务标识集合中存储时间最长的业务标识，并在业务缓存中删除该业务标识对应的业务数据。

7.一种业务缓存的更新装置，其特征在于，所述装置包括：

获取模块，用于通过监听数据库中数据表的变化获取数据表变更记录；

指示模块，用于根据所述数据表变更记录对数据表缓存中的数据表进行更新，得到更新状态结果，所述更新状态结果用于指示所述数据表缓存中的数据表是否更新成功；

生成模块，用于在所述更新状态结果指示所述数据表缓存中的数据表更新成功时，生成与更新成功的数据表相关的业务记录；

更新模块，用于根据所述业务记录进行数据组装得到业务数据，将所述业务数据更新至业务缓存中。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

接收模块，用于接收客户端发起的写请求，通过响应所述写请求生成所述数据表变更记录。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

添加模块，用于将所述业务记录添加至业务更新集合中；

相应地，所述添加模块，包括：

判断单元，用于判断所述业务记录中的业务标识是否存在于预先创建的业务标识集合中，所述业务标识集合用于存储业务缓存中业务数据对应的业务标识；

过滤单元，用于如果不存在，则将所述业务记录过滤；

添加单元，用于否则，将业务标识存在于所述业务标识集合中的业务记录添加至所述业务更新集合中。

10.根据权利要求9所述的装置，其特征在于，所述添加模块包括：

去重处理模块，用于根据所述业务记录中的业务标识对所述业务记录进行去重处理，删除业务标识重复的所述业务记录，并将去重处理后的业务记录添加至所述业务更新集合中。

11.根据权利要求7所述的装置，其特征在于，所述装置还包括：

响应模块，用于接收客户端发送的读请求，并通过响应所述读请求返回业务数据至所述客户端；

存储模块，用于将返回的所述业务数据对应的业务标识存储至业务标识集合中。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

删除模块，用于在所述业务标识集合的存储状态指示所述业务标识集合已存满时，删除所述业务标识集合中存储时间最长的业务标识，并在业务缓存中删除该业务标识对应的业务数据。