CN112799644A - 一种排行榜系统及生成排行榜的方法 - Google Patents

Abstract

本发明提出一种生成排行榜的方法，该方法包括配置第一数据源，从第一数据源获取第一数据，第一数据包括与排行榜对象及排行榜事件相关的初始数据，排行榜事件与排行榜对象相关联，根据第一数据，生成排行榜配置，进而根据排行榜配置生成排行榜。本发明还提出一种排行榜系统,该系统具有可扩展性，以配置化的方式灵活地实现不同种类的排行榜需求，从而减少因不同种类排行榜开发需要的人力和物力，进而降低开发成本,同时缩短开发周期并提高生成排行榜效率。

Description

一种排行榜系统及生成排行榜的方法

技术领域

本发明涉及计算机及通信技术领域，特别涉及一种排行榜系统及生成排行榜的方法。

背景技术

移动互联网流行的今天，各个APP推出层出不穷的排行榜产品，例如手机销售排行榜、用户送礼排行榜服务、帖子阅读数排行榜、用户粉丝数量排行榜等等，成为了各个APP活动运营的主要载体之一。排行榜相关的需求占了活动运营需求的很大比例，每年有成百个排行榜需求被开发上线。大部分排行榜的生命周期比较短，往往是随着运营活动的周期开发上线。

目前业界排行榜类需求的主要实现方式是针对特定领域排行榜需求，开发相应的排行榜系统，以实现特定的排行榜服务。比如手机销售排行榜、用户送礼排行榜服务、帖子阅读数排行榜、用户粉丝数量排行榜等等。同时，开发排行榜类系统的流程基本上为：产品或运营提出需求-->开发人员设计-->编码实现需求-->相关服务器申请、上线-->排行榜生成-->活动周期结束-->排行榜下线。这些不同业务的排行榜系统只解决特定业务领域的需求，无法适用于其他业务。每个排行榜类需求的开发上线流程，消耗大量的人力，整个开发流程效率较低。并且在运营规则发生变化时，相应的排行榜服务需要由开发人员进行代码修改并重新发布，无法通过便捷的配置而适应新的运营规则。因此现有的排行榜技术缺乏扩展性和灵活性，并且开发成本高。

发明内容

本发明的目的在于，提供一种排行榜系统及生成排行榜的方法，能够支持以配置化的方式，而不是代码开发上线的方式，实现不同类型排行榜的需求。通过本发明实现的可扩展的系统，一个排行榜需求的开发流程可变为：产品或运营提出需求-->开发人员在排行榜系统上配置排行榜并生效-->排行榜生成-->活动周期结束-->排行榜自动关闭。在这个流程中，消耗人力的开发和上线阶段被优化，变成了配置生效，大大的减少了开发成本，缩短了排行榜开发周期。

本发明的目的及解决其技术问题是采用以下技术方案来实现的。

根据本发明一方面，提供了一种生成排行榜的方法，包括：配置第一数据源；从第一数据源获取第一数据，第一数据包括与排行榜对象及排行榜事件相关的初始数据，排行榜事件与排行榜对象相关联；根据第一数据，生成排行榜配置；根据排行榜配置生成排行榜。

根据本发明另一方面，提供了一种生成排行榜的装置，包括：数据源配置模块，用于配置第一数据源；数据获取模块，用于从第一数据源获取第一数据，第一数据包括与排行榜对象及排行榜事件相关的初始数据，排行榜事件与排行榜对象相关联；排行榜配置模块，用于根据第一数据，生成排行榜配置；以及排行榜生成模块，用于根据排行榜配置生成排行榜。

根据本发明的又一方面，本发明还包括一种计算机可读存储介质，该存储介质存储可执行指令，可执行指令在被处理器执行时，导致前述生成排行榜的方法的执行。可读存储介质可以为非易失性存储器，比如硬盘或磁盘等，并可被应用在各种终端上，可以是计算机、服务器等。

根据本发明的再一方面，本发明还包括一种排行榜系统，该系统包括处理器以及存储装置。存储装置用于存储可执行指令，当可执行指令被处理器执行时，可实现前述生成排行榜的方法。

本发明与现有技术相比具有明显的优点和有益效果。借由上述技术方案,本发明提供的一种排行榜系统及生成排行榜的方法可取得显著的技术进步性及实用性，并具有产业上的广泛利用价值，其至少具有下列优点：

1、本发明提出的一种排行榜系统及生成排行榜的方法可扩展性强，即通过在排行榜系统的不同配置来生成不同类型事件和对象的排行榜。

2、本发明提出的一种排行榜系统及生成排行榜的方法，由于优化了目前业界中主要消耗人力的开发和上线阶段，将这两个阶段变成了配置生效，即通过在排行榜系统上进行相关排行榜事件的配置来生成排行榜，大大的减少了开发成本，缩短了排行榜开发和上线周期。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图,详细说明如下。

附图说明

图1是本发明生成排行榜方法的流程图；

图2是本发明排行榜系统配置的流程图；

图3是本发明排行榜系统的工作模块示意图；

图4是与本发明排行榜系统相关的各个设备之间的网络架构图。

具体实施方式

为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效,以下结合附图及较佳实施例，对依据本发明提出的一种排行榜系统及生成排行榜的方法，其具体实施方式、方法、步骤及其功效，详细说明如后。

通过具体实施方式的说明,当可对本发明为达成预定目的所采取的技术手段及功效得一更加深入且具体的了解，然而所附图式仅是提供参考与说明之用，并非用来对本发明加以限制。

本发明实施例提供了一种生成排行榜的方法，如图1所示，包括以下步骤：

步骤S1：配置第一数据源。排行榜系统中配置与排行榜对象和排行榜事件相关的需要订阅的数据源(即业务系统)。当与排行榜事件主题相关的行为发生时，数据源会产生与排行榜对象和排行榜事件相关的数据。具体地说，在配置第一数据源时，通常需要配置MQ服务器的地址、排行榜事件主题和MQ类型或为该排行榜事件主题定义一个项目ID。通过上述配置，排行榜系统可以向第一数据源订阅与排行榜对象和排行榜事件主题相关的第一数据。

步骤S2：从第一数据源获取第一数据，第一数据包括与排行榜对象及排行榜事件相关的初始数据，排行榜事件与排行榜对象相关联。当与排行榜事件主题相关的行为发生时，第一数据源获取到包含相关于排行榜事件和排行榜对象的数据的第一数据，通过MQ方式发送给排行榜系统，从而使排行榜系统获取到第一数据。

步骤S3：根据第一数据，生成排行榜配置。排行榜系统根据获取到的第一数据的格式和内容，按照由排行榜的需求而预先设置的条件生成相关于排行榜事件和排行榜对象的具体的业务规则配置，业务规则包括前置过滤规则、数据补全规则、后置过滤规则、数据去重规则、计算加分规则以及成榜周期规则。根据不同的排行榜事件和排行榜对象，可以从上述业务规则中选择合适的业务规则进行配置。

步骤S4：根据所述排行榜配置生成排行榜。排行榜系统的各项业务配置生效后，当时间到达配置的成榜时间，Redis生成排行榜。排行榜系统从Redis的排行榜持久化数据库中获取最终的排行榜对象的排行榜。

本发明实施例提供了一种排行榜系统的配置，图2是排行榜系统中配置的流程方框图。排行榜系统具体的配置主要包括三大类：数据接入配置、业务规则配置和后置处理配置。

具体地说，数据接入配置，是指在排行榜系统中配置与排行榜对象和排行榜事件相关的需要订阅的业务系统(即，数据源)。不同的排行榜对象和排行榜事件的数据可以存在不同的业务系统中，指定的排行榜对象和排行榜事件相关的数据存在于相应的业务系统中。因此，需要在排行榜系统上配置相应的业务系统接入数据，以使排行榜系统与业务系统建立连接并能够互相通信。

当与排行榜事件主题相关的行为发生时，业务系统会产生与排行榜对象和排行榜事件相关的数据，由于排行榜系统与业务系统之间已通过配置建立逻辑连接，因此，业务系统会将相关数据(第一数据)通过已建立的逻辑连接通道发送给排行榜系统。

业务规则配置，排行榜系统收到业务系统实时发来的数据，基于这些数据的内容和格式，按照排行榜事件和对象的需求预先设置的条件，生成排行榜所需的具体业务规则配置。这些业务规则配置有：

前置过滤规则：在实际的业务应用场景中，可能会把许多数据放入相同的事件主题和事件对象中。因此，排行榜系统收到的数据中有部分数据虽然和事件主题和事件对象相关，但在由排行榜的需求而预先设定的条件之外。这种情况下，根据由排行榜的需求而预先设定的某些条件，可以通过前置过滤规则过滤掉一部分与排行榜需求无关的数据。

数据补全规则：排行榜系统收到的数据内容可能不包含排行榜需求预先设定的全部条件内容，而需要额外的数据进行补充。数据经过补充后，排行榜系统可能才能判断是否满足排行榜需求所设定的条件。这种情况下，需要通过接入另外的业务系统平台(第二数据源)以获取补充数据(第二数据)。排行榜系统可以配置与第二数据源的各种连接方式，例如，采用http接口调用的方式。排行榜系统可以从第二数据源获取相关数据(第二数据)，例如，与排行榜对象相关的其他数据。排行榜系统获取到补充数据后，将数据中的相关字段加入到初始数据中同一排行榜对象的字段之后，从而丰富排行榜对象的数据内容，完成对排行榜对象的数据补全。但并非所有运行环境下都需要对从第一数据源获取的初始数据进行数据补全，而是需要根据排行榜事件和排行榜对象的需求的不同来选择是否配置数据补全。

后置过滤规则：经过数据补全规则后的补全后数据，其中可能包含排行榜需求预先设定条件无关的无用的、多余的数据。这时，可以采用后置过滤规则过滤掉根据排行榜需求预先设定条件被判定为无用的数据。后置过滤也并非在所有的运行环境下都必须进行，而是需要根据排行榜事件和排行榜对象的需求的不同来选择是否进行后置过滤。

去重规则：通过以上规则完成后的数据，可能会由于某些原因，存在数据重复。去重规则配置允许业务配置数据的去重规则，例如基于特定字段去重，以确保后续规则处理中，不会对与排行榜事件和排行榜对象相关的重复数据进行处理，以免影响排行榜对象排行的准确性。可能造成数据重复的原因有多种，例如与排行榜事件相关的各系统本身的原因，应用操作失误，网络传输故障等原因，都可能导致与排行榜事件和排行榜对象相关的数据重复。

加分规则：根据排行榜需求不同，可以根据预设条件设定加分规则，或对所获取的排行榜对象的各种条件采取不同的加分逻辑。排行榜系统根据预设条件设定的加分规则，对从第一数据源获取的初始数据或经过补全规则后的补全数据进行对应的权重的调整。更具体地说，排行榜系统可以通过调整根据预设条件设定的加分规则的配置来计算每个排行榜对象的加分值，并将加分值记录到Redis数据库的Zset中。Redis执行更新每个排行榜对象的分值，并产生加分值流水记录。

周期规则：根据由排行榜需求而预先设定的条件，排行榜系统配置排行榜生成的时间和周期，比如分榜(实际应用中较少)、小时榜、日榜、周榜和月榜等。排行榜生成的具体时间也可以是指定的任意具体时间或时间段。当时间到达配置的成榜时间后，Redis根据排行榜系统配置的成榜周期生成排行榜。排行榜系统从Redis的排行榜持久化数据库中获取最终的排行榜对象的排行榜。

成榜后置处理配置，是指排行榜系统可以配置自定义的业务逻辑，例如向用户发一条微信消息、提供一个业务接口或者发送一条MQ消息。也可以通过成榜后置处理配置实现其他业务逻辑，例如，给排行榜对象奖励等。在排行榜系统从Redis的排行榜持久化数据库中获取最终的排行榜对象的排行榜之后，排行榜系统会根据配置的自定义的业务逻辑进行处理。

本发明实施例还提供了一种排行榜系统的配置，图3是排行榜系统中工作模块流程图。排行榜系统主要包括3个工作模块，分别是数据获取模块、业务处理模块和后置处理模块。

在数据获取模块中，配置与排行榜对象和排行榜事件相关的需要订阅的数据源(即业务系统)。当与排行榜事件主题相关的行为发生时，数据源会产生与排行榜对象和排行榜事件相关的数据。具体地说，在配置第一数据源时，通常配置MQ服务器的地址、排行榜事件主题和MQ类型或为该排行榜事件主题定义一个项目ID，以订阅与排行榜对象和排行榜事件主题相关的第一数据。通过以上配置，数据获取模块可以完成从第一数据源获取第一数据。

排行榜系统基于获取到的第一数据的格式和内容，按照由排行榜的需求而预先设置的条件，生成相关于排行榜事件和排行榜对象的具体业务规则配置。业务处理模块对配置的业务规则进行处理。业务处理模块包括前置过滤处理模块、数据补全处理模块、后置过滤处理模块、数据去重处理模块、计算加分处理模块以及成榜周期处理模块。

在不同的业务应用场景中，由于各种数据可能被放入相同的事件主题和事件对象中，因此，排行榜系统收到的数据中有部分数据虽然和事件主题和事件对象相关，但在由排行榜的需求而预先设定的条件之外。这种情况下，根据排行榜需求预先设定的某些条件，可以通过前置过滤处理模块完成过滤一部分与排行榜需求无关的数据。

由于排行榜系统收到的数据内容可能不包含由排行榜的需求而预先设定的全部条件内容，而需要额外的数据进行补充。数据经过补充后，排行榜系统可能才能判断是否满足由排行榜的需求而预先设定的条件。这种情况下，需要通过接入另外的业务系统平台(第二数据源)以获取补充数据(第二数据)。排行榜系统可以配置与第二数据源的各种连接方式，例如，采用http接口调用的方式。排行榜系统可以从第二数据源获取相关数据(第二数据)，例如，与排行榜对象相关的其他数据。排行榜系统获取到补充数据后，将数据中的相关字段加入到第一数据中同一排行榜对象的字段之后，从而丰富排行榜对象的数据内容。通过上述处理，数据补全处理模块完成对排行榜对象的数据补充。

经过数据补全规则后的补全后数据，其中可能包含排行榜需求预先设定条件无关的无用的、多余的数据。这时，可以通过后置过滤处理模块完成过滤根据由排行榜的需求而预先设定条件被判定为无用的数据。

由于经过以上处理模块处理的数据，可能会由于某些原因，存在数据重复。数据去重处理模块通过配置的去重规则，例如基于特定字段去重，从而完成数据去重，以确保后续模块处理中，不会对与排行榜事件和/或排行榜对象相关的重复数据进行处理，以免影响排行榜对象排行的准确性。

根据排行榜需求不同，可以根据预设条件设定加分规则，或对所获取的排行榜对象的各种条件采取不同的加分逻辑。计算加分处理模块完成根据预设条件设定的加分规则，对从第一数据源获取的初始数据或经过补全规则后的补充数据进行对应的权重的调整。更具体地说，计算加分处理模块根据预设条件设定的加分规则完成计算每个排行榜对象的加分值，并将加分值记录到Redis数据库的Zset中。Redis执行更新每个排行榜对象的分值，并产生加分值流水记录。

根据由排行榜的需求而预先设定的条件，成榜周期处理模块完成处理排行榜生成的时间和周期，比如分榜(实际应用中较少)、小时榜、日榜、周榜和月榜等。排行榜生成的具体时间也可以是指定的任意具体时间或时间段。当时间到达配置的成榜时间后，Redis根据排行榜系统配置的成榜周期生成排行榜。

经过业务处理模块对各项业务规则配置的处理，当时间到达配置的成榜时间后，将最终获得从Redis的排行榜持久化数据库中获取最终的排行榜对象的排行榜。

在排行榜生成之后，后置处理模块，根据排行榜系统配置自定义的业务逻辑，进行相应的业务逻辑处理，例如，向用户发一条微信消息、提供一个业务接口或者发送一条MQ消息。

下面将通过一具体实施例来说明通过本发明的排行榜系统来生成排行榜的相关过程。

这一实施例中，要求排行榜系统完成“美国地区主播收礼”排行榜的生成。“美国地区主播收礼”排行榜的需求是：在某一圣诞节运营活动(打赏事件)中生成“美国地区主播收礼”排行榜。在这一活动中，排行榜事件为“打赏事件”，排行榜对象为“主播”。

针对这一需求而预先设定的条件为：

1.展示排名前100的主播。

2.主播参与的规则：国家为美国、粉丝数>50万和主播必须为签约主播。

3.排行榜展示主播的数据字段为主播用户ID(即，排行榜对主播进行排名，在排行榜上显示主播的ID)。

4.分数计算规则：1)基本分＝打赏礼物价值；

2)新主播加分，如果为新主播(主播注册时间2020年12月)，额外加10分；

3)超级大V加分，即如果粉丝数>200万,额外加分20分；

4)打赏时间加分，如果在00:00-01:00,额外加分10分。

5.榜单类型，需要生成总榜和日榜。总榜就是整个活动期间的总排名，日榜是每天更新一次当天的打赏排名，更新时间为每天凌晨00:00

6.活动时间：2020-12-23：00～2020-12-26:00

7.成榜后续业务逻辑：定榜后，给排名前100的主播发1000枚金豆。

首先，进行数据接入配置。在排行榜系统上配置MQ服务器的地址(一个或多个)、MQ的类型，例如，Kafka和一个项目ID。由于采用数据消息订阅模式，当用户在APP客户端(可安装于手机或者电脑)通过按键进行打赏主播的行为时，这一行为触发第一数据源将第一数据发送给排行榜系统，第一数据字段包括打赏事件ID、打赏时间、打赏用户ID、被打赏的主播UID、打赏的礼物价值、主播国家、主播粉丝数及主播类型等。

其次，排行榜系统根据获取到的第一数据的格式和内容，按照由排行榜的需求而预先设置的条件中的第2条“主播参与的规则：国家为美国、粉丝数>50万和主播必须为签约主播”，依顺序在排行榜系统中进行前置过滤配置。前置过滤配置首先过滤掉第一数据中字段“主播国家”不是美国的主播，然后过滤掉第一数据中字段“主播粉丝数”小于等于50万，最后根据“签约”字段过滤掉不是签约的主播。

进一步地，由于排行榜需求预先设置的条件中的第4条的第2项“新主播加分，如果为新主播(主播注册时间2020年12月)，额外加10分”，可知字段“主播注册时间”没有包括在第一数据中。因此，为了判断哪些主播是新主播(新主播可获得加10分的权重)，需要调用其他业务平台获取主播注册时间。这种情况下，从其他业务平台获取到主播注册时间后，将获取到的字段“主播注册时间”增加至第一数据最后一个字段。根据上述要求，需配置采用何种接口调用方式从其他业务平台获取数据，例如，采用Http接口调用的方式。此外，还需配置根据主播ID获取注册时间的请求参数。经过上述配置，完成补充数据的获取。

在本实施例中由于补充数据没有与本次排行榜打赏事件和排行榜主播无关的数据，因此，在本次应用场景中，排行榜系统可省略后置过滤配置。

在本次应用场景中，由于APP端用户在点击打赏按键时，可能碰到APP端没有及时响应此次操作，导致APP端用户在短时间内重复操作，从而使得数据重复传输到排行榜系统，又或者因为中间网络传输等因素导致数据的重传。在本次应用场景中，去重规则是根据打赏事件ID来去重，即，删除重复的打赏事件ID数据。

进一步地，按照由排行榜的需求而预先设定的条件中的第4条的所有规则“基本分＝打赏礼物价值；新主播加10分；粉丝数>200万的主播加20分；打赏时间在00:00-01:00，被打赏主播加10分”，在排行榜系统中进行配置。每次打赏事件发生，排行榜系统对被打赏主播根据上述加分规则计算加分值，并将加分值记录到Redis数据库的Zset中对应的被打赏主播ID上。Redis完成更新分值、产生加分值流水记录。

更进一步地，按照由排行榜的需求而预先设定的条件中的第5条“榜单类型，需要生成总榜和日榜。总榜就是整个活动期间的总排名，日榜是每天更新一次当天的打赏排名，更新时间为每天凌晨00:00”和第6条“活动时间范围从2020-12-23零时至2020-12-26零时”，在排行榜系统中进行相应的配置。

当时间到达配置的成榜时间，即，2020-12-23零时至2020-12-26零时之间的每天凌晨00:00都会更新一次当天的“美国地区主播收礼”前100名主播排名，在2020-12-26零时生成最终的“美国地区主播收礼”前100名主播排名。

在本实施例中，按照排行榜需求预先设置的条件中的第7条“成榜后续业务逻辑：定榜后，给排名前100的主播发1000枚金豆”，在排行榜系统需配置调发金豆的接口和配置进入排行榜的100主播的查询。经过上述配置，当活动时间结束之时通过调发的金豆接口向查询到的排行榜排名前100的主播发1000枚金豆。

下面参考图4，结合上述“美国地区主播收礼”排行榜的实施例，对本发明生成排行榜整个过程中各个设备的业务数据交互过程进行阐述。图4是包括本发明排行榜系统在内的网络架构图，其用来直观说明生成排行榜的各个设备之间的业务信息交互。图4中，本发明排行榜系统装在一台服务器中，其他多个服务器为处理不同业务的服务器，在本实施例中分别称为第一数据源服务器、第二数据源服务器、Redis服务器以及礼物服务器。数据源不仅限于单个服务器，还可以是服务器集群或者云平台，其主要用于接收终端发送的相关数据、对数据进行处理以及处理相关业务请求并进行相应的业务处理等操作，例如，验证终端用户注册及使用权限、为终端用户推送各类直播数据和排行榜信息以及处理相关业务请求等。需要说明的是，实际应用中各设备不仅限于图4所示，图4不对其实际应用进行具体地限定。

终端，可以是具有网络直播功能的智能终端，例如，智能手机、平板电脑、PDA、多媒体播放器以及可穿戴设备等。在直播网络架构中，终端用户可以分为主播终端和用户终端，分别安装有主播客户端和用户客户端。上述两者客户端，通常具有面向用户或者主播的界面，以使用户和主播可以通过相应界面进行各类操作。主播可通过其客户端的界面进行直播，并与用户进行互动；用户可通过其客户端的界面观看主播直播，并与主播进行互动。

以上述“美国地区主播收礼”为例，排行榜系统已经按照上述排行榜业务规则完成配置。各设备之间业务交互如下：

1.主播通过其客户端进行直播，用户通过其客户端观看直播，在直播过程中，一个或多个用户对主播进行打赏行为，与此同时，一个或多个用户相应的用户终端将第一数据“打赏事件ID、打赏时间、打赏用户ID、被打赏的主播UID、打赏的礼物价值、主播国家、主播粉丝数及主播类型”发送给第一数据源服务器。

2.第一数据源服务器接收到一个或多个用户客户端发送的第一数据，将第一数据发送给排行榜系统。

3.排行榜系统收到这些数据，并对其进行前置过滤处理：过滤掉第一数据中字段“主播国家”不是美国的主播；过滤掉第一数据中字段“主播粉丝数”小于等于50万；过滤掉第一数据中字段“签约”中为没有签约的主播。

4.排行榜系统接入第二数据源服务器获取“主播注册时间”，并将该字段增加至第一数据最后一个字段，生成补全后第一数据。

5.排行榜系统对补全后第一数据根据打赏事件ID进行去重处理，之后排行榜系统根据加分规则配置计算被打赏主播加分值。

6.排行榜系统将被打赏主播加分值记录到Redis数据库的Zset中对应的被打赏主播ID上。Redis完成更新分值、产生加分值流水记录并在指定的2020-12-24零时，2020-12-24零时分别生成“美国地区主播收礼”排行榜，并在2020-12-26零时生成最终的“美国地区主播收礼”排行榜。

7.排行榜系统从Redis的排行榜持久化数据库中分别在2020-12-24零时，2020-12-24零时和2020-12-26零时获取最终的排行榜对象前100名的排行榜。

8.排行榜系统将生成的排行榜发给第一数据源服务器。

9.第一数据源服务器将排行榜信息发送给用户终端和主播终端。

10.排行榜系统通过调发金豆的礼物服务器接口，给前100名主播每人1000枚金豆。

上述仅是根据一个设定的直播场景，生成某种特定类型的排行榜的介绍。在这种实施场景中，排行榜对象是主播，排行榜事件为打赏，最终生成主播收礼排行榜。以此为例，来说明本发明实施例提供的生成排行榜的数据业务交互过程。但是本发明提供的生成排行榜的配置及方法并不仅限于直播场景，可以应用在其他的各类业务中。例如，在作品阅读量排行、节目收视率排行、商品销售排行等应用场景中，均可通过本发明的配置化排行榜系统及排行榜生成方式灵活地实现相应的排行榜需求。

本发明的另一方面，提供一种计算机可读存储介质，该存储介质存储可执行指令、软件程序以及模块，可执行指令在被处理器执行时，导致生成排行榜的方法的执行。可读存储介质可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件或其他非易失性固态存储器件等，并可被应用在各种终端上，可以是计算机、服务器等。

存储介质还包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random AcceSS Memory，随即存储器)、EPROM(EraSa ble Programmable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically EraSable Programmable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。存储介质也可以是只读存储器，磁盘或光盘等。

本发明的实施例还提供一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的排行榜生成方法。

另外，本发明的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的排行榜生成方法。

其中，本发明提供的装置、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明,任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims (14)

1.一种生成排行榜的方法，其特征在于，该方法包括：

配置第一数据源；

从第一数据源获取第一数据，所述第一数据包括与排行榜对象及排行榜事件相关的初始数据，所述排行榜事件与所述排行榜对象相关联；

根据所述第一数据，生成排行榜配置；

根据所述排行榜配置生成排行榜。

2.根据权利要求1所述的方法，其特征在于，所述初始数据包含所述排行榜事件ID。

3.根据权利要求1或2所述的方法，其特征在于，所述生成排行榜配置包括配置第二数据源，并从所述第二数据源获取第二数据，所述第二数据包括与所述排行榜对象和/或所述排行榜事件相关的补充数据。

4.根据权利要求3所述的方法，其特征在于，所述生成排行榜的方法还包括基于所述补充数据选择性地对所述初始数据进行补全，以生成补全数据。

5.根据前述任一权利要求所述的方法，其特征在于，所述生成排行榜配置包括根据预设条件设定评分规则，以便基于所述评分规则调整所述初始数据或所述补全数据对应的权重。

6.根据前述任一权利要求所述的方法，其特征在于，所述生成排行榜配置还包括设置第一数据过滤条件，以对所述初始数据进行前置过滤。

7.根据权利要求3-6中任一权利要求所述的方法，其特征在于，所述生成排行榜配置还包括设置第二数据过滤条件，以对所述补全数据进行过滤。

8.根据前述任一权利要求所述的方法，其特征在于，所述生成排行榜配置还包括配置数据删除条件，以删除所获取数据中的重复数据。

9.根据权利要求8所述的方法，其特征在于，所述数据删除条件包括，不同初始数据所包含的事件ID相同。

10.根据前述任一权利要求所述的方法，其特征在于，所述生成排行榜配置还包括设定成榜周期，以限定获取所述第一数据的时间范围和/或排行榜生成的时间。

11.根据前述任一权利要求所述的方法，其特征在于，所述方法还包括生成所述排行榜后的进一步处理，其中，所述进一步处理包括向指定用户发送通知、发送调用业务接口信息和/或MQ消息。

12.一种生成排行榜的装置，其特征在于，该装置包括：

数据源配置模块，用于配置第一数据源；

数据获取模块，用于从所述第一数据源获取第一数据，所述第一数据包括与排行榜对象及排行榜事件相关的初始数据，所述排行榜事件与所述排行榜对象相关联；

排行榜配置模块，用于根据所述第一数据，生成排行榜配置；以及

排行榜生成模块，用于根据所述排行榜配置生成排行榜。

13.一种计算机可读存储介质，其特征在于，该存储介质存储可执行指令，所述可执行指令在被处理器执行时，导致权利要求1-11中任一项所述的生成排行榜的方法的执行。

14.一种排行榜系统，其特征在于，包括：

处理器；

存储装置，用于存储可执行指令，

当所述可执行指令被所述处理器执行时，可实现权利要求1-11中任一权利要求所述的生成排行榜的方法。

Images