CN117708461A - 用户发布内容处理方法、装置、计算设备及存储介质 - Google Patents

Abstract

本申请实施例公开了一种用户发布内容处理方法、装置、计算设备及存储介质，其中，该方法包括：将各个发布内容划分为冷数据和热数据，利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容；接收访问用户的内容访问请求，获取与内容访问请求对应的多个维度下的关联数据；将关联数据与预设决策数据进行匹配，从冷数据存储系统和热数据存储系统中确定待访问系统；从待访问系统中读取目标发布内容。本申请采用不同的存储系统对冷、热数据进行区分存储，实现了冷热数据分级保障的效果，既能有效地保障属于热数据的发布内容的访问实时性，又能降低属于冷数据的发布内容的存储成本，提高了系统稳定性和可用性。

Description

用户发布内容处理方法、装置、计算设备及存储介质

技术领域

本申请实施例涉及数据处理技术领域，具体涉及一种用户发布内容处理方法、装置、计算设备及存储介质。

背景技术

随着互联网技术的发展，越来越多的用户喜欢在一些业务平台中分享短视频、动态、文章等发布内容，通常采用feed流形式来管理用户的发布内容。在现有技术中，业务平台大多采用关系型数据库作为存储系统来存储用户的发布内容，当用户访问时，服务端提供feed流对应的信息流聚合列表，其中，在对发布内容进行聚合时，出于访问性能考虑，大多采用缓存技术进行访问加速，而业务平台中的发布内容的数量非常多，全量使用缓存进行存储是不合适的，通常会使用FIFO、LRU、LFU等缓存淘汰策略对缓存中的数据进行淘汰。然而，使用缓存淘汰策略会使得有些发布内容未存储在缓存中，那么当用户访问这些发布内容时，则需要从关系型数据库中来获取，导致访问延时较长，影响用户体验，当访问压力突增时甚至会出现服务不可用的情况。

发明内容

鉴于上述问题，本申请提出了一种用户发布内容处理方法、装置、计算设备及存储介质，用于解决以下问题：现有的用户发布内容存储方式可用性较差。

根据本申请实施例的一个方面，提供了一种用户发布内容处理方法，包括：

将各个发布内容划分为冷数据和热数据，并利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容；

接收访问用户针对目标发布内容的内容访问请求，获取与内容访问请求对应的多个维度下的关联数据；

将多个维度下的关联数据与预设决策数据进行匹配，从冷数据存储系统和热数据存储系统中确定待访问系统；

从待访问系统中读取目标发布内容。

进一步地，将各个发布内容划分为冷数据和热数据进一步包括：

获取各个发布内容的热度指标数据以及每个发布内容对应的发布用户的热度指标数据；

针对每个发布内容，依据该发布内容的热度指标数据以及该发布内容对应的发布用户的热度指标数据进行运算，得到该发布内容的综合热度评分；

依据各个发布内容的综合热度评分，将各个发布内容划分为冷数据和热数据。

进一步地，在将多个维度下的关联数据与预设决策数据进行匹配之前，该方法还包括：

获取各个访问用户的用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据；

利用大数据计算引擎，对用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据进行分析，生成预设决策数据。

进一步地，获取与内容访问请求对应的多个维度下的关联数据进一步包括：

从内容访问请求中提取访问用户标识、目标发布内容标识以及发布用户标识；

获取与访问用户标识对应的用户行为数据作为访问用户维度下的关联数据；

获取与目标发布内容标识对应的热度指标数据作为发布内容维度下的关联数据；

获取与发布用户标识对应的热度指标数据作为发布用户维度下的关联数据。

进一步地，热数据存储系统包括：redis缓存和关系型数据库；

从待访问系统中读取目标发布内容进一步包括：

当待访问系统为热数据存储系统时，优先从redis缓存中读取目标发布内容，若redis缓存中未存储目标发布内容，则从关系型数据库中读取目标发布内容。

进一步地，冷数据存储系统包括：对象存储服务和Key-Value数据库；

从待访问系统中读取目标发布内容进一步包括：

当待访问系统为冷数据存储系统时，优先从Key-Value数据库中读取目标发布内容，若Key-Value数据库中未存储目标发布内容，则从对象存储服务中读取目标发布内容。

进一步地，冷数据存储系统包括：对象存储服务和Key-Value数据库；该方法还包括：

将在当前第一单位时段之前发布的各个发布内容按照第一单位时段进行分类并全量存储至对象存储服务中；

将在当前第一单位时段中发布的发布内容按照第二单位时段增量存储至Key-Value数据库中，当满足预设更新条件时，更新Key-Value数据库中的全量发布内容至对象存储服务中进行存储；其中，第一单位时段中包含有多个第二单位时段。

根据本申请实施例的另一方面，提供了一种用户发布内容处理装置，包括：

划分模块，适于将各个发布内容划分为冷数据和热数据；

存储模块，适于利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容；

获取模块，适于接收访问用户针对目标发布内容的内容访问请求，获取与内容访问请求对应的多个维度下的关联数据；

决策模块，适于将多个维度下的关联数据与预设决策数据进行匹配，从冷数据存储系统和热数据存储系统中确定待访问系统；

读取模块，适于从待访问系统中读取目标发布内容。

根据本申请实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述用户发布内容处理方法对应的操作。

根据本申请实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述用户发布内容处理方法对应的操作。

根据本申请实施例提供的用户发布内容处理方法、装置、计算设备及存储介质，将各个发布内容划分为冷数据和热数据，采用不同的存储系统对冷数据和热数据进行区分存储，实现了冷热数据分级保障的效果；在访问用户进行访问时，依据预设决策数据，从访问用户维度、发布内容维度以及发布用户维度这多个维度来决策当前访问热数据存储系统还是冷数据存储系统；该方案既能有效地保障属于热数据的发布内容的访问实时性，又能降低属于冷数据的发布内容的存储成本，提高了系统稳定性和可用性，优化了用户发布内容处理方式。

上述说明仅是本申请实施例技术方案的概述，为了能够更清楚了解本申请实施例的技术手段，而可依照说明书的内容予以实施，并且为了让本申请实施例的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请实施例的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请实施例的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本申请一个实施例的用户发布内容处理方法的流程示意图；

图2a示出了根据本申请另一个实施例的用户发布内容处理方法的流程示意图；

图2b示出了根据本申请另一个实施例的用户发布内容处理方法中的预设决策数据生成原理示意图；

图2c示出了根据本申请另一个实施例的用户发布内容处理方法的原理示意图；

图2d示出了根据本申请另一个实施例的用户发布内容处理方法中的冷数据存储系统的存储原理示意图；

图3示出了根据本申请一个实施例的用户发布内容处理装置的结构框图；

图4示出了根据本申请一个实施例的一种计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

feed流：是指持续更新并呈现给用户内容的信息流，是一种有时效性的信息聚合流；其中，feed是将用户订阅的若干消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容。

关系型数据库：是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。

FIFO(First in First out)：是一种基于先进先出的缓存淘汰策略，缓存对象可以以队列的形式存在，当缓存满了而且需要添加新的数据时，就释放队列头部的缓存对象。

LRU(Least Recently Used)：是一种基于最近使用的缓存淘汰策略，当缓存满了而且需要添加新的数据时，会淘汰最久没有使用的数据。

LFU(Least Frequently Used)：是一种基于最近最少使用的缓存淘汰策略，当缓存满了而且需要添加新的数据时，会淘汰掉使用频率最低的数据；如果存在相同使用频率的数据，则再根据使用时间间隔，将最久未使用的数据淘汰。

redis缓存：是一个开源的使用ANSIC语言编写、支持网络、可基于内存也可持久化的日志型、Key-Value数据库，并提供多种语言的API。

对象存储服务(Object Storage Service，OSS)：是一种云存储服务，以对象为基本存储单元，适用于海量数据的存储和访问，能够提供海量、安全、低成本、高可靠的非结构化云存储服务，常用的OSS包括AWS的S3服务等。

Key-Value数据库：一种以键值对存储数据的数据库，具有高性能、高可扩展性和高可用性等特点。

MapReduce：是一种编程模型，专门处理大规模数据的并行运算，该模型借鉴了函数式程序设计的思想，程序实现过程是通过map()函数和reduce()函数实现的。

图1示出了根据本申请一个实施例的用户发布内容处理方法的流程示意图，如图1所示，该方法包括如下步骤：

步骤S101，将各个发布内容划分为冷数据和热数据，并利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容。

其中，可充分结合各个发布内容的发布时间、访问频次以及各个发布内容对应的发布用户的关注人数、点赞数量等，综合评估各个发布内容的热度，将各个发布内容划分为冷数据和热数据。在本申请实施例中，针对冷数据和热数据设置了不同的存储系统和访问策略。对冷热数据进行区分存储，利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容。

具体地，热数据存储系统可采用实时性较好的内存缓存中间件redis缓存以及关系型数据库(例如MySQL)进行存储回源，能够有效地保障数据访问的实时性；冷数据存储系统可采用存储成本较低的对象存储服务和Key-Value数据库进行存储。

步骤S102，接收访问用户针对目标发布内容的内容访问请求，获取与内容访问请求对应的多个维度下的关联数据。

访问用户可通过客户端对业务平台中的发布内容进行访问，将访问用户所要访问的发布内容称为目标发布内容。在步骤S102中，接收访问用户针对目标发布内容的内容访问请求，其中，内容访问请求可包含有访问用户标识、目标发布内容标识、发布用户标识、请求时间等数据。在接收到访问用户的内容访问请求之后，获取与内容访问请求对应的多个维度下的关联数据，多个维度可包括访问用户维度、发布内容维度以及发布用户维度，从多个维度综合决策使用冷数据存储系统还是使用热数据存储系统为该访问用户提供访问服务。

具体地，访问用户维度下的关联数据可包括访问用户的用户行为数据，发布内容维度下的关联数据可包括用于反映发布内容热度情况的数据，发布用户维度下的关联数据可包括用于反映发布用户热度情况的数据。

步骤S103，将多个维度下的关联数据与预设决策数据进行匹配，从冷数据存储系统和热数据存储系统中确定待访问系统。

为了在实际访问场景中能够快速地决策出使用哪个存储系统作为访问用户的待访问系统，可预先对各个访问用户的访问行为、数据库访问情况、各个访问用户针对各个发布用户的内容发布页面的访问流量分布情况等通过大数据进行全面分析，生成预设决策数据，预设决策数据记录有切换至冷、热数据存储系统时对应的关联数据所需满足的条件。

在一种可选的实施方式中，若预设决策数据记录的是切换至热数据存储系统时对应的关联数据所需满足的条件，当步骤S102中所获取的多个维度下的关联数据与预设决策数据中的条件相匹配时，说明该访问用户需要通过热数据存储系统读取目标发布内容，那么将热数据存储系统确定为待访问系统；当均不相匹配时，说明该访问用户需要通过冷数据存储系统读取目标发布内容，那么将冷数据存储系统确定为待访问系统。

在另一种可选的实施方式中，若预设决策数据记录的是切换至冷数据存储系统时对应的关联数据所需满足的条件，当步骤S102中所获取的多个维度下的关联数据与预设决策数据中的条件相匹配时，说明该访问用户需要通过冷数据存储系统读取目标发布内容，那么将冷数据存储系统确定为待访问系统；当均不相匹配时，说明该访问用户需要通过热数据存储系统读取目标发布内容，那么将热数据存储系统确定为待访问系统。

步骤S104，从待访问系统中读取目标发布内容。

在决策得到待访问系统之后，则可通过待访问系统响应于该内容访问请求为访问用户提供访问服务，从待访问系统中读取目标发布内容，并返回至客户端供访问用户查看。

根据本申请实施例提供的用户发布内容处理方法，将各个发布内容划分为冷数据和热数据，采用不同的存储系统对冷数据和热数据进行区分存储，实现了冷热数据分级保障的效果；在访问用户进行访问时，依据预设决策数据，从访问用户维度、发布内容维度以及发布用户维度这多个维度来决策当前访问热数据存储系统还是冷数据存储系统；该方案既能有效地保障属于热数据的发布内容的访问实时性，又能降低属于冷数据的发布内容的存储成本，提高了系统稳定性和可用性，优化了用户发布内容处理方式。

图2a示出了根据本申请另一个实施例的用户发布内容处理方法的流程示意图，如图2a所示，该方法包括如下步骤：

步骤S201，获取各个发布内容的热度指标数据以及每个发布内容对应的发布用户的热度指标数据。

考虑到发布用户的热度会影响其发布内容的访问流量，以发布内容为视频为例，发布用户即为up主(uploader，作品上传作者)，与关注人数较少的发布用户相比，关注人数较多的头部发布用户所发布的视频具有较高的访问流量，本申请实施例在对各个发布内容进行冷热数据区分的过程中，不仅依据发布内容本身的热度情况，还充分结合了发布用户的热度情况来评估发布内容的综合热度。

在步骤S201中可从业务平台中获取各个发布内容的热度指标数据以及各个发布用户的热度指标数据。其中，发布内容的热度指标数据可以包括：发布内容的发布时间、修改时间、访问次数、访问频次、评论数量、点赞数量、收藏数量、分享数量、弹幕数量等数据。发布用户的热度指标数据可以包括：发布用户的关注人数、内容访问总数量、评论总数量、点赞总数量、收藏总数量、分享总数量、内容主题丰富度、内容质量综合评分、资源数据等数据。资源数据具体可包括发布用户的营收数据、发布用户接收到的访问用户提供的虚拟道具数据(例如直播间礼物)等。发布内容和发布用户的热度指标数据还可包括其他能够用于反映其热度的数据，此处不做限定。

步骤S202，针对每个发布内容，依据该发布内容的热度指标数据以及该发布内容对应的发布用户的热度指标数据进行运算，得到该发布内容的综合热度评分。

具体地，可为发布内容的各个热度指标数据以及发布用户的各个热度指标数据设置对应的权重，在权重设置过程中，可通过Lambda架构的大数据平台，计算业务平台中各个发布用户的发布内容的访问流量分布来设置热度指标数据对应的权重。然后通过对每个发布内容的各个热度指标数据以及该发布内容对应的发布用户的各个热度指标数据进行加权运算，从而得到该发布内容的综合热度评分。

步骤S203，依据各个发布内容的综合热度评分，将各个发布内容划分为冷数据和热数据。

具体地，可以以业务打标或者系统自动识别等方式，依据各个发布内容的综合热度评分，将各个发布内容划分为冷数据和热数据。例如，将每个发布内容的综合热度评分与预设划分阈值进行比对，若该发布内容的综合热度评分大于或等于预设划分阈值，则判定该发布内容属于热数据；若该发布内容的综合热度评分小于预设划分阈值，则判定该发布内容属于冷数据。其中，预设划分阈值可根据具体的业务需求进行设置，此处不做具体限定。

步骤S204，利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容。

热数据存储系统可采用实时性较好的存储方式，以保障数据访问的实时性，使访问用户获得较快的访问体验。而冷数据存储系统可采用存储成本较低的存储方式，以降低数据存储成本。

步骤S205，接收访问用户针对目标发布内容的内容访问请求，获取与内容访问请求对应的多个维度下的关联数据。

当访问用户想要访问业务平台中的某个目标发布内容时，可通过客户端发送针对目标发布内容的内容访问请求。由于本申请实施例采用了冷数据存储系统和热数据存储系统这两个存储系统来存储发布内容，那么在接收到内容访问请求之后，为了决策出哪个系统为待访问系统，还需获取与内容访问请求对应的多个维度下的关联数据。

其中，多个维度包括：访问用户维度、发布内容维度以及发布用户维度。多个维度下的关联数据的获取过程可为：从内容访问请求中提取访问用户标识、目标发布内容标识以及发布用户标识；获取与访问用户标识对应的用户行为数据作为访问用户维度下的关联数据；获取与目标发布内容标识对应的热度指标数据作为发布内容维度下的关联数据；获取与发布用户标识对应的热度指标数据作为发布用户维度下的关联数据。

其中，与访问用户标识对应的用户行为数据即为访问用户的用户行为数据，访问用户的用户行为数据可包括访问用户对业务平台中的发布内容的访问行为数据、评论行为数据、点赞行为数据、收藏行为数据、分享行为数据、弹幕行为数据等行为数据。访问用户的用户行为数据能够用于反映访问用户在业务平台中的活跃度。

步骤S206，将多个维度下的关联数据与预设决策数据进行匹配，从冷数据存储系统和热数据存储系统中确定待访问系统。

为了在实际访问场景中能够快速地决策出使用哪个存储系统作为访问用户的待访问系统，预先生成了预设决策数据。具体地，获取各个访问用户的用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据；利用大数据计算引擎，对用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据进行分析，通过均衡访问时效性、数据存储成本、系统稳定性、系统可用性等各方面，从而生成预设决策数据。其中，用户行为数据可包括kafka用户行为日志数据等。

图2b示出了根据本申请另一个实施例的用户发布内容处理方法中的预设决策数据生成原理示意图，如图2b所示，将用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据输入至大数据平台，通过MapReduce技术，利用Spark、Presto等大数据计算引擎，对上述各数据进行分析，得到在冷热数据存储系统之间切换的条件，进而依据条件生成预设决策数据。其中，预设决策数据记录有切换至冷、热数据存储系统时对应的关联数据所需满足的条件。

在一种可选的实施方式中，考虑到在发布用户的内容发布页面中，其所发布的多个发布内容以列表形式按照发布时间从近到远的顺序进行排列，访问用户可在内容发布页面滑动内容列表来查看发布用户历史发布的所有发布内容。发布内容在内容列表中的内容排列顺序越靠后，说明该发布内容的发布时间越久远，那么可在发布内容的访问次数的基础上结合访问用户的访问行为数据来生成预设决策数据中的若干条件。例如，预设决策数据中的某一条件为：访问用户访问的是在发布用户的内容发布页面的内容列表中排列顺序位于第N个(例如第20个)之后的发布内容且该发布内容的访问次数小于第一预设值(例如1000次)，该条件对应的待访问系统为冷数据存储系统。

在另一种可选的实施方式中，可在发布内容的发布时间的基础上结合发布用户的关注人数来生成预设决策数据中的若干条件。例如，预设决策数据中的另一条件为：访问用户访问的发布内容的发布时间与当前时间之间的时间间隔大于预设间隔(例如1年)且该发布内容对应的发布用户的关注人数大于第二预设值(例如10万人)，该条件对应的待访问系统为冷数据存储系统。

在又一种可选的实施方式中，可在发布内容的访问频次的基础上结合访问用户的活跃度评分来生成预设决策数据中的若干条件，其中，访问用户的活跃度评分可根据访问用户的用户行为数据计算得到。例如，预设决策数据中的另一条件为：访问用户访问的发布内容的访问频次位于预设频次范围内且该访问用户的活跃度评分大于第三预设值(例如80分)，该条件对应的待访问系统为热数据存储系统。

假设预设决策数据记录的是切换至热数据存储系统时对应的关联数据所需满足的条件，若步骤S205所获取的多个维度下的关联数据与预设决策数据中的某一条件相匹配，则将热数据存储系统确定为待访问系统；若均不相匹配，则将冷数据存储系统确定为待访问系统。

步骤S207，从待访问系统中读取目标发布内容。

图2c示出了根据本申请另一个实施例的用户发布内容处理方法的原理示意图，如图2c所示，在本实施例中，热数据存储系统包括redis缓存和关系型数据库，冷数据存储系统包括对象存储服务和Key-Value数据库。访问用户请求访问目标发布内容，发送内容访问请求；通过决策系统，依据预设决策数据对与内容访问请求对应的多个维度下的关联数据进行决策，确定待访问系统是冷数据存储系统还是热数据存储系统。其中，预设决策数据可存储在冷数据存储系统中的Key-Value数据库中，供访问用户访问时决策系统实时查询使用。

当待访问系统为热数据存储系统时，优先从redis缓存中读取目标发布内容，若redis缓存中未存储目标发布内容，则从关系型数据库中读取目标发布内容。当待访问系统为冷数据存储系统时，优先从Key-Value数据库中读取目标发布内容，若Key-Value数据库中未存储目标发布内容，则从对象存储服务中读取目标发布内容。

可选地，还可利用冷数据存储系统为热数据存储系统提供灾备冗余，进一步提高系统稳定性和可用性。当热数据存储系统发生故障时，冷数据存储系统可作为全量数据备份提供灾备下的临时访问存储，为用户提供服务，有效提升了系统可用性。

具体地，将在当前第一单位时段之前发布的各个发布内容按照第一单位时段进行分类并全量存储至对象存储服务中；将在当前第一单位时段中发布的发布内容按照第二单位时段增量存储至Key-Value数据库中，当满足预设更新条件时，更新Key-Value数据库中的全量发布内容至对象存储服务中进行存储；其中，第一单位时段中包含有多个第二单位时段。本领域技术人员可根据实际需要设置第一单位时段和第二单位时段的时间长度。例如，第一单位时段可为1天，第二单位时段可为1小时；又如，第一单位时段可为1小时，第二单位时段可为20分钟。本领域技术人员可根据实际需要设置预设更新条件，例如，可将预设更新条件设置为每天0点更新。

图2d示出了根据本申请另一个实施例的用户发布内容处理方法中的冷数据存储系统的存储原理示意图，如图2d所示，用户发布发布内容，若第一单位时段为1天，第二单位时段为1小时，那么可通过大数据平台每天重新计算最新发布的所有发布内容，按照天进行分区，按照小时进行更新，每天计算前一天的历史总量与各个小时的增量进行合并，得到最终的全量发布的冷数据，然后sink写入至对象存储服务和Key-Value数据库，形成1+1形式的数据备份。

根据本申请实施例提供的用户发布内容处理方法，将发布内容本身的热度情况与发布用户的热度情况相结合，实现了对发布内容的综合热度的评估，依据发布内容的综合热度评分，便捷、高效等实现了对发布内容进行冷热数据的有效划分；采用实时性较好的热数据存储系统存储属于热数据的发布内容，有效地保障了数据访问的实时性，使访问用户获得较快的访问体验，采用存储成本较低的冷数据存储系统存储属于冷数据的发布内容，降低了数据存储成本，实现了冷热数据分级保障的效果；利用大数据计算引擎，对用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据进行分析，通过均衡访问时效性、数据存储成本、系统稳定性、系统可用性等各方面，生成预设决策数据；在访问用户进行访问时，将访问用户维度、发布内容维度以及发布用户维度下的关联数据与预设决策数据进行匹配，实现了对待访问系统的快速决策，既能有效地保障属于热数据的发布内容的访问实时性，又能降低属于冷数据的发布内容的存储成本；另外，还利用冷数据存储系统为热数据存储系统提供灾备冗余，进一步提高了系统稳定性和可用性。

图3示出了根据本申请一个实施例的用户发布内容处理装置的结构框图，如图3所示，该装置包括：划分模块310、存储模块320、获取模块330、决策模块340以及读取模块350。

划分模块310适于：将各个发布内容划分为冷数据和热数据。

存储模块320适于：利用冷数据存储系统存储属于冷数据的发布内容，利用热数据存储系统存储属于热数据的发布内容。

获取模块330适于：接收访问用户针对目标发布内容的内容访问请求，获取与内容访问请求对应的多个维度下的关联数据。

决策模块340适于：将多个维度下的关联数据与预设决策数据进行匹配，从冷数据存储系统和热数据存储系统中确定待访问系统。

读取模块350适于：从待访问系统中读取目标发布内容。

可选地，划分模块310进一步适于：获取各个发布内容的热度指标数据以及每个发布内容对应的发布用户的热度指标数据；针对每个发布内容，依据该发布内容的热度指标数据以及该发布内容对应的发布用户的热度指标数据进行运算，得到该发布内容的综合热度评分；依据各个发布内容的综合热度评分，将各个发布内容划分为冷数据和热数据。

可选地，决策模块340进一步适于：获取各个访问用户的用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据；利用大数据计算引擎，对用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据进行分析，生成预设决策数据。

可选地，获取模块330进一步适于：从内容访问请求中提取访问用户标识、目标发布内容标识以及发布用户标识；获取与访问用户标识对应的用户行为数据作为访问用户维度下的关联数据；获取与目标发布内容标识对应的热度指标数据作为发布内容维度下的关联数据；获取与发布用户标识对应的热度指标数据作为发布用户维度下的关联数据。

可选地，热数据存储系统包括：redis缓存和关系型数据库。读取模块350进一步适于：当待访问系统为热数据存储系统时，优先从redis缓存中读取目标发布内容，若redis缓存中未存储目标发布内容，则从关系型数据库中读取目标发布内容。

可选地，冷数据存储系统包括：对象存储服务和Key-Value数据库。读取模块350进一步适于：当待访问系统为冷数据存储系统时，优先从Key-Value数据库中读取目标发布内容，若Key-Value数据库中未存储目标发布内容，则从对象存储服务中读取目标发布内容。

可选地，存储模块320进一步适于：将在当前第一单位时段之前发布的各个发布内容按照第一单位时段进行分类并全量存储至对象存储服务中；将在当前第一单位时段中发布的发布内容按照第二单位时段增量存储至Key-Value数据库中，当满足预设更新条件时，更新Key-Value数据库中的全量发布内容至对象存储服务中进行存储；其中，第一单位时段中包含有多个第二单位时段。

以上各模块的描述参照方法实施例中对应的描述，在此不再赘述。

根据本申请实施例提供的用户发布内容处理装置，将发布内容本身的热度情况与发布用户的热度情况相结合，实现了对发布内容的综合热度的评估，依据发布内容的综合热度评分，便捷、高效等实现了对发布内容进行冷热数据的有效划分；采用实时性较好的热数据存储系统存储属于热数据的发布内容，有效地保障了数据访问的实时性，使访问用户获得较快的访问体验，采用存储成本较低的冷数据存储系统存储属于冷数据的发布内容，降低了数据存储成本，实现了冷热数据分级保障的效果；利用大数据计算引擎，对用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据进行分析，通过均衡访问时效性、数据存储成本、系统稳定性、系统可用性等各方面，生成预设决策数据；在访问用户进行访问时，将访问用户维度、发布内容维度以及发布用户维度下的关联数据与预设决策数据进行匹配，实现了对待访问系统的快速决策，既能有效地保障属于热数据的发布内容的访问实时性，又能降低属于冷数据的发布内容的存储成本；另外，还利用冷数据存储系统为热数据存储系统提供灾备冗余，进一步提高了系统稳定性和可用性。

本申请实施例还提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，可执行指令可执行上述任意方法实施例中的用户发布内容处理方法。

图4示出了根据本申请一个实施例的一种计算设备的结构示意图，本申请实施例的具体实施例并不对计算设备的具体实现做限定。

如图4所示，该计算设备可以包括：处理器(processor)402、通信接口(Communications Interface)404、存储器(memory)406、以及通信总线408。

其中：

处理器402、通信接口404、以及存储器406通过通信总线408完成相互间的通信。

通信接口404，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器402，用于执行程序410，具体可以执行上述用户发布内容处理实施例中的相关步骤。

具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。

处理器402可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器406，用于存放程序410。存储器406可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序410具体可以用于使得处理器402执行上述任意方法实施例中的用户发布内容处理方法。程序410中各步骤的具体实现可以参见上述用户发布内容处理实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请实施例的内容，并且上面对特定语言所做的描述是为了披露本申请实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请实施例的示例性实施例的描述中，本申请实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请实施例的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例中的一些或者全部部件的一些或者全部功能。本申请实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请实施例进行说明而不是对本申请实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种用户发布内容处理方法，包括：

将各个发布内容划分为冷数据和热数据，并利用冷数据存储系统存储属于所述冷数据的发布内容，利用热数据存储系统存储属于所述热数据的发布内容；

接收访问用户针对目标发布内容的内容访问请求，获取与所述内容访问请求对应的多个维度下的关联数据；

将多个维度下的关联数据与预设决策数据进行匹配，从所述冷数据存储系统和所述热数据存储系统中确定待访问系统；

从所述待访问系统中读取所述目标发布内容。

2.根据权利要求1所述的方法，所述将各个发布内容划分为冷数据和热数据进一步包括：

获取各个发布内容的热度指标数据以及每个发布内容对应的发布用户的热度指标数据；

针对每个发布内容，依据该发布内容的热度指标数据以及该发布内容对应的发布用户的热度指标数据进行运算，得到该发布内容的综合热度评分；

依据各个发布内容的综合热度评分，将各个发布内容划分为冷数据和热数据。

3.根据权利要求1所述的方法，在所述将多个维度下的关联数据与预设决策数据进行匹配之前，所述方法还包括：

获取各个访问用户的用户行为数据、数据库访问情况数据以及内容发布页面的流量分布数据；

利用大数据计算引擎，对所述用户行为数据、所述数据库访问情况数据以及所述内容发布页面的流量分布数据进行分析，生成预设决策数据。

4.根据权利要求1-3任一项所述的方法，所述获取与所述内容访问请求对应的多个维度下的关联数据进一步包括：

从所述内容访问请求中提取访问用户标识、目标发布内容标识以及发布用户标识；

获取与所述访问用户标识对应的用户行为数据作为访问用户维度下的关联数据；

获取与所述目标发布内容标识对应的热度指标数据作为发布内容维度下的关联数据；

获取与所述发布用户标识对应的热度指标数据作为发布用户维度下的关联数据。

5.根据权利要求1-4任一项所述的方法，所述热数据存储系统包括：redis缓存和关系型数据库；

所述从所述待访问系统中读取所述目标发布内容进一步包括：

当所述待访问系统为所述热数据存储系统时，优先从redis缓存中读取所述目标发布内容，若redis缓存中未存储所述目标发布内容，则从所述关系型数据库中读取所述目标发布内容。

6.根据权利要求1-4任一项所述的方法，所述冷数据存储系统包括：对象存储服务和Key-Value数据库；

所述从所述待访问系统中读取所述目标发布内容进一步包括：

当所述待访问系统为所述冷数据存储系统时，优先从Key-Value数据库中读取所述目标发布内容，若Key-Value数据库中未存储所述目标发布内容，则从所述对象存储服务中读取所述目标发布内容。

7.根据权利要求1-6任一项所述的方法，所述冷数据存储系统包括：对象存储服务和Key-Value数据库；所述方法还包括：

将在当前第一单位时段之前发布的各个发布内容按照第一单位时段进行分类并全量存储至所述对象存储服务中；

将在当前第一单位时段中发布的发布内容按照第二单位时段增量存储至Key-Value数据库中，当满足预设更新条件时，更新Key-Value数据库中的全量发布内容至所述对象存储服务中进行存储；其中，第一单位时段中包含有多个第二单位时段。

8.一种用户发布内容处理装置，包括：

划分模块，适于将各个发布内容划分为冷数据和热数据；

存储模块，适于利用冷数据存储系统存储属于所述冷数据的发布内容，利用热数据存储系统存储属于所述热数据的发布内容；

获取模块，适于接收访问用户针对目标发布内容的内容访问请求，获取与所述内容访问请求对应的多个维度下的关联数据；

决策模块，适于将多个维度下的关联数据与预设决策数据进行匹配，从所述冷数据存储系统和所述热数据存储系统中确定待访问系统；

读取模块，适于从所述待访问系统中读取所述目标发布内容。

9.一种计算设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的用户发布内容处理方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的用户发布内容处理方法对应的操作。