点赞数据处理方法及系统

技术领域

本申请涉及数据处理技术领域，尤其涉及一种点赞数据处理方法、系统、电子装置及计算机可读存储介质。

背景技术

点赞，网络用语中指“赞同”、“喜爱”，该网络语来源于网络社区的“赞”功能。在视频网站中，点赞数可以反映出UP主(内容提供者)所上传的视频内容受到观众喜爱的程度。而点踩则与点赞正好相反，表达出相应内容不受喜欢或不被暂同。一般在视频网站中，需要提供针对视频、动态、专栏、评论、弹幕等多种实体维度的点赞、点踩以及其余配套的数据查询功能。并且，点赞/点踩作为一个与社区实体共存的服务，还需要提供业务快速接入的能力及较高的数据存储能力。另外，作为被用户强感知的功能，需要考虑到各种情况下的系统容灾。

发明内容

本申请的主要目的在于提出一种点赞数据处理方法、系统、电子装置及计算机可读存储介质，旨在解决至少一种上述技术问题。

为实现上述目的，本申请实施例提供了一种点赞数据处理方法，所述方法包括：

响应于点赞操作，发送所述点赞操作对应的点赞消息；

根据所述点赞消息异步更新数据库和缓存中的点赞数据；

接收点赞数据展示请求，从所述缓存中获取对应的点赞数据；

其中，所述缓存和所述数据库均至少使用两个数据存储设备互相进行数据备份。

可选地，所述方法还包括：

在所述缓存中不存在所述点赞数据展示请求对应的点赞数据的情形下，从所述数据库中获取所述点赞数据，并将所述点赞数据更新至所述缓存。

可选地，所述响应于点赞操作，发送所述点赞操作对应的点赞消息包括：

接收客户端的点赞操作请求；

从所述数据库中查询所述点赞操作请求对应的点赞状态；

在所述点赞状态正常的情形下，发送所述点赞操作对应的点赞消息，以进行异步处理。

可选地，所述数据库为关系型数据库，保存点赞记录表和点赞计数表，所述点赞记录表在用户移动互联网设备和被点赞的实体标识两个维度上建立联合索引，所述点赞计数表以业务标识和实体标识为主键，按照实体标识维度建立索引。

可选地，所述缓存为键值型，保存点赞数和用户点赞列表，所述点赞数以业务标识和实体标识作为键，并将点赞数与点踩数拼接起来作为值，所述用户点赞列表以用户移动互联网设备与业务标识作为键，值是一个有序数据集合，其中每个数据为被点赞的实体标识，以点赞时间排序。

可选地，所述方法还包括：

利用最小堆算法，在预先配置的时间窗口范围内，统计出所述缓存中访问最频繁的键，将所述键和对应的值保存在本地缓存中，以应对缓存热点问题。

可选地，所述数据库至少使用两个数据存储设备互相进行数据备份包括：

使用位于不同机房的两个数据存储设备作为所述数据库进行数据备份；

在正常情况下，第一机房的数据库承载所有写流量与部分读流量，第二机房的数据库承载部分读流量；

当其中一个机房的数据库发生故障时，通过数据库代理的切换将所有读写流量切换至另一机房继续提供服务。

可选地，所述缓存至少使用两个数据存储设备互相进行数据备份包括：

设置两套出于不同机房的Redis集群作为所述缓存，并且通过异步任务消费所述数据库的BinLog日志维护两地缓存的一致性。

此外，为实现上述目的，本申请实施例还提供一种点赞数据处理系统，所述系统包括：

收发模块，用于响应于点赞操作，发送所述点赞操作对应的点赞消息；

更新模块，用于根据所述点赞消息异步更新数据库和缓存中的点赞数据；

获取模块，用于接收点赞数据展示请求，从所述缓存中获取对应的点赞数据；

其中，所述缓存和所述数据库均至少使用两个数据存储设备互相进行数据备份。

为实现上述目的，本申请实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的点赞数据处理程序，所述点赞数据处理程序被所述处理器执行时实现如上述的点赞数据处理方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有点赞数据处理程序，所述点赞数据处理程序被处理器执行时实现如上述的点赞数据处理方法。

本申请实施例提出的点赞数据处理方法、系统、电子装置及计算机可读存储介质，能够通过数据库、缓存等多级数据存储结构来保存点赞(点踩)相关数据，当接收到客户端用户的点赞操作后，先更新数据库，再刷新缓存，而当需要展示点赞数据时，先调用缓存获取所述点赞数据，缓存中没有相应数据再回源数据库，从而实现点赞数据的快速更新与查询。并且，通过异步任务来刷新缓存、为下游其他服务提供点赞的异步消息，可以多线程并发执行，提高处理效率。另外，所述数据库和所述缓存均使用两地机房互为灾备，在遇到故障时切换机房以保证继续提供服务，提高了容灾能力，使客户端用户对故障无感知，提升了用户使用体验。

附图说明

图1为实现本申请各个实施例的一种应用环境架构图；

图2为本申请中服务端的点赞服务应用架构示意图；

图3为本申请中异步任务层的异步任务示意图；

图4为本申请第一实施例提出的一种点赞数据处理方法的流程图；

图5为图4中步骤S200的细化流程示意图；

图6为本申请中更新数据库和缓存的流程示意图；

图7为本申请中获取点赞计数的流程示意图；

图8为本申请中获取点赞状态的流程示意图；

图9为本申请中获取用户被点赞计数的流程示意图；

图10为本申请中单元化多活容灾方式的示意图；

图11为本申请第二实施例提出的一种电子装置的硬件架构示意图；

图12为本申请第三实施例提出的一种点赞数据处理系统的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

下面以点赞操作为主介绍本申请各个实施例，可以理解的是，点踩操作与点赞操作类似，可以采用与点赞数据处理方案类似的方案处理点踩数据，在此不再赘述。

请参阅图1，图1为实现本申请各个实施例的一种应用环境架构图。本申请可应用于包括，但不仅限于客户端2、服务端4、数据库6的应用环境中。

其中，所述客户端2用于向用户显示当前应用的界面，例如视频网站界面，并接收用户的点赞/点踩、进入视频播放页面、进入个人空间页等操作，及根据上述操作向服务端4发送请求。所述客户端2可以为PC(Personal Computer，个人电脑)、手机、平板电脑、便携计算机、可穿戴设备等终端设备。

所述服务端4用于为所述客户端2提供点赞服务的数据和技术支持，例如在客户端2接收到点赞操作后，查询点赞状态；在所述点赞状态正常的情形下，异步处理所述点赞操作对应的点赞消息，更新所述数据库6和所述缓存；当接收到客户端2发送的点赞数据展示请求时，从所述缓存中调用对应的点赞数据；在所述缓存中不存在所述点赞数据的情形下，回源所述数据库6获取所述点赞数据，并更新所述缓存。所述服务端4可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。

所述数据库6用于存储点赞数据，包括点赞记录表、点赞计数表等。在本申请实施例中，所述数据库6为关系型数据库，例如可以采用TiDB数据库。TiDB是一种分布式关系型数据库，同时支持在线事务处理与在线分析处理(Hybrid Transactional and AnalyticalProcessing，HTAP)，适合高可用、强一致要求较高、数据规模较大等各种应用场景。

所述服务端4和一个或多个所述客户端2、所述数据库6之间通过无线或有线网络通信连接，以进行数据传输和交互。所述网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，GSM)、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等。

在本申请的各个实施例中，所述服务端4的点赞服务至少要满足以下业务能力、平台能力、容灾能力等各个方面的能力，以满足客户端2的用户需求。

在业务能力方面，以视频稿件为例，点赞服务需要提供的具体服务内容包括：对某个稿件点赞或取消点赞、点踩或取消点踩；查询是否对某一个或一批稿件点过赞或点过踩；查询某个实体(稿件、动态等)的点赞数；查询某个用户的点赞列表；查询某个实体的点赞人列表；查询用户收到的总点赞数等。

在平台能力方面，点赞服务作为一个与社区实体共存的服务，需要从配置级别提供业务快速接入的能力，以及在数据存储上(缓存、数据库)具备数据隔离存储的能力，以适应多租户需求。

在容灾能力方面，点赞服务作为被用户强感知的功能，需要考虑到各种情况下的系统容灾，例如存储不可用、消息队列不可用、机房故障、网络故障等。

另外，点赞服务还需要承载热门事件、稿件等带来的热点问题所产生的流量压力，所述热点问题包括数据库热点、缓存热点等。

参阅图2所示，为所述服务端4的点赞服务应用架构示意图。在本申请实施例中，整个点赞服务的应用架构可以分为四个部分，包括流量入口控制层、业务网关层、点赞服务层、点赞异步任务层。所述流量入口控制层用于确定流量应该去往哪个机房。所述业务网关层用于统一鉴权、反黑灰产等统一流量筛选。所述点赞服务层(Thumbup-Service)用于提供统一的远程过程调用(Remote Procedure Call，RPC)接口。所述点赞异步任务层(Thumbup-Job)用于处理异步任务。

另外还需要数据存储单元的支持，本申请中主要包括三级数据存储，分别为数据库(Database，DB)层、缓存(Cache)层和本地缓存(LocalCache)。

其中，所述数据库层可以是所述TiDB数据库。点赞服务中最为重要的数据是点赞记录表和点赞计数表，保存在所述数据库层中。所述点赞记录表用于记录每一次的点赞记录，包括用户移动互联网设备(Mobile Internet Device，MID)、被点赞的实体标识(MessageID，实体ID)、点赞来源、时间等信息，并且在MID、实体ID两个维度上建立了满足业务查询需求的联合索引。所述点赞计数表以业务标识(BusinessID，业务ID)和实体ID为主键，聚合了该实体的点赞数、点踩数等信息，并且按照实体ID维度建立满足业务查询需求的索引。由于采用TiDB数据库，所以对业务上无需考虑分库分表的操作。

所述缓存层采用远程字典服务(Remote Dictionary Server，Redis)缓存，Redis缓存是一个支持网络、可基于内存亦可持久化的日志型、键值(Key-Value，KV)数据库。点赞作为一个高流量的服务，缓存的设立肯定是必不可少的。以点赞数和用户点赞列表为例，所述点赞数用业务ID和该业务下的实体ID作为缓存的键(Key)，并将点赞数与点踩数拼接起来作为缓存的值(Value)进行存储以及更新。所述用户点赞列表用MID与业务ID作为Key，Value则是一个Zset。所述Zset即Sorted Set(有序集合)，是个有序且不可重复的数据集合，其中每个数据member都对应一个score值，Zset内部由score进行排序。具体地，所述member为被点赞的实体ID，score为点赞的时间。当该业务下某用户有新的点赞操作时，被点赞的实体则会通过Redis的Zadd命令的方式将最新的点赞记录加入到所述Zset中。所述Zadd命令用于将一个或多个成员元素及其分数值加入到有序集合当中。

为了维持用户点赞列表的长度，使其不至于无限扩张，需要在每一次加入新的点赞记录的时候，按照固定长度裁剪用户的点赞记录缓存。该设计也就代表用户的点赞记录在缓存中是有限制长度的，超过该长度的数据请求需要回源数据库查询。

本地缓存的建立，目的是为了应对缓存热点问题。利用最小堆算法，在可配置的时间窗口范围内，统计出访问最频繁的缓存Key，也就是热Key，并将热Key及其Value按照业务可接受的TTL(Time To Live，生存时间)存储在本地内存中，即为所述本地缓存。

所述点赞服务层作为面对用户端2流量的直接接口，在提供服务的同时，还需要在面对各种未知或者可预知的灾难时，尽可能保障继续提供服务。为了提高容灾能力，在本申请实施例中，在所述数据库6(数据库层，所述TiDB数据库)的设计上，点赞服务使用两地机房互为灾备，正常情况下，第一机房承载所有写流量与部分读流量，第二机房承载部分读流量。当一个机房的数据库发生故障时，通过数据库代理(Proxy)的切换可以将读写流量切换至备份机房继续提供服务。

在缓存上，点赞服务也拥有两套出于不同机房的Redis集群，并且通过异步任务消费所述TiDB数据库的BinLog维护两地缓存的一致性，可以在需要时切换机房来保证服务的提供。所述Binlog是记录所有数据库表结构变更以及表数据修改的二进制日志。

另外，所述点赞服务层在遇到各种灾难后，可以自动进行接口的降级。下面以点赞数降级、点赞状态降级、点赞列表降级为例进行说明。所述点赞数降级是指当在缓存查询点赞数或数据库查询点赞数失败后，会默认以0返回。所述点赞状态降级是指当查询是否点过赞失败后，默认以未点赞作为结果返回。所述点赞列表降级是指当查询点赞列表失败后，默认以空列表作为结果返回。

所述异步任务层所要处理的异步任务主要用于刷新缓存、为下游其他服务提供点赞的异步消息等功能。如图3所示，为所述异步任务层的异步任务示意图。其中，刷新缓存包括点赞状态缓存、点赞列表缓存、点赞计数缓存等。为下游提供点赞的异步消息包括点赞事件异步消息、点赞计数异步消息等。

另外，由于点赞数据的存储为TiDB数据库，且数据量较大。在实际应用场景中，Binlog会偶遇数据延迟甚至是断流的问题。为了减少Binlog数据延迟对服务数据的影响，所述点赞服务做了以下优化：首先在运维层面、代码层面都对Binlog的实时性、是否断流做了监控。其次，还可以脱离Binlog，由业务层发送重要的数据信息(点赞数变更、点赞状态事件)等。当发生数据延迟时，会自动同时消费由所述点赞服务层发送的容灾消息，继续向下游发送。

实施例一

如图4所示，为本申请第一实施例提出的一种点赞数据处理方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述服务端作为执行主体对该方法进行说明。

该方法包括以下步骤：

S200，响应于点赞操作，发送所述点赞操作对应的点赞消息。

在本实施例中，需要结合当前点赞状态和当前用户的点赞操作请求，分别做状态更新和计数更新。因此，在发送所述点赞消息之前，首先要回源查询点赞状态。

具体而言，进一步参阅图5，为上述步骤S200的细化流程示意图。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S200具体包括：

S2000，接收客户端的点赞操作请求。

本实施例的点赞适用于视频稿件、文章、评论等当前的点赞和计数逻辑。另外，除了所述点赞操作请求外，在其他实施例中，也可以是点踩操作请求、取消点赞操作请求、取消点踩操作请求，但点赞、点踩须互斥。

S2002，从数据库中查询所述点赞操作请求对应的点赞状态。

在本实施例中，所述数据库可以为TiDB数据库，用于保存点赞记录表和点赞计数表等数据。所述点赞记录表用于记录每一次的点赞记录，包括用户MID、被点赞的实体(稿件、动态等)ID、点赞来源、时间等信息，并且在MID、实体ID两个维度上建立了满足业务查询需求的联合索引。所述点赞计数表以业务ID和实体ID为主键，聚合了该实体的点赞数、点踩数等信息，并且按照实体ID维度建立满足业务查询需求的索引。由于采用TiDB数据库，所以对业务上无需考虑分库分表的操作。

所述点赞状态主要是指该用户对该视频是否已经点过赞。若已经点过赞，则所述点赞操作为重复点赞，表示点赞状态有问题。除此之外，还可能出现操作数据库的错误、用户MID为空等其他问题。

S2004，在所述点赞状态正常(没有问题)的情形下，发送所述点赞操作对应的点赞消息，以进行异步处理。

所述点赞消息具体包括点赞的用户、被点赞的实体ID、具体点赞时间、被点赞实体的业务类型、被点赞实体的点赞计数等。

另外，在所述点赞状态有问题的情形下，还可以进一步确定是否为重复点赞问题。若是，则发送重复点赞消息进行异步处理，并返回错误提示(Error)，否则直接返回Error。

由于重复点赞问题是被程序所预期的，因此在收到所述重复点赞消息后可以采用对齐的特殊处理逻辑进行异步处理。而其他的错误则是不被预期的，例如操作数据库的错误或者用户MID为空等，这些无法预期的错误数据会被直接拒绝处理，并返回Error。

回到图4，S202，根据所述点赞消息异步更新数据库和缓存中的点赞数据。

所述缓存采用Redis缓存，用于保存点赞数和用户点赞列表等数据。所述点赞数用业务ID和该业务下的实体ID作为缓存的Key，并将点赞数与点踩数拼接起来作为缓存的Value进行存储以及更新。所述用户点赞列表用MID与业务ID作为Key，Value则是一个Zset，其中每个数据member都对应一个score值，以进行排序。所述member为被点赞的实体ID，score为点赞的时间。为了维持用户点赞列表的长度，使其不至于无限扩张，需要在每一次加入新的点赞记录的时候，按照固定长度裁剪用户的点赞记录缓存。

并且，为了应对缓存热点问题，利用最小堆算法，在预先配置的时间窗口范围内，统计出所述缓存中访问最频繁的Key，也就是热Key，并将热Key及其Value按照业务可接受的TTL存储在本地内存中，即为本地缓存。

在本实施例中，所述更新包括状态更新和计数更新等。具体地，更新数据库包括更新用户点赞记录表、视频稿件被点赞计数表等；更新缓存包括更新用户点赞列表、视频稿件的点赞人列表、视频稿件被点赞计数等。

如图6所示，为所述更新的流程示意图。当接收到异步点赞消息后，首先回源查询点赞状态，具体过程与上一步骤类似，在此不再赘述。在所述点赞状态正常的情形下，根据所述点赞消息更新所述数据库和所述缓存。在所述点赞状态有问题的情形下，中断此次处理，继续处理下一条点赞消息。

S204，接收点赞数据展示请求，从所述缓存中获取对应的点赞数据。

当客户端用户进入视频播放页面、进入个人空间页等场景时，需要向用户展示该视频或该个人的点赞数据。此时客户端向服务端发送相应的点赞数据展示请求。服务端接收到所述点赞数据展示请求后，首先从所述缓存中调用对应的点赞数据。

在所述缓存中存在所述点赞数据的情形下，从所述缓存中获取到所述点赞数据后，返回至所述客户端进行展示。

S206，在所述缓存中不存在所述点赞数据的情形下，回源所述数据库获取所述点赞数据，并更新至所述缓存。

若所述缓存中不存在所述点赞数据展示请求对应的点赞数据，则需要回源至所述数据库中获取所述点赞数据，并在获取到所述点赞数据后，将所述点赞数据更新至所述缓存中。

下面分别以所述点赞数据展示请求对应的点赞数据为点赞计数、点赞状态、用户被点赞计数为例对上述步骤S204和S206进行说明。

如图7所示，为获取点赞计数的流程示意图。在本实施例中，需要获取点赞计数的应用场景包括客户端用户进入视频播放页面时查询视频稿件的点赞数量、浏览评论列表时查询每条评论的点赞数量等。首先，根据类型和ID从Redis缓存中获取点赞计数。所述类型是指被点赞实体的类型(例如被点赞的视频、评论或者动态等)。所述ID是指具体被点赞的实体ID，例如视频ID、评论ID、动态ID等。若缓存中有相应数据，则获取所述点赞计数后返回结果。若缓存中没有相应数据，则需要回源所述数据库获取所述点赞计数，并将所述点赞计数写入到所述缓存中。

如图8所示，为(批量)获取点赞状态的流程示意图。该流程的目的是查询一批实体(例如20个)的点赞数量。首先，根据类型和ID从Redis缓存中获取点赞状态。若缓存中有相应数据，则判断ID数量是否小于预设值(需要获取的量，例如20)，若是，则在所述Zset的score中获取点赞时间，否则获取全量点赞列表后在内存中做判断。若缓存中没有相应数据，则先判断缓存接口是否出错，若是，则回源所述数据库获取200条点赞列表，否则回源所述数据库获取全量点赞列表，并写入所述缓存。由于缓存的响应速度远高于数据库，因此先从所述缓存中获取这批数据的点赞数，但是假设只从所述缓存中获取到了其中10条数据(即ID数量小于预设值)，则剩下10条数据需要从所述数据库中获取(回源)，再将从所述数据库中获取的10条数据也写入缓存，以便于下次查询时直接从缓存获取。

如图9所示，为获取所述用户被点赞计数的流程示意图。首先确定所述缓存中是否存在所述用户被点赞计数，若是，则直接从所述缓存中获取，返回每个类型对应的被点赞数。否则，回源所述数据库获取所述用户被点赞计数，返回每个类型对应的被点赞总数，并异步回源该用户所有投稿稿件的被点赞列表。其中，所述异步回源是指开启一个新的线程用来获取该用户所有投稿稿件的点赞人列表，并存入所述缓存中，则下次用户查询时可以直接从所述缓存中获取数据。异步的原因是为了不阻塞当前的流程。

值得注意的是，为了提高容灾能力，所述数据库和所述缓存均至少使用两个数据存储设备互相进行数据备份。在本实施例中，所述数据库使用两地机房互为灾备，正常情况下，第一机房承载所有写流量与部分读流量，第二机房承载部分读流量。当一个机房的数据库发生故障时，通过数据库Proxy的切换可以将读写流量切换至备份机房继续提供服务。所述缓存也拥有两套出于不同机房的Redis集群，并且通过异步任务消费所述TiDB数据库的BinLog维护两地缓存的一致性，可以在需要时切换机房来保证服务的提供。

具体而言，本实施例所采用的容灾方式为单元化多活方式，即在不同城市、不同机房独立部署业务单元，容灾能力更强，且遇到灾难时需要切换的范围更小。如图10所示，为所述单元化多活容灾方式的示意图。所述单元化多活容灾方式主要包括用户分流、流量管控、数据同步、单元配套消息流等功能。所述用户分流是指根据用户信息(例如MID等)将用户划分到某个固定单元，即该用户的点赞服务在该单元中执行。所述流量管控包括内容分发网络(Content Delivery Network，CDN)侧流量、服务网关流量、存储层(数据存储模块，例如TiDB、Redis、KV数据库等)流量等。所述数据同步主要是指TiDB数据库的数据同步。所述单元配套消息流是指每个单元独立传递点赞事件消息、点赞数消息等。

另外，本实施例还可以在遇到问题时自动进行接口的降级，例如点赞数降级、点赞状态降级、点赞列表降级等。所述点赞数降级是指当在缓存查询点赞数或数据库查询点赞数失败后，会默认以0返回。所述点赞状态降级是指当查询是否点过赞失败后，默认以未点赞作为结果返回。所述点赞列表降级是指当查询点赞列表失败后，默认以空列表作为结果返回。

本实施例提出的点赞数据处理方法，可以通过数据库、缓存、本地缓存三级数据存储结构来保存点赞(点踩)相关数据，当接收到客户端用户的点赞操作后，先更新数据库，再刷新缓存，而当需要展示点赞数据时，先调用缓存获取所述点赞数据，缓存中没有相应数据再回源数据库，从而实现点赞数据的快速更新与查询。并且，针对缓存热点问题，可以将热Key及对应的Value保存在本地缓存中，节省数据访问时间。本方法通过异步任务来刷新缓存、为下游其他服务提供点赞的异步消息，可以多线程并发执行，提高处理效率。另外，所述数据库和所述缓存均使用两地机房互为灾备，在遇到故障时切换机房以保证继续提供服务，提高了容灾能力，使客户端用户对故障无感知，提升了用户使用体验。

实施例二

如图11所示，为本申请第二实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图11仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是服务器。

所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如点赞数据处理系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述点赞数据处理系统60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。

实施例三

如图12所示，为本申请第三实施例提出一种点赞数据处理系统60的模块示意图。所述点赞数据处理系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述点赞数据处理系统60包括：

收发模块600，用于响应于点赞操作，发送所述点赞操作对应的点赞消息。

在本实施例中，需要结合当前点赞状态和当前用户的点赞操作请求，分别做状态更新和计数更新。因此，在发送所述点赞消息之前，首先要回源查询点赞状态。

具体而言，首先接收客户端的用户点赞操作请求，然后从数据库中查询点赞状态。所述点赞状态主要是指该用户对该视频是否已经点过赞。若已经点过赞，则所述点赞操作为重复点赞，表示点赞状态有问题。除此之外，还可能出现操作数据库的错误、用户MID为空等其他问题。在所述点赞状态正常的情形下，发送所述点赞操作对应的点赞消息，以进行异步处理。另外，在所述点赞状态有问题的情形下，还可以进一步确定是否为重复点赞问题。若是，则发送重复点赞消息进行异步处理，并返回Error，否则直接返回Error。

更新模块602，用于根据所述点赞消息异步更新数据库和缓存中的点赞数据。

在本实施例中，所述更新包括状态更新和计数更新等。具体地，更新数据库包括更新用户点赞记录表、视频稿件被点赞计数表等；更新缓存包括更新用户点赞列表、视频稿件的点赞人列表、视频稿件被点赞计数等。

获取模块604，用于接收点赞数据展示请求，从所述缓存中获取对应的点赞数据。

当客户端用户进入视频播放页面、进入个人空间页等场景时，需要向用户展示该视频或该个人的点赞数据。此时客户端向服务端发送相应的点赞数据展示请求。获取模块604接收到所述点赞数据展示请求后，首先从所述缓存中调用对应的点赞数据。

在所述缓存中存在所述点赞数据的情形下，从所述缓存中获取到所述点赞数据后，返回至所述客户端进行展示。

所述获取模块604，还用于在所述缓存中不存在所述点赞数据的情形下，回源所述数据库获取所述点赞数据，并更新至所述缓存。

若所述缓存中不存在所述点赞数据展示请求对应的点赞数据，则需要回源至所述数据库中获取所述点赞数据，并在获取到所述点赞数据后，将所述点赞数据更新至所述缓存中。

实施例四

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有点赞数据处理程序，所述点赞数据处理程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的点赞数据处理方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。