CN112182093A - 数据存储方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种数据存储方法、装置、设备及计算机可读存储介质；方法包括：获取第一用户发布的内容数据和针对所述内容数据的标签操作；将所述内容数据存储至第一数据库；基于所述内容数据和所述标签操作，生成标签更新消息；将所述标签更新消息加入消息处理队列；采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。通过本申请，能够提高基于标签进行内容数据搜索时的系统性能，从而能够更快地为用户返回搜索结果，提升用户使用体验。

Description

数据存储方法、装置、设备及计算机可读存储介质

技术领域

本申请涉及计算机存储技术，尤其涉及一种数据存储方法、装置、设备及计算机可读存储介质。

背景技术

随着信息技术的发展，论坛、社区等系统中由用户产生的内容(user generatecontent，UGC)越来越多，为便于用户从海量UGC数据中搜索到感兴趣的数据，可以通过为UGC数据(例如微博、帖子、推送消息等)添加合适的关键词、属性等标签，用户可以基于感兴趣的标签进行搜索，以获取与该标签相关的UGC数据。此外，还可以利用多个标签按照特定的条件聚合后进行搜索，从而获得更加精准的UGC数据。对于较为热门或常用的多个标签的聚合，可以将其作为新的聚合标签对UGC数据进行标签，用户可以直接基于聚合标签获得相应的UGC数据。

在相关技术中，通常采用MySQL数据库存储UGC数据，在进行搜索时通过查询语句对各UGC数据对应的标签进行条件筛选，得到搜索结果。但是在搜索请求量较大或基于复杂的聚合标签进行搜索时，数据库查询消耗的计算资源会变多、负载会变高且耗时也会增加，进而会影响UGC系统的整体性能，从而影响用户使用体验。

发明内容

本申请实施例提供一种数据存储方法、装置及计算机可读存储介质，能够提高基于标签进行内容数据搜索时的系统性能，从而能够更快地为用户返回搜索结果，提升用户使用体验。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种数据存储方法，包括：

获取第一用户发布的内容数据和针对所述内容数据的标签操作；

将所述内容数据存储至第一数据库；

基于所述内容数据和所述标签操作，生成标签更新消息；

将所述标签更新消息加入消息处理队列；

采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；

基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。

在一些实施例中，所述标签包括至少一个第一标签和至少一个第二标签，所述第二标签是由至少两个第一标签聚合得到的；所述第二数据库中存储有第一标签与内容数据列表之间的对应关系和第二标签与内容数据列表之间的对应关系；所述基于所述待处理的标签更新消息，更新第二数据库，包括：基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系；基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

在一些实施例中，所述基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系，包括：对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；根据所述标签操作，得到第一操作类型和第一标签列表；针对所述第一标签列表中的每一第一标签，根据所述第一操作类型和内容数据标识，在所述第二数据库中，更新所述第一标签以及与所述第一标签对应的内容数据列表。

在一些实施例中，所述基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系，包括：对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；根据所述标签操作，得到第一操作类型和第一标签列表；基于所述第一标签列表，在第三数据库中查询第三对应关系，得到与所述第一标签列表对应的第二标签列表；其中，所述第三对应关系用于表征第二标签和聚合配置信息之间的关联关系，所述聚合配置信息包括至少两个第一标签和所述至少两个第一标签的聚合方式；针对所述第二标签列表中的每一第二标签，根据所述第一操作类型和所述内容数据标识，在所述第二数据库中，更新所述第二标签以及与所述第二标签对应的内容数据列表。

在一些实施例中，所述方法还包括：获取第二用户针对第二标签的编辑操作；获取所述编辑操作对应的所述第二标签的聚合配置信息；获取所述编辑操作对应的第二操作类型；基于所述第二操作类型、所述第二标签和所述第二标签的聚合配置信息，更新第三数据库中第二标签和聚合配置信息之间的第三对应关系；基于更新后的第三对应关系，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

在一些实施例中，所述第一数据库中包括至少一条内容数据和每一所述内容数据对应的标签；所述方法还包括：按照特定的更新周期，定时基于所述第一数据库中的各内容数据和每一所述内容数据对应的标签，确定全量标签列表和所述全量标签列表中每一所述标签对应的内容数据列表；基于所述全量标签列表和每一所述标签对应的内容数据列表，采用批处理方式，全量更新所述第二数据库。

在一些实施例中，所述方法还包括：针对所述第二数据库中存储的每一标签，在所述标签对应的内容数据列表在特定的时长内持续为空的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除；或者，针对所述第二数据库中存储的每一标签，在特定的时长内未接收到针对所述标签的访问操作或编辑操作的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除。

在一些实施例中，所述方法还包括：响应于在内容数据查看界面针对所述标签的查询操作，基于所述标签，在所述第二数据库中查询与所述标签对应的内容数据列表；其中，所述内容数据列表中包括每一内容数据的标识；在所述内容数据查看界面显示内容数据标识列表，所述内容数据标识列表包括所述内容数据列表中每一内容数据的标识；响应于针对所述内容数据标识列表中内容数据标识的选择操作，基于所述内容数据标识，在所述第一数据库中查询与所述内容数据标识对应的内容数据；在所述内容数据查看界面显示所述内容数据。

本申请实施例提供一种数据存储装置，包括：

第一获取模块，用于获取第一用户发布的内容数据和针对所述内容数据的标签操作；

第一存储模块，用于将所述内容数据存储至第一数据库；

第一生成模块，用于基于所述内容数据和所述标签操作，生成标签更新消息；

第一加入模块，用于将所述标签更新消息加入消息处理队列；

第二获取模块，用于采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；

第一更新模块，用于基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。

在一些实施例中，所述标签包括至少一个第一标签和至少一个第二标签，所述第二标签是由至少两个第一标签聚合得到的；所述第二数据库中存储有第一标签与内容数据列表之间的对应关系和第二标签与内容数据列表之间的对应关系；所述第一更新模块还用于：基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系；基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

在一些实施例中，所述第一更新模块还用于：对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；根据所述标签操作，得到第一操作类型和第一标签列表；针对所述第一标签列表中的每一第一标签，根据所述第一操作类型和内容数据标识，在所述第二数据库中，更新所述第一标签以及与所述第一标签对应的内容数据列表。

在一些实施例中，所述第一更新模块还用于：对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；根据所述标签操作，得到第一操作类型和第一标签列表；基于所述第一标签列表，在第三数据库中查询第三对应关系，得到与所述第一标签列表对应的第二标签列表；其中，所述第三对应关系用于表征第二标签和聚合配置信息之间的关联关系，所述聚合配置信息包括至少两个第一标签和所述至少两个第一标签的聚合方式；针对所述第二标签列表中的每一第二标签，根据所述第一操作类型和所述内容数据标识，在所述第二数据库中，更新所述第二标签以及与所述第二标签对应的内容数据列表。

在一些实施例中，所述数据存储装置还包括：第三获取模块，用于获取第二用户针对第二标签的编辑操作；第四获取模块，用于获取所述编辑操作对应的所述第二标签的聚合配置信息；第五获取模块，用于获取所述编辑操作对应的第二操作类型；第二更新模块，用于基于所述第二操作类型、所述第二标签和所述第二标签的聚合配置信息，更新第三数据库中第二标签和聚合配置信息之间的第三对应关系；第三更新模块，用于基于更新后的第三对应关系，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

在一些实施例中，所述第一数据库中包括至少一条内容数据和每一所述内容数据对应的标签；所述数据存储装置还包括：确定模块，用于按照特定的更新周期，定时基于所述第一数据库中的各内容数据和每一所述内容数据对应的标签，确定全量标签列表和所述全量标签列表中每一所述标签对应的内容数据列表；第四更新模块，用于基于所述全量标签列表和每一所述标签对应的内容数据列表，采用批处理方式，全量更新所述第二数据库。

在一些实施例中，所述数据存储装置还包括：删除模块，用于：针对所述第二数据库中存储的每一标签，在所述标签对应的内容数据列表在特定的时长内持续为空的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除；或者，针对所述第二数据库中存储的每一标签，在特定的时长内未接收到针对所述标签的访问操作或编辑操作的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除。

在一些实施例中，所述数据存储装置还包括：第一查询模块，用于响应于在内容数据查看界面针对所述标签的查询操作，基于所述标签，在所述第二数据库中查询与所述标签对应的内容数据列表；其中，所述内容数据列表中包括每一内容数据的标识；第一显示模块，用于在所述内容数据查看界面显示内容数据标识列表，所述内容数据标识列表包括所述内容数据列表中每一内容数据的标识；第二查询模块，用于响应于针对所述内容数据标识列表中内容数据标识的选择操作，基于所述内容数据标识，在所述第一数据库中查询与所述内容数据标识对应的内容数据；第二显示模块，用于在所述内容数据查看界面显示所述内容数据。

本申请实施例提供一种数据存储设备，包括：存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的方法。

本申请实施例具有以下有益效果：

通过将内容数据存储至第一数据库中，将标签与内容数据列表之间的对应关系存储至第二数据库，并采用异步处理方法异步更新第二数据库中存储的标签与内容数据列表之间的对应关系。这样，可以在存储层将基于标签查询内容数据列表的功能与其他功能进行隔离解耦，从而可以有效提高用户基于标签查看内容数据列表时的系统性能，加速业务处理速度，提升用户使用体验，即使存在大量基于标签查看内容数据列表的请求，也不会影响系统的其他功能的用户使用体验。此外，由于在基于标签查看帖子列表时，由于第二数据库中已经存储了标签与内容数据列表之间的对应关系，因此只需进行简单查询，即可获得要查看标签对应的内容数据列表，从而可以快速响应用户的查看请求，并能实现快速翻页查询。

附图说明

图1A是相关技术中UGC系统的组成结构示意图；

图1B是本申请实施例提供的数据存储系统的一个可选的架构示意图；

图2是本申请实施例提供的数据存储装置的一个可选的结构示意图；

图3是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图4是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图5是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图6是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图7是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图8是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图9A是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图9B是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图10是本申请实施例提供的数据存储方法的一个可选的流程示意图；

图11A是本申请实施例提供的一种UGC系统的组成结构示意图；

图11B是本申请实施例提供的一种UGC系统中不同用户的操作权限示意图；

图11C是本申请实施例提供的一种发帖方法的实现流程示意图；

图11D是本申请实施例提供的一种配置标签聚合的方法的实现流程示意图；

图11E是本申请实施例提供的一种标签聚合数据增量更新方法的实现流程示意图；

图11F是本申请实施例提供的一种标签聚合数据全量更新方法的实现流程示意图；

图11G是本申请实施例提供的一种标签聚合数据全量更新方法的实现流程示意图；

图12是本申请实施例提供的一种增量更新标签数据的方法的实现流程示意图；

图13是本申请实施例提供的一种全量更新小标签帖子列表的方法的实现流程示意图；

图14是本申请实施例提供的一种全量更新大标签数据的方法的实现流程示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)由用户产生的内容(user generate content，UGC)，典型应用如论坛、社区等系统中用户发布的帖子、朋友圈、微博等。

2)聚合，是指将用户产生的内容(如帖子、微博等)按某些条件聚合得到内容列表(如帖子列表或微博列表等)，比如同一个作者发的帖子可以进行聚合。

3)标签聚合，是指按特定标签条件(比如帖子f1和帖子f2都有同一个标签t1)对用户产生的内容进行聚合得到内容列表，一般而言，标签条件可以包括&(与)和|(或)两种。

4)小标签，即用户在发布内容数据时添加的针对该内容数据的原始标签。比如帖子与小标签之间的关联关系可以如下表1-1所示，表1-1中，帖子包括f1、f2、f3，小标签包括t1至t6，帖子f1有小标签t1、t2、t3，帖子f2有小标签t4、t5、t6，帖子f3有小标签t1、t3、t5。

表1-1帖子与小标签之间的关联关系示例

帖子	小标签
		f1	t1
f1	t2
		f1	t3
f2	t4
		f2	t5
f2	t6
		f3	t1
f3	t3
		f3	t5
…	…

5)大标签，是产品运营人员配置的至少两个小标签聚合后的标签。例如，假设存在如下表1-2所示的小标签与帖子列表之间的对应关系：

表1-2小标签与帖子列表的对应关系示例

小标签	帖子列表
		t1	f1，f3
t2	f1
		t3	f1，f3
t4	f2
		t5	f2,f3
t6	f2
		…	…

产品运营人员可以配置大标签T1＝t1&t4，T2＝t1|t4，则大标签与帖子列表之间的对应关系可以如下表1-3所示，大标签T1对应的帖子列表为空列表，大标签T2对应的帖子列表包括f1、f2、f3。

表1-3大标签与帖子列表的对应关系示例

大标签	帖子列表
		T1＝t1&t4	(空列表)
T2＝t1|t4	f1，f2，f3
		…	…

6)信息流，是指持续更新并呈现给用户内容的内容流，例如，feed流。从结构来看，信息流是一个信息出口，想要了解该信息流中更多的相关内容，只需要刷新这一个动作，即可获得大量所需，并且不断在更新。

为了更好地理解本申请实施例提供的数据存储方法，下面先对相关技术中通过标签进行内容数据查询的技术方案进行说明。

以帖子搜索为例，参见图1A，图1A是相关技术中UGC系统的组成结构示意图。如图1A所示，相关技术中，作者111通过UGC系统120发布帖子，UGC系统120将作者111发布的帖子和作者111为该帖子添加的小标签存储在MySQL数据库131中，产品运营人员112可以在UGC系统120的管理端为M ySQL数据库131中存储的帖子添加小标签，还可以基于小标签配置大标签，U GC系统120的管理端可以将产品运营人员112编辑的大标签存储至聚合配置数据库132，用户113可以通过UGC系统120查看大标签或小标签下的帖子列表，UGC系统120可以根据用户113选择的小标签从MySQL数据库131中查询包括该小标签的帖子，UGC系统120还可以根据用户113选择的大标签从聚合配置数据库132中读取该大标签的聚合配置信息，并根据读取到的聚合配置信息从MySQL数据库131中查询满足该聚合配置信息的帖子。在相关技术中，UGC系统120从MySQL数据库131中查询帖子时，通过MySQL查询语句对MySQL数据库中的数据(帖子f，小标签t)做标签聚合计算，比如，查询小标签t1对应的帖子列表时，可以采用如下查询语句：

Select*from(帖子f,小标签t)where t＝“t1”limit 10,10；

查询小标签t4对应的帖子列表时，可以采用如下查询语句：

Select*from(帖子f,小标签t)where t＝“t4”limit 10,10；

查询大标签T1＝t1&t4对应的帖子列表时，可以采用如下查询语句：

Select table1.*,table2,*from(帖子f,小标签t)table1，(帖子f,小标签t)table2 where table1.t＝“t1”and table2.t＝“t4”limit 10,10；

查询大标签T2＝t1|t4对应的帖子列表时，可以采用如下查询语句：

Select*from(帖子f,小标签t)where t in(“t1”,“t4”)limit 10,10。

上述相关技术中的方案在查询请求量大时或配置的大标签聚合条件复杂时，对MYSQL帖子的存储数据进行查询消耗的计算资源会变多、负载会变高、耗时也会增加，从而会影响UGC系统的其他功能模块的用户使用体验，比如作者发帖子、产品运营为帖子打标签等功能模块的用户使用体验。

本申请实施例提供一种数据存储方法、装置、设备和计算机可读存储介质，能够提高基于标签进行内容数据搜索时的系统性能，从而能够更快地为用户返回搜索结果，提升用户使用体验。下面说明本申请实施例提供的数据存储设备的示例性应用，本申请实施例提供的数据存储设备可以实施为笔记本电脑，平板电脑，台式计算机，机顶盒，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)等各种类型的用户终端，也可以实施为服务器。下面，将说明设备实施为服务器时的示例性应用。

参见图1B，图1B是本申请实施例提供的数据存储系统100的一个可选的架构示意图，为实现支撑一个内容数据发布和查询的应用，终端(示例性示出了终端400-1和终端400-2)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。

终端用于：在图形界面(示例性示出了图形界面410-1和图形界面410-2)显示用户发布内容数据的交互界面，接收用户针对所述内容数据的标签操作，并将用户发布的内容数据和针对所述内容数据的标签操作发送至服务器200。

服务器200用于：获取第一用户发布的内容数据和针对所述内容数据的标签操作；将所述内容数据存储至第一数据库510；基于所述内容数据和所述标签操作，生成标签更新消息；将所述标签更新消息加入消息处理队列；采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；基于所述待处理的标签更新消息，更新第二数据库520；所述第二数据库520中存储有标签与内容数据列表之间的对应关系。

在一些实施例中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本发明实施例中不做限制。

参见图2，图2是本申请实施例提供的数据存储设备200的结构示意图，图2所示的数据存储设备200包括：至少一个处理器210、存储器250、至少一个网络接口220和用户接口230。数据存储设备200中的各个组件通过总线系统240耦合在一起。可理解，总线系统240用于实现这些组件之间的连接通信。总线系统240除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统240。

处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口230包括使得能够呈现媒体内容的一个或多个输出装置231，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口230还包括一个或多个输入装置232，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器250可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器250可选地包括在物理位置上远离处理器210的一个或多个存储设备。

存储器250包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器250旨在包括任意适合类型的存储器。

在一些实施例中，存储器250能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统251，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块252，用于经由一个或多个(有线或无线)网络接口220到达其他计算设备，示例性的网络接口220包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

呈现模块253，用于经由一个或多个与用户接口230相关联的输出装置231(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块254，用于对一个或多个来自一个或多个输入装置232之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的数据存储装置可以采用软件方式实现，图2示出了存储在存储器250中的数据存储装置255，其可以是程序和插件等形式的软件，包括以下软件模块：第一获取模块2551、第一存储模块2552、第一生成模块2553、第一加入模块2554、第二获取模块2555和第一更新模块2556，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。

将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的数据存储装置可以采用硬件方式实现，作为示例，本申请实施例提供的数据存储装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的数据存储方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific IntegratedCircuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)或其他电子元件。

下面将结合本申请实施例提供的终端或服务器的示例性应用和实施，说明本申请实施例提供的数据存储方法。

参见图3，图3是本申请实施例提供的数据存储方法的一个可选的流程示意图，下面将结合图3示出的步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

在步骤S101中，获取第一用户发布的内容数据和针对所述内容数据的标签操作。

这里，内容数据可以是帖子、微博、feed流等用户生成的内容，第一用户即为该内容数据的作者。

用户可以在进行内容数据发布时，对发布的内容数据进行标签操作，也可以在内容数据发布后，对已发布的内容数据进行标签操作，这里并不限定。标签操作可以包括但不限于为内容数据添加标签、删除标签、修改标签等中的一种或多种。标签可以是大标签，也可以是小标签，这里并不限定。

在步骤S102中，将所述内容数据存储至第一数据库。

这里，第一数据库可以是关系型数据库(例如MySQL、Oracle、SQLServer等)、也可以是非关系型数据库(例如远程字典服务(Remote Dictionary Server，Redis)、MongoDB等)。在实施时，本领域技术人员可以根据实际情况采用合适的数据库作为第一数据库，本申请实施例并不限定。

第一数据库中存储的内容可以包括但不限于内容数据的标题、正文、标签列表、图片、发布时间、作者等中的一种或多种。

在步骤S103中，基于所述内容数据和所述标签操作，生成标签更新消息。

这里，标签更新消息可以用于对该内容数据对应的标签数据进行更新。在实施时，标签更新消息可以是任意合适的消息队列(Message Queue，MQ)能够传输的消息，本领域技术人员可以根据实际采用的消息队列确定生成的标签更新消息的格式，这里并不限定。

在步骤S104中，将所述标签更新消息加入消息处理队列。

这里，消息处理队列可以是任意合适的消息队列，如Kafka、RabbitMQ、RocketMQ、ActiveMQ等，本领域技术人员可以根据实际情况采用合适的消息队列，这里并不限定。

在步骤S105中，采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息。

这里，可以采用任意合适的异步处理方式，从消息处理队列中获取标签更新消息，作为待处理的标签更新消息。例如，可以通过新建一个线程，从消息处理队列中消费MQ消息，获得待处理的标签更新消息，也可以采用特定的消息处理服务模块，对消息处理队列中的消息进行消费，获得待处理的标签更新消息。从消息处理队列中获取待处理的标签更新消息的消息消费策略可以是默认的，也可以是用户或产品运营人员设定的，例如，可以是逐个消费消息处理队列中的标签更新消息，也可以批量消费消息处理队列中的标签更新消息，这里并不限定。

在步骤S106中，基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。

这里，第二数据库可以是关系型数据库(例如MySQL、Oracle、SQLServer等)、也可以是非关系型数据库(例如Redis、MongoDB等)。在实施时，本领域技术人员可以根据实际情况采用合适的数据库作为第二数据库，本申请实施例并不限定。第二数据库中可以存储第一数据库中的内容数据涉及的部分或全部标签，以及该部分或全部标签中每一标签对应的内容数据列表。每一标签对应的内容数据列表中可以包括具有该标签的部分或全部内容数据中每一内容数据的标识，比如每一内容数据在第一数据库中存储的索引号、每一内容数据的标题、摘要等。用户可以根据标签对应的内容数据列表，识别具有该标签的内容数据。

基于待处理的标签更新消息，可以确定该标签更新消息对应的内容数据以及与该内容数据对应的标签操作和待更新的标签，基于该内容数据与待更新的标签之间的对应关系，可以更新第二数据库中存储的标签与内容数据列表之间的对应关系。例如，待处理的标签更新消息中可以包括内容数据f1和该内容数据要添加的标签t1，则当第二数据库中不存在标签t1时，可以在第二数据库中新增标签t1和t1对应的内容数据列表，并将内容数据f1加入该内容数据列表；当第二数据库中存在标签t1时，则可在与标签t1对应内容数据列表中新增内容数据f1。又如，待处理的标签更新消息中可以包括内容数据f1和该内容数据要删除的标签t2，则可将与标签t2对应内容数据列表中的内容数据f1移除。

本申请实施例中，通过将内容数据存储至第一数据库中，将标签与内容数据列表之间的对应关系存储至第二数据库，并采用异步处理方法异步更新第二数据库中存储的标签与内容数据列表之间的对应关系。这样，可以在存储层将基于标签查询内容数据列表的功能与其他功能进行隔离解耦，从而可以有效提高用户基于标签查看内容数据列表时的系统性能，加速业务处理速度，提升用户使用体验，即使存在大量基于标签查看内容数据列表的请求，也不会影响系统的其他功能的用户使用体验。此外，由于在基于标签查看帖子列表时，由于第二数据库中已经存储了标签与内容数据列表之间的对应关系，因此只需进行简单查询，即可获得要查看标签对应的内容数据列表，从而可以快速响应用户的查看请求，并能实现快速翻页查询。

在一些实施例中，参见图4，图4是本申请实施例提供的数据存储方法的一个可选的流程示意图，基于图3，所述标签包括至少一个第一标签和至少一个第二标签，所述第二标签是由至少两个第一标签聚合得到的；所述第二数据库中存储有第一标签与内容数据列表之间的对应关系和第二标签与内容数据列表之间的对应关系。图3示出的步骤S106可以通过步骤S401至步骤S402实现，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S401中，基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系。

这里，第一标签可以是大标签也可以是小标签，第二标签可以是至少两个任意合适的第一标签进行聚合后得到的标签，这里并不限定。在一些示例中，第一标签可以是小标签，第二标签可以是大标签。

步骤S402中，基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

这里，由于第二标签由至少两个第一标签聚合得到的，因此，在第一标签与内容数据列表之间的第一对应关系进行更新后，也需要对第二标签与内容数据列表之间的第二对应关系进行更新，从而保证第一对应关系与第二对应关系的同步更新。

本申请实施例中，在第一标签与内容数据列表之间的第一对应关系进行更新后，对第二标签与内容数据列表之间的第二对应关系也进行更新，可以有效保证第一对应关系与第二对应关系的同步更新，进而可以保证用户进行标签操作后第一对应关系和第二对应关系中数据的一致性。

在一些实施例中，参见图5，图5是本申请实施例提供的数据存储方法的一个可选的流程示意图，图4示出的步骤S401可以通过步骤S501至步骤S503实现，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S501中，对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作。

这里，标签更新消息中可以携带待处理的内容数据标识和标签操作。内容数据标识可以为用于识别内容数据的字符、数字、字符串等信息，例如，内容数据标识可以为内容数据在第一数据库中存储的索引号、内容数据的标题、摘要等。在实施时，本领域技术人员可以根据实际情况选择合适的信息作为内容数据的标识，本申请实施例并不限定。

步骤S502中，根据所述标签操作，得到第一操作类型和第一标签列表。

这里，第一操作类型为对内容数据进行的标签操作的类型，可以包括但不限于新增类型、删除类型、修改类型等中的一种或多种。第一标签列表为该标签操作所操作的第一标签的列表。例如，标签操作可以为对内容数据添加第一标签t1和t2，则第一操作类型可以为新增类型，第一标签列表可以包括第一标签t1和t2；标签操作还可以为删除内容数据的已有第一标签t3，则第一操作类型可以为删除类型，第一标签列表可以包括第一标签t3。

步骤S503中，针对所述第一标签列表中的每一第一标签，根据所述第一操作类型和内容数据标识，在所述第二数据库中，更新所述第一标签以及与所述第一标签对应的内容数据列表。

这里，第一标签列表中的第一标签可以是第二数据库中已经存储的，也可以是第二数据库中还未存储的。

对于第二数据库中已经存储的第一标签，可以根据第一操作类型和内容数据标识，更新第二数据库中该第一标签对应的内容数据列表，而不需要更新第二数据库中的第一标签。在实施时，本领域技术人员可以根据实际情况确定更新第一标签以及与第一标签对应的内容数据列表的方式，本申请实施例对此并不限定。例如，在第一操作类型为新增类型的情况下，可以将该内容数据标识添加至该第一标签对应的内容数据列表中；在第一操作类型为删除类型的情况下，可以将该内容数据标识从该第一标签对应的内容数据列表中删除。

对于第二数据库中还未存储的第一标签，需要在第二数据库中新增该第一标签，然后更新第二数据库中该第一标签对应的内容数据列表。

本申请实施例中，通过对待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作，根据标签操作，得到第一操作类型和第一标签列表，然后根据第一操作类型和内容数据标识，在第二数据库中，更新第一标签列表中的各第一标签以及与各第一标签对应的内容数据列表。这样，可以简单快速地更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系，从而可以提升第一对应关系的更新效率。

在一些实施例中，参见图6，图6是本申请实施例提供的数据存储方法的一个可选的流程示意图，图4示出的步骤S402可以通过步骤S601至步骤S604实现，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S601中，对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作。

步骤S602中，根据所述标签操作，得到第一操作类型和第一标签列表。

这里，步骤S601和步骤S602分别与前述步骤S501和步骤S502对应，在实施时，可以参照前述步骤S501和步骤S502的具体实施方式，这里不再赘述。

步骤S603中，基于所述第一标签列表，在第三数据库中查询第三对应关系，得到与所述第一标签列表对应的第二标签列表；其中，所述第三对应关系用于表征第二标签和聚合配置信息之间的关联关系，所述聚合配置信息包括至少两个第一标签和所述至少两个第一标签的聚合方式。

这里，第三数据库可以是关系型数据库(例如MySQL、Oracle、SQLServer等)、也可以是非关系型数据库(例如Redis、MongoDB等)。在实施时，本领域技术人员可以根据实际情况采用合适的数据库作为第三数据库，本申请实施例并不限定。

至少两个第一标签的聚合方式可以包括与操作、或操作等中的一种或多种。聚合配置信息中可以包括用于聚合得到与该聚合配置信息对应的第二标签的至少两个第一标签，以及针对至少两个第一标签的聚合方式。在实施时，聚合配置信息可以是用户配置的，也可以是系统自动生成的。例如，产品运营人员可以根据实际需要配置第二标签以及与该第二标签对应的聚合配置信息；系统也可以根据历史用户搜索记录，获得搜索热度高于特定阈值的多组第一标签，自动对每一组第一标签进行聚合，得到多个第二标签以及与每一第二标签对应的聚合配置信息。

第三数据库中可以存储第二标签和聚合配置信息之间的关联关系(也即第三对应关系)。针对第一标签列表中的每一第一标签，可以基于该第一标签，查询第三对应关系中聚合配置信息包括该第一标签的第二标签，从而可以得到与该第一标签对应的第二标签列表。对每一第一标签对应的第二标签列表求并集，可以得到第一标签列表对应的第二标签列表。

步骤S604中，针对所述第二标签列表中的每一第二标签，根据所述第一操作类型和所述内容数据标识，在所述第二数据库中，更新所述第二标签以及与所述第二标签对应的内容数据列表。

这里，第二标签列表中的第二标签可以是第二数据库中已经存储的，也可以是第二数据库中还未存储的。

对于第二数据库中已经存储的第二标签，可以根据第一操作类型和内容数据标识，更新第二数据库中该第二标签对应的内容数据列表，而不需要更新第二数据库中的第二标签。在实施时，本领域技术人员可以根据实际情况确定更新第二标签以及与第二标签对应的内容数据列表的方式，本申请实施例对此并不限定。例如，在第一操作类型为新增类型的情况下，可以将该内容数据标识添加至该第二标签对应的内容数据列表中；在第一操作类型为删除类型的情况下，可以将该内容数据标识从该第二标签对应的内容数据列表中删除。

对于第二数据库中还未存储的第二标签，需要在第二数据库中新增该第二标签，然后更新第二数据库中该第二标签对应的内容数据列表。

本申请实施例中，通过在第三数据库中查询第三对应关系，得到与第一标签列表对应的第二标签列表，针对第二标签列表中的每一第二标签，根据标签更新消息对应的第一操作类型和内容数据标识，在第二数据库中，更新第二标签列表中的每一第二标签以及与各第二标签分别对应的内容数据列表。这样，可以简单快速地更新第二数据库中存储的第二标签与内容数据列表之间的第二对应关系，从而可以提升第二对应关系的更新效率。

在一些实施例中，参见图7，图7是本申请实施例提供的数据存储方法的一个可选的流程示意图，基于图4，该方法还可以执行如下步骤S701至步骤S705，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S701中，获取第二用户针对第二标签的编辑操作。

这里，第二用户可以是具有第二标签编辑权限的任意用户。针对第二标签的编辑操作可以包括但不限于新增第二标签、删除第二标签、修改第二标签等中的一种或多种。

步骤S702中，获取所述编辑操作对应的所述第二标签的聚合配置信息；

这里，编辑操作中可以携带编辑的第二标签的聚合配置信息。

步骤S703中，获取所述编辑操作对应的第二操作类型；

这里，第二操作类型为对第二标签进行的编辑操作的类型，可以包括但不限于新增类型、删除类型、修改类型等中的一种或多种。

步骤S704中，基于所述第二操作类型、所述第二标签和所述第二标签的聚合配置信息，更新第三数据库中第二标签和聚合配置信息之间的第三对应关系；

这里，用户编辑的第二标签可以是第三数据库中已经存储的，也可以是第三数据库中还未存储的，这里并不限定。

对于用户编辑的第二标签，可以根据第二操作类型和第二标签的聚合配置信息，更新第二数据库中与该第二标签对应的聚合配置信息。在实施时，本领域技术人员可以根据实际情况确定更新第三对应关系的方式，本申请实施例对此并不限定。例如，在第二操作类型为新增类型的情况下，可以将该第二标签与该聚合配置信息之间的对应关系添加至第三数据库中；在第一操作类型为删除类型的情况下，可以将该第二标签与该聚合配置信息之间的对应关系从第三数据库中删除。

步骤S705中，基于更新后的第三对应关系，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

这里，可以根据用户编辑的第二标签查询第三数据库中存储的更新后的第三对应关系，得到更新后的第二标签对应的聚合配置信息。根据该聚合配置信息中的至少两个第一标签，在第二数据库中查询各第一标签对应的内容数据列表，并根据该聚合配置信息中各第一标签的聚合方式，对各第一标签对应的内容数据列表进行聚合，即可得到与第二标签对应的内容数据列表。基于该第二标签以及与该第二标签对应的内容数据列表，可以更新第二数据库中的第二对应关系。

本申请实施例中，可以根据用户对第二标签进行的编辑操作，更新第三数据库中存储的第二标签和聚合配置信息之间的第三对应关系以及第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。这样，用户可以自定义第二标签以及与第二标签对应的聚合配置信息，并能根据自定义的第二标签进行快速地内容数据搜索，进而能够加速业务处理速度，提升用户使用体验。

在一些实施例中，参见图8，图8是本申请实施例提供的数据存储方法的一个可选的流程示意图，基于图3，所述第一数据库中包括至少一条内容数据和每一所述内容数据对应的标签，该方法还可以执行如下步骤S801至步骤S802，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S801中，按照特定的更新周期，定时基于所述第一数据库中的各内容数据和每一所述内容数据对应的标签，确定全量标签列表和所述全量标签列表中每一所述标签对应的内容数据列表。

这里，特定的更新周期可以是用户设定的，也可以是系统默认值，例如1天1次、1周1次等。全量标签列表可以包括第一数据库中存储的每一内容数据对应的标签的集合，可以包括但不限于大标签、小标签等中的一种或多种。每一标签对应的内容数据列表中包括第一数据库中具有该标签的内容数据的标识。在实施时，可以通过遍历全量标签列表中的每一标签，将第一数据库中具有该标签的内容数据的标识加入与该标签对应的内容数据列表。

步骤S802中，基于所述全量标签列表和每一所述标签对应的内容数据列表，采用批处理方式，全量更新所述第二数据库。

这里，可以采用任意合适的批处理方式对所述第二数据库中的标签与内容列表之间的对应关系进行全量更新，包括但不限于执行批处理脚本、多线程并发执行等方式，本申请实施例对此并不限定。

需要说明的是，上述步骤S801和步骤S802可以是离线流程，在实施时，可以开启特定的线程执行该离线流程，或者可以通过系统中特定的服务模块执行该离线流程，这里并不限定。

本申请实施例中，通过批处理方式定时全量更新第二数据库中标签与内容列表之间的对应关系，可以有效避免标签更新消息丢失或处理失败导致的第一数据库与第二数据库中数据不一致的问题，保证第一数据库与第二数据库中数据的最终一致性，进而可以提高用户查看内容数据列表时的准确性，进一步提升用户使用体验。

在一些实施例中，参见图9A，图9A是本申请实施例提供的数据存储方法的一个可选的流程示意图，基于图3，该方法还可以执行如下步骤S901，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S901中，针对所述第二数据库中存储的每一标签，在所述标签对应的内容数据列表在特定的时长内持续为空的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除。

这里，特定的时长可以是用户设定的也可以是系统默认值，这里并不限定。在实施时，可以根据实际情况确定合适的时长，例如可以是1周、1个月、半年等。

本申请实施例中，通过将对应的内容数据列表在特定时长内持续为空的标签删除，可以实现对标签的定期清理，从而可以减少对失效的标签的维护和存储成本。

在一些实施例中，参见图9B，图9B是本申请实施例提供的数据存储方法的一个可选的流程示意图，基于图3，该方法还可以执行如下步骤S902，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S902中，针对所述第二数据库中存储的每一标签，在特定的时长内未接收到针对所述标签的访问操作或编辑操作的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除。

这里，针对标签的访问操作可以包括但不限于对该标签的相关信息进行查看的操作、基于该标签进行内容数据列表查看的操作。在一些示例中，当标签为大标签时，对该大标签的访问操作还可以包括对该标签的聚合配置信息的查看操作或对该大标签对应的至少两个小标签的查看操作等。

特定的时长可以是用户设定的也可以是系统默认值，这里并不限定。在实施时，可以根据实际情况确定合适的时长，例如可以是1周、1个月、半年等。

本申请实施例中，通过将在特定的时长内未接收到访问操作或编辑操作的标签删除，可以实现对标签的定期清理，从而可以减少对失效的标签的维护和存储成本。

在一些实施例中，参见图10，图10是本申请实施例提供的数据存储方法的一个可选的流程示意图，基于图3，该方法还可以执行如下步骤S1001至步骤S1004，下面将结合各步骤进行说明，下述步骤的执行主体可以是前文的终端或服务器。

步骤S1001中，响应于在内容数据查看界面针对所述标签的查询操作，基于所述标签，在所述第二数据库中查询与所述标签对应的内容数据列表；其中，所述内容数据列表中包括每一内容数据的标识。

这里，内容数据查看界面可以是用户进行内容数据查看的界面，用户在内容数据查看界面中针对标签执行查询操作。在实施时，可以通过点击或触摸内容数据查看界面中的标签触发查询操作，也可以通过在搜索框中输入标签后点击或触摸查询按钮触发查询操作，本领域技术人员可以根据实际情况确定触发查询操作的方式，这里并不限定。

步骤S1002中，在所述内容数据查看界面显示内容数据标识列表，所述内容数据标识列表包括所述内容数据列表中每一内容数据的标识。

这里，内容数据的标识可以为用于识别内容数据的字符、数字、字符串等信息，例如，内容数据标识可以为内容数据在第一数据库中存储的索引号、内容数据的标题、摘要等。在实施时，本领域技术人员可以根据实际情况选择合适的信息作为内容数据的标识，本申请实施例并不限定。

步骤S1003中，响应于针对所述内容数据标识列表中内容数据标识的选择操作，基于所述内容数据标识，在所述第一数据库中查询与所述内容数据标识对应的内容数据。

这里，选择操作可以包括但不限于对内容数据标识列表中的内容数据标识的点击或触摸操作等。在实施时，本领域技术人员可以根据实际情况确定合适的选择操作，本申请实施例并不限定。

步骤S1004中，在所述内容数据查看界面显示所述内容数据。

这里，显示的内容数据可以包括但不限于该内容数据的标题、正文、图片、视频等中的一种或多种。

本申请实施例中，可以在内容数据查看界面基于标签进行内容数据列表的查询，并响应于针对内容数据列表中的内容数据标识的选择操作显示选择的内容数据。由于可以直接在第二数据库中查询与标签对应的内容数据列表，无需进行复杂的标签聚合计算，因此，可以有效减少基于标签查看内容数据列表时的系统计算复杂度，从而可以提高系统性能，加速业务处理速度，进而可以提升用户的使用体验。进一步地，还可以实现快速翻页查询，从而进一步提升用户的使用体验。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。本申请实施例提供的方法可以应用于论坛的帖子存储、社区平台的微博存储、信息推送平台的feed流数据存储等场景。

以论坛的帖子(即作品)存储场景为例，参见图11A，图11A是本申请实施例提供的一种UGC系统的组成结构示意图。如图11A所示，该系统包括：接入层1110、消息队列(message queue，MQ)模块1120、存储层1130和批处理模块1140，其中，接入层1110包括作品详情公共网关接口(Common Gateway Interface，CGI)1111、作品操作CGI 1112、发布器CGI1113、标签聚合CGI 1114，存储层1130包括采用MySQL数据库进行存储的作品存储模块1131、采用Redis的string数据结构进行存储的作品操作存储模块1132、采用Redis的zset数据结构进行存储的标签聚合存储模块1133。

这里，作品存储模块可以用于存储全部用户发布的全部作品，即全量数据。作品操作存储模块可以用于存储用户对作品的阅读、点赞、评论等操作相关的数据。标签聚合存储模块可以用于存储各标签对应的作品列表。

上述UGC系统中针对不同用户角色可以提供不同的操作权限，参见图11B，图11B是本申请实施例提供的一种UGC系统中不同用户的操作权限示意图，如图11B所示，发布帖子的作者1101可以进行帖子/文章/feed的管理操作1103(如发布、删除等)和帖子/文章/feed的普通操作1104(如阅读、点赞、评论等)，其他用户1102可以进行帖子/文章/feed的普通操作1104(如阅读、点赞、评论等)。该系统具体可以实现如下业务：

1)用户发布帖子或feed数据等作品；这里，可以在请求接入层的发布器CGI，将用户发布的帖子或feed数据通过存储层的作品存储模块保存至MySQL数据库。

2)作者(即发布帖子的用户)或其他用户阅读、点赞或评论作品；这里，可以请求接入层的作品操作CGI，将用户对作品的阅读、点赞、评论等操作相关的数据通过存储层的作品操作存储模块存储至Redis中。

3)作者或其他用户查看小标签或大标签下的作品列表。这里，可以请求接入层的标签聚合CGI，通过存储层的标签聚合存储模块从Redis中读取作者或其他用户查看小标签或大标签下的作品列表。

参见图11C，图11C是本申请实施例提供的一种发帖方法的实现流程示意图，该方法包括如下步骤：

步骤S1151，作者在UGC系统120上执行发布帖子操作；

步骤S1152，UGC系统120将用户发布的帖子信息写入MySQL数据库131；

步骤S1153，UGC系统120生产MQ消息，并通知批处理模块121执行标签聚合数据的更新。这里，作者发帖时可以为帖子或feed数据加上小标签，MQ消息的内容可以包括帖子、标签的操作内容等。

参见图11D，图11D是本申请实施例提供的一种配置标签聚合的方法的实现流程示意图，该方法包括如下步骤：

步骤S1161，产品运营人员通过UGC系统的管理端122对帖子的小标签进行编辑操作；这里，对小标签进行的编辑操作可以包括小标签的增加、删除、修改等操作。

步骤S1162，产品运营人员通过UGC系统的管理端122对大标签做编辑操作；这里，对大标签进行的编辑操作可以包括大标签的增加、删除、修改等操作。

参见图11E，图11E是本申请实施例提供的一种标签聚合数据增量更新方法的实现流程示意图，该方法包括如下步骤：

步骤S1171，UGC系统120的批处理模块121消费MQ消息，对于MQ消息中指定的帖子，在Redis数据库133中更新对应的小标签、大标签下的帖子列表。

参见图11F，图11F是本申请实施例提供的一种标签聚合数据全量更新方法的实现流程示意图，该方法包括如下步骤：

步骤S1181，定时更新所有小标签的帖子列表。

步骤S1182，定时更新所有大标签的帖子列表。

参见图11G，图11G是本申请实施例提供的一种标签聚合数据全量更新方法的实现流程示意图，该方法包括如下步骤：

步骤S1191，用户在UGC系统120上请求查看标签的帖子列表。

这里，标签可以是大标签也可以是小标签。

步骤S1192，UGC系统120读取该标签的聚合配置信息。

这里，聚合配置信息可以包括大标签与小标签之间的聚合对应关系。

步骤S1193，UGC系统120在Redis数据库133中读取该标签的帖子列表。

在一些实施例中，上述图11E中示出的步骤S1171可以采用如图12所示的方法实现，参见图12，图12为本申请实施例提供的一种增量更新标签数据的方法的实现流程示意图，该方法可以由UGC系统的批处理模块执行，包括如下步骤：

步骤S1201，从消息队列中获取消费的MQ消息，MQ消息中包括帖子f和标签操作内容；

步骤S1202，解析标签操作内容，得到新增的小标签列表add_ts和删除的小标签列表del_ts，并对add_ts和del_ts中的每一小标签进行归一化处理；

这里，对小标签的归一化处理可以包括但不限于英文字母的大写转小写、空格去除、将&和|替换为其他特定字符等。

步骤S1203，在Redis中，更新del_ts中的每一个小标签对应的帖子列表，更新add_ts中的每一个小标签对应的帖子列表；

这里，假设del_ts中存在小标签t1，更新小标签t1对应的帖子列表时可以采用Redis命令：zrem key f，其中，令key＝t1。

假设add_ts中存在小标签t2，更新小标签t2对应的帖子列表时可以采用R edis命令：zadd key f f，其中，令key＝t2。

步骤S1204，获取全部的大标签配置信息；

步骤S1205，确定add_ts对应的大标签列表add_TS，确定del_ts对应的大标签列表del_TS；

这里，add_TS中包括对add_ts中各个小标签对应的大标签进行去重后的集合，可以通过遍历add_ts中每个t对应的T得到add_TS。del_TS中包括对del_ts中各个小标签对应的大标签进行去重后的集合，可以通过遍历del_ts中每个t对应的T得到del_TS。

步骤S1206，在Redis中，更新del_TS中的每一个大标签对应的帖子列表，更新add_TS中的每一个大标签对应的帖子列表，并为del_TS和add_TS中的每一大标签设置有效时长；

这里，对于del_TS中的每一个大标签T1，可以对T1进行归一化处理和排序处理得到该T1对应的key，更新大标签T1对应的帖子列表时可以采用Redis命令：zrem key f，其中，令key＝T1。

对于add_TS中的每一个大标签T2，可以对T2进行归一化处理和排序处理得到该T2对应的key，更新大标签T2对应的帖子列表时可以采用Redis命令：zadd key f f，其中，令key＝T2。

对del_TS和add_TS中的大标签进行的归一化处理可以包括但不限于英文字母的大写转小写、空格取去除、聚合条件表达式的统一变换等。排序处理可以包括但不限于按照字母先后顺序进行排序、按照数字大小顺序进行排序等中的一种或多种。

为大标签设置有效时长时，可以采用Redis命令：expire key time，其中，key为需要设置有效时长的大标签的键，time为该大标签配置的有效时长。

当该大标签下无帖子或在配置的有效时长内没有用户对该大标签进行更新或没有用户通过点击该标签查看该大标签下的帖子列表时，Redis会自动对该大标签和该大标签对应的帖子列表进行清除。

在一些实施例中，还可以为小标签配置有效时长，当该小标签下无帖子或在配置的有效时长内没有用户对该小标签进行更新或没有用户通过点击该小标签查看该小标签下的帖子列表时，Redis会自动对该小标签和该小标签对应的帖子列表进行清除。

在一些实施例中，上述图11F中示出的步骤S1181可以采用如图13所示的方法实现，参见图13，图13为本申请实施例提供的一种全量更新小标签帖子列表的方法的实现流程示意图，该方法可以由UGC系统的批处理模块执行，包括如下步骤：

步骤S1301，定时触发小标签更新任务；

这里，小标签更新任务可以是按照特定的更新周期触发，比如1周1次、1天1次等。

步骤S1302，获取MySQL数据库中存储的帖子中的所有小标签的集合ts，并对ts中每一小标签进行归一化处理；

步骤S1303，循环获取ts中的每一小标签t；

步骤S1304，针对当前获取的小标签，获取MySQL中具有该小标签的全量帖子列表，将该全量帖子列表存储至Redis中；

这里，定时触发的更新任务为离线流程，为避免更新过程中线上流程访问的数据不一致，可以区别于线上流程使用的各小标签，另外存储一份更新后的全量帖子列表作为与线上流程中各小标签对应的帖子列表。在实施时，假设M ySQL中存在小标签t，该小标签t对应的全量帖子列表为fs(f1，f2，f3，……)，可以采用Redis命令：zadd key_calculate f1f1 f2 f2 f3 f3……，其中，key_calculate为与小标签t对应的全量帖子列表的键。

步骤S1305，在Redis中，利用该小标签对应的全量帖子列表替换该小标签对应的原帖子列表。

这里，在将小标签对应的帖子列表替换为该小标签对应的全量帖子列表时，可以采用Redis命令：rename key_calculate key，其中，key_calculate为全量帖子列表的键，key为原帖子列表的键。

在一些实施例中，上述图11F示出的步骤S1182可以采用如图14所示的方法实现，参见图14，图14为本申请实施例提供的一种全量更新大标签数据的方法的实现流程示意图，该方法可以由UGC系统的批处理模块执行，包括如下步骤：

步骤S1401，定时触发大标签更新任务；

这里，小标签更新任务可以是按照特定的更新周期触发，比如1周1次、1天1次等。

步骤S1402，获取所有的大标签配置信息TS；

步骤S1403，循环获取TS中的每一大标签配置信息；

步骤S1404，对于获取的大标签配置信息，获取该大标签配置信息中的大标签T，对该大标签T进行归一化处理和排序处理，并对该大标签进行语义解析，得到op1、op1_ts、op2、op2_ts、op和key_T；

这里，key_T为大标签T的唯一标识，通过语义解析可以得到大标签配置信息中的参数op1、op1_ts、op2、op2_ts、op，基于参数op1、op1_ts、op2、op2_ts、op可以确定key_T。

对标签进行语义解析的具体过程可以为：对于任意的归一化处理后的小标签t，key_t＝t为小标签t的唯一标识；对于任意的归一化处理后的大标签T＝function(t1,t2,t3,...)，function为&和|。大标签T可以语义解析为T＝op1(op1_list)op op2(op2_list)，以等式的右值计算并作为T的唯一标识key_T，其中，op1_list和op2_list分别为两个标签列表；op1为对op1_list中各标签进行聚合的方式，可以是与(&)，也可以是或(|)；op2为对op2_list中各标签进行聚合的方式，可以是&，也可以是|；op为对op1和op2操作的结果中各标签进行聚合的方式，可以是&，也可以是|。

比如T＝t4&t1，对T进行语义解析后可以得到：op1＝空值，op1_list＝t1，op2＝空值，op2_list＝t4，op＝&，key_T＝key(t1)&key(t4)＝t1&t4。

比如T＝(t2|t4)&t1＝(t2|t1)&(t4|t1)＝(t1|t2)&(t1|t4)，对T进行语义解析后可以得到：op1＝or，op1_list＝(t1,t2)，op2＝|，op2_list＝(t1,t4)，op＝&，key_T＝(t1|t2)&(t1|t4)。

步骤S1405，将key_op1、key_op2、key_op_all均初始化为空值；

这里，key_op1、key_op2分别为op1的计算结果和op2的计算结果在Redis中对应的键，key_op_all为op的计算结果在Redis中对应的键。

步骤S1406，判断op1_ts中的标签数量是否大于1；若不是，则跳转至步骤S1407；若是，则跳转至步骤S1408；

步骤S1407，在op1_ts中的标签数量等于1的情况下，确定key_op1为op1_ts的首元素；在op1_ts中的标签数量等于0的情况下，进行错误告警；跳转至步骤S1409。

步骤S1408，在op1为&的情况下，将opt1_ts中各标签对应的帖子列表的交集确定为key_op1对应的帖子列表；在op1为|的情况下，将opt1_ts中各标签对应的帖子列表的并集确定为key_op1对应的帖子列表。

这里，Redis的zset数据结构可以对n个key的集合keys(key1,key2,key3,...，keyn)进行与操作(&)，命令为：zinerstore dest n key1 key2 key3…keyn AGGREGATEMAX，其中n为正整数。下文简写为REDIS_ZSET_AND(dest,keys)。

Redis的zset数据结构还可以对n个key的集合keys(key1,key2,key3,...，keyn)进行或操作(|)，命令为：zunionstore dest n key1 key2 key3…keyn AGGREGATE MAX，其中n为正整数。下面简写为REDIS_ZSET_OR(dest,keys)。

在实施时，计算opt1_ts中各标签对应的帖子列表的交集时，可以采用Redis命令：REDIS_ZSET_AND(key_op1,op1_ts)。计算opt1_ts中各标签对应的帖子列表的并集时，可以采用Redis命令：REDIS_ZSET_OR(key_op1,op1_ts)。

步骤S1409，判断op2_ts中的标签数量是否大于1；若不是，则跳转至步骤S1410；若是，则跳转至步骤S1411。

步骤S1410，在op2_ts中的标签数量等于1的情况下，确定key_op2为op2_ts的首元素；在op2_ts中的标签数量等于0的情况下，进行错误告警；跳转至步骤S1412。

步骤S1411，在op2为&的情况下，将opt2_ts中各标签对应的帖子列表的交集确定为key_op2对应的帖子列表；在op2为|的情况下，将opt2_ts中各标签对应的帖子列表的并集确定为key_op2对应的帖子列表。

这里，计算opt2_ts中各标签对应的帖子列表的交集时，可以采用Redis命令：REDIS_ZSET_AND(key_op2,op2_ts)。计算opt2_ts中各标签对应的帖子列表的并集时，可以采用Redis命令：REDIS_ZSET_OR(key_op2,op2_ts)。

步骤S1412，判断op是否为&；若不是，则跳转至步骤S1413；若是，则跳转至步骤S1414。

步骤S1413，在op为|的情况下，将key_op1对应的帖子列表与key_op2对应的帖子列表的并集作为key_op_all对应的帖子列表。

这里，可以通过执行如下Redis命令计算key_op1对应的帖子列表与key_op2对应的帖子列表的并集：

keys＝(key_op1,key_op2)；REDIS_ZSET_OR(key_op_all,keys)。

步骤S1414，将key_op1对应的帖子列表与key_op2对应的帖子列表的交集作为key_op_all对应的帖子列表。

这里，可以通过执行如下Redis命令计算key_op1对应的帖子列表与key_op2对应的帖子列表的交集：

keys＝(key_op1,key_op2)；REDIS_ZSET_AND(key_op_all,keys)。

步骤S1415，在将key_T对应的帖子列表替换为key_op_all对应的帖子列表，并为key_T配置有效时长。

这里，在将key_T对应的帖子列表替换为key_op_all对应的帖子列表时，可以采用Redis命令：rename key_op_all key_T。为key_T配置有效时长时，可以采用Redis命令：expire key_T time，time为key_T配置的有效时长。

需要说明的是，在实施时，用户发布的帖子可以作为前述实施例中的内容数据，小标签可以作为前述实施例中的第一标签，大标签可以作为前述实施例中的第二标签。

本申请实施例具有如下有益效果：

1)通过消息队列增量更新、定时全量更新异步批处理实现标签的聚合，在存储层将对标签进行聚合的功能与作者发帖、产品配置进行隔离解耦，并将标签与帖子列表之间的对应关系与帖子信息、产品配置相关的数据隔离存储。这样，可以有效提高用户基于标签查看帖子列表时的系统性能，加速业务处理速度，即使存在大量基于标签查看帖子列表的请求或者存在复杂的聚合条件，也不会影响UGC系统的作者发帖、产品配置等其他功能的用户使用体验。

2)由于在用户发布帖子或更新标签配置信息时，已对标签进行聚合，并将聚合后的标签及标签对应的帖子列表存储至Redis中，这样，在基于标签查看帖子列表时，只需从Redis中进行简单查询，即可获得要查看的帖子列表，计算简单，可实现快速翻页。此外，由于Redis查询过程为内存的访问，相比于基于访问磁盘的数据库，查询速度更快，并且标签与帖子列表的对应关系采用Redis中的zset数据结构进行数据存储，由于zset数据结构本身具有方便实现快速翻页查询的特性，因此可以进一步提高翻页查询的速度，提升用户体验。

(3)通过为标签设置有效时长，能对标签进行定期清理，减少了对失效的标签的维护和存储成本。

下面继续说明本申请实施例提供的数据存储装置255的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器250的数据存储装置255中的软件模块可以包括：

第一获取模块2551，用于获取第一用户发布的内容数据和针对所述内容数据的标签操作；

第一存储模块2552，用于将所述内容数据存储至第一数据库；

第一生成模块2553，用于基于所述内容数据和所述标签操作，生成标签更新消息；

第一加入模块2554，用于将所述标签更新消息加入消息处理队列；

第二获取模块2555，用于采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；

第一更新模块2556，用于基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。

在一些实施例中，所述标签包括至少一个第一标签和至少一个第二标签，所述第二标签是由至少两个第一标签聚合得到的；所述第二数据库中存储有第一标签与内容数据列表之间的对应关系和第二标签与内容数据列表之间的对应关系；所述第一更新模块还用于：基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系；基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

在一些实施例中，所述第一更新模块还用于：对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；根据所述标签操作，得到第一操作类型和第一标签列表；针对所述第一标签列表中的每一第一标签，根据所述第一操作类型和内容数据标识，在所述第二数据库中，更新所述第一标签以及与所述第一标签对应的内容数据列表。

在一些实施例中，所述第一更新模块还用于：对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；根据所述标签操作，得到第一操作类型和第一标签列表；基于所述第一标签列表，在第三数据库中查询第三对应关系，得到与所述第一标签列表对应的第二标签列表；其中，所述第三对应关系用于表征第二标签和聚合配置信息之间的关联关系，所述聚合配置信息包括至少两个第一标签和所述至少两个第一标签的聚合方式；针对所述第二标签列表中的每一第二标签，根据所述第一操作类型和所述内容数据标识，在所述第二数据库中，更新所述第二标签以及与所述第二标签对应的内容数据列表。

在一些实施例中，所述数据存储装置还包括：第三获取模块，用于获取第二用户针对第二标签的编辑操作；第四获取模块，用于获取所述编辑操作对应的所述第二标签的聚合配置信息；第五获取模块，用于获取所述编辑操作对应的第二操作类型；第二更新模块，用于基于所述第二操作类型、所述第二标签和所述第二标签的聚合配置信息，更新第三数据库中第二标签和聚合配置信息之间的第三对应关系；第三更新模块，用于基于更新后的第三对应关系，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

在一些实施例中，所述第一数据库中包括至少一条内容数据和每一所述内容数据对应的标签；所述数据存储装置还包括：确定模块，用于按照特定的更新周期，定时基于所述第一数据库中的各内容数据和每一所述内容数据对应的标签，确定全量标签列表和所述全量标签列表中每一所述标签对应的内容数据列表；第四更新模块，用于基于所述全量标签列表和每一所述标签对应的内容数据列表，采用批处理方式，全量更新所述第二数据库。

在一些实施例中，所述数据存储装置还包括：删除模块，用于：针对所述第二数据库中存储的每一标签，在所述标签对应的内容数据列表在特定的时长内持续为空的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除；或者，针对所述第二数据库中存储的每一标签，在特定的时长内未接收到针对所述标签的访问操作或编辑操作的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除。

在一些实施例中，所述数据存储装置还包括：第一查询模块，用于响应于在内容数据查看界面针对所述标签的查询操作，基于所述标签，在所述第二数据库中查询与所述标签对应的内容数据列表；其中，所述内容数据列表中包括每一内容数据的标识；第一显示模块，用于在所述内容数据查看界面显示内容数据标识列表，所述内容数据标识列表包括所述内容数据列表中每一内容数据的标识；第二查询模块，用于响应于针对所述内容数据标识列表中内容数据标识的选择操作，基于所述内容数据标识，在所述第一数据库中查询与所述内容数据标识对应的内容数据；第二显示模块，用于在所述内容数据查看界面显示所述内容数据。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的数据存储方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的数据存储方法，例如，如图3示出的方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，通过本申请实施例能够提高基于标签进行内容数据搜索时的系统性能，从而能够更快地为用户返回搜索结果，提升用户使用体验，此外，还能对标签进行定期清理，减少了对失效的标签的维护和存储成本。

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

Claims (10)

1.一种数据存储方法，其特征在于，包括：

获取第一用户发布的内容数据和针对所述内容数据的标签操作；

将所述内容数据存储至第一数据库；

基于所述内容数据和所述标签操作，生成标签更新消息；

将所述标签更新消息加入消息处理队列；

采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；

基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。

2.根据权利要求1所述的方法，其特征在于，所述标签包括至少一个第一标签和至少一个第二标签，所述第二标签是由至少两个第一标签聚合得到的；所述第二数据库中存储有第一标签与内容数据列表之间的对应关系和第二标签与内容数据列表之间的对应关系；

所述基于所述待处理的标签更新消息，更新第二数据库，包括：

基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系；

基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

3.根据权利要求2所述的方法，其特征在于，所述基于所述待处理的标签更新消息，更新第二数据库中存储的第一标签与内容数据列表之间的第一对应关系，包括：

对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；

根据所述标签操作，得到第一操作类型和第一标签列表；

针对所述第一标签列表中的每一第一标签，根据所述第一操作类型和内容数据标识，在所述第二数据库中，更新所述第一标签以及与所述第一标签对应的内容数据列表。

4.根据权利要求2所述的方法，其特征在于，所述基于所述第一对应关系和所述待处理的标签更新消息，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系，包括：

对所述待处理的标签更新消息进行解析，得到待处理的内容数据标识和标签操作；

根据所述标签操作，得到第一操作类型和第一标签列表；

基于所述第一标签列表，在第三数据库中查询第三对应关系，得到与所述第一标签列表对应的第二标签列表；其中，所述第三对应关系用于表征第二标签和聚合配置信息之间的关联关系，所述聚合配置信息包括至少两个第一标签和所述至少两个第一标签的聚合方式；

针对所述第二标签列表中的每一第二标签，根据所述第一操作类型和所述内容数据标识，在所述第二数据库中，更新所述第二标签以及与所述第二标签对应的内容数据列表。

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

获取第二用户针对第二标签的编辑操作；

获取所述编辑操作对应的所述第二标签的聚合配置信息；

获取所述编辑操作对应的第二操作类型；

基于所述第二操作类型、所述第二标签和所述第二标签的聚合配置信息，更新第三数据库中第二标签和聚合配置信息之间的第三对应关系；

基于更新后的第三对应关系，更新所述第二数据库中存储的第二标签与内容数据列表之间的第二对应关系。

6.根据权利要求1所述的方法，其特征在于，所述第一数据库中包括至少一条内容数据和每一所述内容数据对应的标签；所述方法还包括：

按照特定的更新周期，定时基于所述第一数据库中的各内容数据和每一所述内容数据对应的标签，确定全量标签列表和所述全量标签列表中每一所述标签对应的内容数据列表；

基于所述全量标签列表和每一所述标签对应的内容数据列表，采用批处理方式，全量更新所述第二数据库。

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

针对所述第二数据库中存储的每一标签，在所述标签对应的内容数据列表在特定的时长内持续为空的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除；

或者，针对所述第二数据库中存储的每一标签，在特定的时长内未接收到针对所述标签的访问操作或编辑操作的情况下，在所述第二数据库中将所述标签以及与所述标签对应的内容数据列表删除。

8.一种数据存储装置，其特征在于，包括：

第一获取模块，用于获取第一用户发布的内容数据和针对所述内容数据的标签操作；

第一存储模块，用于将所述内容数据存储至第一数据库；

第一生成模块，用于基于所述内容数据和所述标签操作，生成标签更新消息；

第一加入模块，用于将所述标签更新消息加入消息处理队列；

第二获取模块，用于采用异步处理方式，从所述消息处理队列中获取待处理的标签更新消息；

第一更新模块，用于基于所述待处理的标签更新消息，更新第二数据库；所述第二数据库中存储有标签与内容数据列表之间的对应关系。

9.一种数据存储设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于被处理器执行时，实现权利要求1至7任一项所述的方法。

Images