直播榜单数据更新方法、装置、电子设备和存储介质
阅读：247发布：2020-05-08
专利汇可以提供直播榜单数据更新方法、装置、电子设备和存储介质专利检索，专利查询，专利分析的服务。并且本 申请 涉及一种直播榜单数据更新方法、装置、 电子 设备和存储介质。所述方法包括通过获取直播过程中至少一个用户对直播间的贡献事件，并根据事件类型确定贡献事件对应的贡献值，基于消息 中间件 将贡献事件对应的贡献值按用户标识存储于相应的消息分区中，进而根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，而线程池中仅运行一个线程，从而保证同一用户的数据更新在单线程中有序执行，保障了榜单数据更新的正确性，进而提高了更新后的榜单数据的可靠性。，下面是直播榜单数据更新方法、装置、电子设备和存储介质专利的具体信息内容。
1.一种直播榜单数据更新方法，其特征在于，所述方法包括：
获取直播过程中至少一个用户对直播间的贡献事件，所述贡献事件包括发起贡献的用户标识和事件类型；
根据所述事件类型确定所述贡献事件对应的贡献值；
基于消息中间件将所述贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
根据所述消息分区中存储的所述贡献事件对应的贡献值，采用与所述用户标识对应的线程池更新所述直播间的榜单贡献数据，所述线程池中同一时刻仅运行一个线程。
2.根据权利要求1所述的直播榜单数据更新方法，其特征在于，所述基于消息中间件将所述贡献事件对应的贡献值按用户标识存储于相应的消息分区中，包括：
基于消息中间件按用户标识生成对应的消息分区；
将所述贡献事件对应的贡献值顺序写入与所述用户标识对应的消息分区中。
3.根据权利要求1所述的直播榜单数据更新方法，其特征在于，所述根据所述消息分区中存储的所述贡献事件对应的贡献值，采用与所述用户标识对应的线程池更新所述直播间的榜单贡献数据，包括：
根据所述消息分区中存储的所述贡献事件对应的贡献值，采用与所述用户标识对应的线程池更新用户对直播间的总贡献值；
根据所述用户对所述直播间的总贡献值更新所述直播间的榜单贡献数据。
4.根据权利要求1所述的直播榜单数据更新方法，其特征在于，所述根据所述消息分区中存储的所述贡献事件对应的贡献值，采用与所述用户标识对应的线程池更新所述直播间的榜单贡献数据，包括：
当满足批量处理条件时，根据存储的所述贡献事件对应的贡献值计算所述消息分区中多个贡献事件的累加贡献值；
根据所述累加贡献值采用与所述用户标识对应的线程池更新所述用户对所述直播间的总贡献值；
根据所述用户对所述直播间的总贡献值更新所述直播间的榜单贡献数据。
5.根据权利要求3或4所述的直播榜单数据更新方法，其特征在于，所述根据所述用户对所述直播间的总贡献值更新所述直播间的榜单贡献数据，包括：
根据所述用户对所述直播间的总贡献值，采用第一命令更新直播间的榜单贡献数据中对应用户的总贡献值；
若更新后的直播间的榜单贡献数据的长度大于预设长度，则从更新后的直播间的榜单贡献数据中提取排序靠前的预设长度的数据作为直播间的当前榜单贡献数据。
6.根据权利要求1至4任一项所述的直播榜单数据更新方法，其特征在于，所述事件类型包括点击事件和虚拟送礼事件中的任一种。
7.根据权利要求1至4任一项所述的直播榜单数据更新方法，其特征在于，所述消息中间件采用分布式发布订阅消息系统。
8.一种直播榜单数据更新装置，其特征在于，所述装置包括：
贡献事件获取模块，用于获取直播过程中至少一个用户对直播间的贡献事件，所述贡献事件包括发起贡献的用户标识和事件类型；
贡献值确定模块，用于根据所述事件类型确定所述贡献事件对应的贡献值；
存储模块，用于基于消息中间件将所述贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
榜单贡献数据更新模块，用于根据所述消息分区中存储的所述贡献事件对应的贡献值，采用与所述用户标识对应的线程池更新所述直播间的榜单贡献数据，所述线程池中同一时刻仅运行一个线程。
9.一种电子设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述方法的步骤。
直播榜单数据更新方法、装置、电子设备和存储介质
技术领域
背景技术
[0002] 随着互联网技术的不断发展，网络在线直播已成为一种新兴的网络社交方式，与在线直播业务对应的各种各样的排行榜单也应运而生。例如：“主播人气榜单”、“观众等级榜单”、“直播PK贡献榜单”等，都是非常重要且能够增加用户粘性的方式。
[0003] 而直播PK贡献榜单，是指按用户对直播间的贡献值进行排序的一个有序列表。由于直播PK的贡献值来源有多个，包含点赞、虚拟礼物、暴击时刻等，从而存在并发更新榜单中用户贡献值的情况，但是，由于网络等原因会导致并发更新榜单的顺序无法得到保证，从而存在榜单中用户贡献值不正确使得榜单数据可靠性低的问题。发明内容
[0004] 基于此，有必要针对上述并发更新榜单导致榜单数据可靠性低的问题，提供一种能够有效提高榜单数据可靠性的直播榜单数据更新方法、装置、电子设备和存储介质。
[0005] 为了实现上述目的，一方面，本申请实施例提供了一种直播榜单数据更新方法，所述方法包括：
[0006] 获取直播过程中至少一个用户对直播间的贡献事件，其中贡献事件包括发起贡献的用户标识和事件类型；
[0007] 根据事件类型确定贡献事件对应的贡献值；
[0008] 基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
[0009] 根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，其中，线程池中同一时刻仅运行一个线程。
[0010] 在其中一个实施例中，基于消息中间件将所述贡献事件对应的贡献值按用户标识存储于相应的消息分区中，包括：基于消息中间件按用户标识生成对应的消息分区；将贡献事件对应的贡献值顺序写入与用户标识对应的消息分区中。
[0011] 在其中一个实施例中，根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，包括：根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新用户对直播间的总贡献值；根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0012] 在其中一个实施例中，根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，包括：当满足批量处理条件时，根据存储的贡献事件对应的贡献值计算消息分区中多个贡献事件的累加贡献值；根据累加贡献值采用与用户标识对应的线程池更新用户对直播间的总贡献值；根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0013] 在其中一个实施例中，根据用户对直播间的总贡献值更新直播间的榜单贡献数据，包括：根据用户对直播间的总贡献值，采用第一命令更新直播间的榜单贡献数据中对应用户的总贡献值；若更新后的直播间的榜单贡献数据的长度大于预设长度，则从更新后的直播间的榜单贡献数据中提取排序靠前的预设长度的数据作为直播间的当前榜单贡献数据。
[0014] 在其中一个实施例中，事件类型包括点击事件和虚拟送礼事件中的任一种。
[0015] 在其中一个实施例中，消息中间件采用分布式发布订阅消息系统。
[0016] 另一方面，本申请实施例还提供了一种直播榜单数据更新装置，包括：
[0017] 贡献事件获取模块，用于获取直播过程中至少一个用户对直播间的贡献事件，其中，贡献事件包括发起贡献的用户标识和事件类型；
[0018] 贡献值确定模块，用于根据事件类型确定贡献事件对应的贡献值；
[0019] 存储模块，用于基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
[0020] 榜单贡献数据更新模块，用于根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，其中，线程池中同一时刻仅运行一个线程。
[0022] 再一方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述方法的步骤
[0023] 上述直播榜单数据更新方法、装置、电子设备和存储介质，其通过获取直播过程中至少一个用户对直播间的贡献事件，并根据事件类型确定贡献事件对应的贡献值，基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中，进而根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，而线程池中仅运行一个线程，从而保证同一用户的数据更新在单线程中有序执行，保障了榜单数据更新的正确性，进而提高了更新后的榜单数据的可靠性。附图说明
[0024] 图1为传统技术中直播榜单数据更新原理图；
[0025] 图2为一个实施例中直播榜单数据更新方法的应用环境图；
[0026] 图3为一个实施例中直播榜单数据更新方法的流程示意图；
[0027] 图4为一个实施例中消息分区存储步骤的流程示意图；
[0028] 图5为一个实施例中更新直播间的榜单贡献数据步骤的流程示意图；
[0029] 图6为另一个实施例中更新直播间的榜单贡献数据步骤的流程示意图；
[0030] 图7为一个实施例中更新直播间的榜单贡献数据步骤的流程示意图；
[0031] 图8为另一个实施例中直播榜单数据更新方法的流程示意图；
[0032] 图9为一个实施例中直播榜单数据更新装置的结构框图；
[0033] 图10为一个实施例中电子设备的内部结构图。
具体实施方式
[0034] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
[0035] 由于在直播PK(Player Killing，对决)过程中用户得到贡献值的成本很低，即只需要在直播PK过程中点赞即可得到对应的贡献值，从而导致全量有贡献值的用户量过大，因此，难以将所有对直播间具有贡献值的用户存储于一个有序列表中。现有的方案一般通过redis(REmote DIctionary Server，数据结构服务器)的key(关键字)-value(值)数据结构存储用户(即key，通常为用户标识)对直播间的总贡献值(对应的value)，并用redis的有序列表(zset)保存适度冗余的榜单用户，而最终向用户展示的贡献榜单通常为top K(即贡献值最大的前K个用户数据)，其中K的取值可以根据用户需求而设定，其长度通常不大于redis中保存的有序列表的长度。
[0036] 又由于直播PK的贡献值来源有多个，包含点赞、虚拟礼物、暴击时刻等，从而存在并发更新榜单中用户贡献值的情况。如图1所示，用户u1当前贡献值为80，并发的两条新增贡献值分别为10、20，由于网络等原因会导致更新榜单的顺序无法得到保证，从而可能导致榜单中用户贡献值不正确，例如，1)进程1先执行的+10，返回了90；2)进程2再执行的+20，返回了110；3)进程2执行了更新榜单，榜单中u1更新成100；4)进程1再执行了更新榜单，榜单中u1更新为90。由于对于两次贡献值的榜单更新在不同的进程中执行，因此执行顺序没法得到保证，即无法保证先执行的+10的操作的更新榜单比后执行的+20的操作的更新榜单先完成，而用户u1的最终贡献值应该是110，但是由于并发问题导致u1在榜单中的贡献值为90，导致榜单数据的可靠性较低。
[0037] 基于此，本申请实施例提供了一种直播榜单数据更新方法，通过将同一用户的数据更新在单线程中有序执行，从而保障了榜单数据更新的正确性，进而提高了更新后的榜单数据的可靠性。
[0038] 本申请提供的直播榜单数据更新方法，可以应用于如图2所示的应用环境中。其中，第一终端202和第二终端204与服务器206通过网络进行通信，其中，第一终端202为直播终端，第二终端204则为观众终端，当第一终端202进行直播时，该直播间的多个粉丝可以分别通过各自的第二终端204观看直播内容。具体的，第一终端202和第二终端204可以是各种个人计算机、笔记本电脑、智能手机、平板电脑等中的至少一种，服务器206可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
[0039] 本实施例中的直播榜单数据更新方法，通过获取直播过程中至少一个用户对直播间的贡献事件，并根据事件类型确定贡献事件对应的贡献值，基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中，进而根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，而线程池中仅运行一个线程，从而保证同一用户的数据更新在单线程中有序执行，保障了榜单数据更新的正确性，进而提高了更新后的榜单数据的可靠性。
[0040] 在一个实施例中，如图3所示，提供了一种直播榜单数据更新方法，以该方法应用于图2中的服务器为例进行说明，包括以下步骤：
[0041] 步骤302，获取直播过程中至少一个用户对直播间的贡献事件。
[0042] 其中，贡献事件包括发起贡献的用户标识和事件类型，具体的，事件类型包括点击事件或虚拟送礼事件，而点击事件又包括普通的点赞和对于暴击时刻的点击等。用户标识则是区分不同用户的标记，例如可以是用户登录直播间的用户ID(Identity document，登录帐号)。用户在观看直播PK过程中，可以通过客户端发起对心仪直播间的送礼行为、点赞行为或对于暴击时刻的点击行为等，从而得到用户对直播间的贡献值，进而通过对该直播间的每个用户的总贡献值进行排序，而得到一个有序的贡献列表。而在直播过程中，可能会不断的爆发对直播间的贡献事件，而当贡献事件产生，则对应直播间的贡献列表也需要进行相应更新，因此，在本实施例中，通过服务器实时获取直播过程中至少一个用户对直播间的贡献事件，进而根据贡献事件更新直播间的贡献列表。
[0043] 步骤304，根据事件类型确定贡献事件对应的贡献值。
[0044] 其中，贡献值是预先设定的事件类型的权重值，对于每一事件类型都可以预先设置相应的权重值，即可以根据事件类型的不同，设置不同的权重值。需要说明的是，对于点击事件中的点赞行为和暴击时刻的点击行为可以分别设置不同的权重值；对于虚拟送礼事件，则可以根据虚拟礼物所对应的价值的不同而分别设置不同的权重值。因此，在本实施例中，根据贡献事件的事件类型及预先设置的权重值即可得到贡献事件对应的贡献值。
[0045] 步骤306，基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中。
[0046] 其中，消息中间件具体可以采用高吞吐量的分布式发布订阅消息系统kafka，基于kafka具有消息分区及分布式消费的特点，为了避免传统的榜单更新对于并发场景下的执行顺序无法保障的问题，在本实施例中引入了消息中间件，并将贡献事件对应的贡献值按用户标识存储于相应的消息分区中，即按用户标识进行消息分区，并将同一用户对直播间的贡献事件对应的贡献值有序存储于对应的消息分区中，进而有序消费，从而保证了同一用户的数据更新不会出现并发问题。
[0047] 步骤308，根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据。
[0048] 其中，线程池中同一时刻仅运行一个线程。由于直播间的贡献列表是对该直播间的每个用户的总贡献值进行排序后得到的，又由于对直播间有贡献值的全部用户量过大，因此，通常将贡献列表中适度冗余的榜单用户保存为直播间的榜单贡献数据，并存储于redis中。而在直播过程中，可能会不断的爆发对直播间的贡献事件，而当贡献事件产生，则对应的用户对直播间的总贡献值也会发生改变，进而直播间的榜单贡献数据也需要进行相应更新。本实施例为了避免并发场景下榜单更新可靠性低的问题，从而将同一用户的数据更新收敛至同一个线程池中，即根据贡献事件的用户标识选择对应的线程池对直播间的榜单贡献数据进行更新，又由于线程池中同一时刻仅运行一个线程，且消息分区中消息有序消费的特性，从而使得同一用户的数据更新可以通过同一线程池有序处理，即通过与用户标识对应的线程池有序处理相应消息分区中存储的贡献值，即根据贡献事件对应的贡献值更新直播间的榜单贡献数据。
[0049] 上述直播榜单数据更新方法，通过获取直播过程中至少一个用户对直播间的贡献事件，并根据事件类型确定贡献事件对应的贡献值，基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中，进而根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，而线程池中仅运行一个线程，从而保证同一用户的数据更新在单线程中有序执行，保障了榜单数据更新的正确性，进而提高了更新后的榜单数据的可靠性。
[0050] 在一个实施例中，如图4所示，基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中，具体可以包括如下步骤：
[0051] 步骤402，基于消息中间件按用户标识生成对应的消息分区。
[0052] 具体的，消息中间件可以采用高吞吐量的分布式发布订阅消息系统kafka，基于kafka具有消息分区及分布式消费的特点，且同一分区(partition)内的消息具有有序性的特点，因此，在本实施例中基于kafka，可以根据贡献事件的用户标识生成对应的消息分区。
[0053] 步骤404，将贡献事件对应的贡献值顺序写入与用户标识对应的消息分区中。
[0054] 由于在直播过程中，可能会不断的爆发对直播间的贡献事件，因此，当服务器获取到用户对直播间的贡献事件后，则根据贡献事件的用户标识将贡献事件对应的贡献值顺序写入与用户标识对应的消息分区中。即按用户标识进行消息分区存储，将同一用户对直播间的贡献事件对应的贡献值有序存储于对应的消息分区中，进而有序消费，从而保证了同一用户的数据更新不会出现并发问题。
[0055] 在一个实施例中，如图5所示，根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，具体可以包括如下步骤：
[0056] 步骤502，根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新用户对直播间的总贡献值。
[0057] 其中，线程池可以采用亲缘性线程池，具体的，通过建立N个线程池，如pool1、pool2、…、poolN，每个线程池同一时刻仅运行一个线程，且基于消息分区具有有序消费的特性，因此，当消息分区中存储的贡献事件被消费时，根据当前被消费的贡献事件的用户标识选择对应的线程池进行处理，即根据当前被消费的贡献事件将同一用户发起的贡献事件对应的贡献值收敛至同一个线程池中进行有序处理。由于用户对直播间的总贡献值是通过redis的key-value数据结构存储的，又由于每个线程池同一时刻仅运行一个线程，且同一用户发起的贡献事件对应的贡献值被收敛至同一个线程池中进行有序处理，因此，线程池根据当前被消费的贡献事件对应的贡献值更新用户对直播间的总贡献值，即根据当前被消费的贡献事件对应的用户标识查找相应的key，并根据当前被消费的贡献事件对应的贡献值更新key对应的value，则更新后的value为更新前的value与当前被消费的贡献事件对应的贡献值之和。
[0058] 步骤504，根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0059] 由于直播间的榜单贡献数据是通过对该直播间的每个用户的总贡献值进行排序并经过适度冗余后得到的一个有序列表，因此，当用户发起贡献事件并经过上述步骤的处理后，则对应用户的总贡献值发生了改变，因此，需要对列表进行重新排序，即根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0060] 本实施例由于每个线程池同一时刻仅运行一个线程，且同一用户发起的贡献事件对应的贡献值被收敛至同一个线程池中进行有序处理，因此保证了同一用户的总贡献值更新是在单线程内进行的，从而解决了并发导致榜单更新不正确的问题，进而提高了榜单数据的准确性和可靠性。
[0061] 在一个实施例中，如图6所示，根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，具体可以包括如下步骤：
[0062] 步骤602，当满足批量处理条件时，根据存储的贡献事件对应的贡献值计算消息分区中多个贡献事件的累加贡献值。
[0063] 由于本申请通过消息中间件将同一用户对直播间的贡献事件对应的贡献值收敛于同一个消息分区中，然后采用对应的线程池对消息分区中的贡献事件进行顺序消费，从而确保榜单数据的准确性和可靠性。但是，对于某些特定场合，如发生暴击时刻时，则用户在短时间内(如500毫秒至1秒内)可能会产生多次贡献事件，从而导致服务器的瞬时处理压力过大。因此，在本实施例中，在将同一用户对直播间的贡献事件对应的贡献值收敛于同一个消息分区中时，可以判断是否满足批量处理条件，即判断同一用户是否在预设时间内(如500毫秒至1秒内)暴发多次贡献事件，如果同一用户在预设时间内暴发了多次贡献事件，则确定满足批量处理条件。
[0064] 当确定满足批量处理条件时，则可以对批量暴发的用户对应的消息分区中的多个贡献事件进行本地聚合，即将批量暴发的用户对应的消息分区中的多个贡献事件分别对应的贡献值进行累加计算，得到消息分区中多个贡献事件的累加贡献值，从而根据累加贡献值采用后续步骤更新用户对直播间的总贡献值。
[0065] 步骤604，根据累加贡献值采用与用户标识对应的线程池更新用户对直播间的总贡献值。
[0066] 由于累加贡献值是根据同一用户在短时间内暴发的多次贡献事件得到的，因此，根据该用户的用户标识选择对应的线程池更新用户对直播间的总贡献值，即根据用户标识查找相应的key，并根据上述计算的累加贡献值更新key对应的value，则更新后的value为更新前的value与上述计算的累加贡献值之和。
[0067] 步骤606，根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0068] 由于直播间的榜单贡献数据是通过对该直播间的每个用户的总贡献值进行排序并经过适度冗余后得到的一个有序列表，因此，当用户发起贡献事件并经过上述步骤的处理后，则对应用户的总贡献值发生了改变，因此，需要对列表进行重新排序，即根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0069] 本实施例通过将同一用户在短时间内暴发的多次贡献事件进行本地聚合后再交由对应的线程池进行榜单更新，在确保榜单数据的准确性和可靠性的同时，极大的缓解了服务器的瞬时处理压力。
[0070] 在一个实施例中，如图7所示，根据用户对直播间的总贡献值更新直播间的榜单贡献数据，具体可以包括如下步骤：
[0071] 步骤702，根据用户对直播间的总贡献值，采用第一命令更新直播间的榜单贡献数据中对应用户的总贡献值。
[0072] 其中，第一命令是指redis zadd命令(用于添加所有指定的成员指定的值存放在键的有序集合)。由于直播间的榜单贡献数据是通过对该直播间的每个用户的总贡献值进行排序并经过适度冗余后得到的一个有序列表，因此，直播间的榜单贡献数据并没有存储全量的对直播间有贡献值的全部用户数据，而当前对直播间的总贡献值发生改变的用户不一定存在于直播间的榜单贡献数据中，当对直播间的总贡献值发生改变的用户不在直播间的榜单贡献数据中时，如果采用redis的原子操作进行榜单数据更新，会导致该用户之前的贡献值丢失，从而导致榜单数据更新的不正确。因此，为了保证榜单数据更新的准确性，本实施例通过采用redis zadd命令将用户更新后的key-value贡献值更新到直播间的榜单贡献数据中，即将对直播间的总贡献值发生改变的用户及对应的总贡献值加入到有序排列的直播间的榜单贡献数据中；如果对直播间的总贡献值发生改变的用户已经存在于直播间的榜单贡献数据中，则更新对应用户的贡献值，并通过重新插入数据而保证对直播间的总贡献值发生改变的用户能够在榜单中正确的位置上。
[0073] 步骤704，若更新后的直播间的榜单贡献数据的长度大于预设长度，则从从更新后的直播间的榜单贡献数据中提取排序靠前的预设长度的数据作为直播间的当前榜单贡献数据。
[0074] 由于在经过上述更新后，直播间的榜单贡献数据中可能会被加入一些新的用户数据，从而导致榜单数据长度发生改变，因此，在本实施例中，可以采用Redis Zcard命令(用于计算集合中元素的数量)获取更新后的直播间的榜单贡献数据的长度，当更新后的直播间的榜单贡献数据的长度大于预设长度时，则采用trim命令(用于去掉集合中多余的数据长度)从更新后的直播间的榜单贡献数据中去掉多余的数据，即只保留排序靠前的预设长度的数据作为直播间的当前榜单贡献数据，从而完成对直播间的榜单贡献数据的更新。
[0075] 进一步的，当用户通过API(Application Programming Interface，应用程序接口)请求top K的贡献榜单时，API则从redis存储的直播间的榜单贡献数据中获取top K的用户数据展示给用户，使得用户可以获知top K的贡献榜单。
[0076] 为了更加清楚描述本申请所提出的直播榜单数据更新方法的具体过程，下面以一个具体的实施例来描述本申请的方法，如图8所示：
[0077] 1)用户在直播间内发生点赞、送礼等用户行为，发送对应行为消息(即发送对直播间的贡献事件)。
[0078] 2)消费用户行为的消息，计算用户当次贡献分(即根据用户当次行为计算对应的贡献值)。
[0079] 3)按用户标识选择partition(即消息分区)，发送用户贡献分消息。
[0080] 4)选择线程池消费贡献分消息。
[0081] 5)incr用户key。
[0082] 6)根据用户的当次贡献分，累计到用户总贡献分，即更新key-value。
[0083] 7)以用户总贡献分，更新榜单贡献分数据，即采用redis zadd命令将用户更新后的key-value贡献值更新到直播间的榜单贡献数据中。
[0084] 8)采用Redis Zcard命令获取更新后的直播间的榜单贡献数据的长度。
[0085] 9)判断长度是否大于预设长度。
[0086] 10)若大于，则采用trim命令从更新后的直播间的榜单贡献数据中去掉多余的数据，即只保留排序靠前的预设长度的数据作为直播间的当前榜单贡献数据，从而完成对直播间的榜单贡献数据的更新。
[0087] 11)用户请求后端api接口获取topK的贡献榜单。
[0088] 12)api从redis存储的直播间的榜单贡献数据中获取topK的贡献榜单。
[0089] 13)api将获取的topK的贡献榜单展示给用户。
[0090] 应该理解的是，虽然图2-8的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-8中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
[0091] 在一个实施例中，如图9所示，提供了一种直播榜单数据更新装置，包括：贡献事件获取模块901、贡献值确定模块902、存储模块903和榜单贡献数据更新模块904，其中：
[0092] 贡献事件获取模块901，用于获取直播过程中至少一个用户对直播间的贡献事件，其中，贡献事件包括发起贡献的用户标识和事件类型；
[0093] 贡献值确定模块902，用于根据事件类型确定贡献事件对应的贡献值；
[0094] 存储模块903，用于基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
[0095] 榜单贡献数据更新模块904，用于根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，其中，线程池中同一时刻仅运行一个线程。
[0096] 在一个实施例中，存储模块903包括：分区单元，用于基于消息中间件按用户标识生成对应的消息分区；写入单元，用于将贡献事件对应的贡献值顺序写入与用户标识对应的消息分区中。
[0097] 在一个实施例中，榜单贡献数据更新模块904包括：第一更新单元，用于根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新用户对直播间的总贡献值；第二更新单元，用于根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0098] 在一个实施例中，榜单贡献数据更新模块904还包括批量处理单元，用于当满足批量处理条件时，根据存储的贡献事件对应的贡献值计算消息分区中多个贡献事件的累加贡献值；则第一更新单元还用于，根据累加贡献值采用与用户标识对应的线程池更新用户对直播间的总贡献值。
[0099] 在一个实施例中，第二更新单元具体用于：根据用户对直播间的总贡献值，采用第一命令更新直播间的榜单贡献数据中对应用户的总贡献值；若更新后的直播间的榜单贡献数据的长度大于预设长度，则从更新后的直播间的榜单贡献数据中提取排序靠前的预设长度的数据作为直播间的当前榜单贡献数据。
[0100] 在一个实施例中，事件类型包括点击事件和虚拟送礼事件中的任一种。
[0101] 在一个实施例中，消息中间件采用分布式发布订阅消息系统。
[0102] 关于直播榜单数据更新装置的具体限定可以参见上文中对于直播榜单数据更新方法的限定，在此不再赘述。上述直播榜单数据更新装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
[0103] 在一个实施例中，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图10所示。该电子设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的数据库用于存储用户对直播间的贡献事件数据。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种直播榜单数据更新方法。
[0104] 本领域技术人员可以理解，图10中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
[0105] 在一个实施例中，提供了一种电子设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：
[0106] 获取直播过程中至少一个用户对直播间的贡献事件，其中贡献事件包括发起贡献的用户标识和事件类型；
[0107] 根据事件类型确定贡献事件对应的贡献值；
[0108] 基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
[0109] 根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，其中，线程池中同一时刻仅运行一个线程。
[0110] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：基于消息中间件按用户标识生成对应的消息分区；将贡献事件对应的贡献值顺序写入与用户标识对应的消息分区中。
[0111] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新用户对直播间的总贡献值；根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0112] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：当满足批量处理条件时，根据存储的贡献事件对应的贡献值计算消息分区中多个贡献事件的累加贡献值；根据累加贡献值采用与用户标识对应的线程池更新用户对直播间的总贡献值；根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0113] 在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据用户对直播间的总贡献值，采用第一命令更新直播间的榜单贡献数据中对应用户的总贡献值；若更新后的直播间的榜单贡献数据的长度大于预设长度，则从更新后的直播间的榜单贡献数据中提取排序靠前的预设长度的数据作为直播间的当前榜单贡献数据。
[0114] 在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：
[0115] 获取直播过程中至少一个用户对直播间的贡献事件，其中贡献事件包括发起贡献的用户标识和事件类型；
[0116] 根据事件类型确定贡献事件对应的贡献值；
[0117] 基于消息中间件将贡献事件对应的贡献值按用户标识存储于相应的消息分区中；
[0118] 根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新直播间的榜单贡献数据，其中，线程池中同一时刻仅运行一个线程。
[0119] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：基于消息中间件按用户标识生成对应的消息分区；将贡献事件对应的贡献值顺序写入与用户标识对应的消息分区中。
[0120] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据消息分区中存储的贡献事件对应的贡献值，采用与用户标识对应的线程池更新用户对直播间的总贡献值；根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0121] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：当满足批量处理条件时，根据存储的贡献事件对应的贡献值计算消息分区中多个贡献事件的累加贡献值；根据累加贡献值采用与用户标识对应的线程池更新用户对直播间的总贡献值；根据用户对直播间的总贡献值更新直播间的榜单贡献数据。
[0122] 在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据用户对直播间的总贡献值，采用第一命令更新直播间的榜单贡献数据中对应用户的总贡献值；若更新后的直播间的榜单贡献数据的长度大于预设长度，则从更新后的直播间的榜单贡献数据中提取排序靠前的预设长度的数据作为直播间的当前榜单贡献数据。
[0123] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 通信数据同步及处理方法和系统 | 2020-05-08 | 43 |
| 基于CDN和MEC的车联网移动性管理方法 | 2020-05-08 | 530 |
| 业务数据事件的分析订阅方法及系统 | 2020-05-08 | 507 |
| 电子券发放方法和装置 | 2020-05-11 | 915 |
| 一种业务处理系统、业务处理的方法、装置及设备 | 2020-05-12 | 1013 |
| 点赞信息处理方法、装置及系统 | 2020-05-12 | 284 |
| 基于数据传输服务的软硬件解耦设计的系统设计方法 | 2020-05-08 | 795 |
| 一种动态剪裁发布订阅关系的LVC网关 | 2020-05-08 | 138 |
| 事务处理方法、装置、设备及存储介质 | 2020-05-12 | 832 |
| 信息处理方法、装置、电子设备及存储介质 | 2020-05-11 | 49 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
消息中间件热门专利
QQ群二维码
意见反馈
意见反馈