Live broadcast task matching method and device, electronic equipment and computer readable medium

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

以下示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

在一些相关的实施例中，直播任务主要通过独立的主播账号单独进行，任务策略集中于时间维度上，一场任务的结果在时间上影响后续创建的任务。直播任务的普惠性强，但主播账号之间缺乏互动性。

对于主播账号之间的互动任务，主要在一对互动账号或者多个互动账号之间进行，参与主体为各个主播账号，电子设备通过获取各个主播账号在固定时间内的分数值进行判定。随着业务的快速迭代，这种互动任务会对用户产生很大的消耗，导致主播与观众之间的互动性逐渐降低，进而导致服务器、网络等资源利用率低。

任务PVP(Player versus player，玩家对战玩家)是在直播任务的基础上，增加了互动属性，以匹配双方的任务为参与主体，使主播提高任务效率，以获得更多资源，进而提升直播的互动性，并提升网络资源的利用率。

任务PVP的主要流程为：

1、当主播满足一定的参与门槛限制时，主播在完成单个任务后加入匹配池进行匹配；

2、在一定时间范围内为主播匹配到任务能力相当的对手时，则以匹配双方的任务能力值为基础计算出公共的任务目标值，并以此目标值为匹配双方创建任务，并通过H5页面，即符合HTML5(HyperText Markup Language 5，超文本标记语言)标准实现的页面，或者直播间挂件等触达方式通知给主播；

3、如果在任务完成时限内有一方提前完成了任务，则视为该主播成功且对手主播失败；如果在任务完成时限内双方都没有完成任务，则视为双方均失败。获胜主播将获得任务资源和对战资源。如果未到任务完成时限，失败主播可继续完成本轮主播任务并获得任务资源。

在上述内容的基础上，本示例实施方式首先提供了一种直播任务的匹配方法。参考图1所示，上述直播任务的匹配方法可以包括以下步骤：

步骤S110.针对所有处于开播状态的账号，获取账号的任务状态，并确定账号是否满足任务互动参与条件。

步骤S120.在账号满足任务互动参与条件时，获取账号在任务互动匹配池中的任务互动匹配状态。

步骤S130.若账号已加入任务互动匹配池并且匹配成功，则在匹配成功的双方账号的直播间中创建互动任务。

步骤S140.根据双方账号在任务结算时间内的任务状态确定任务互动结果，并根据任务互动结果向相应的账号下发任务资源。

本公开示例实施方式的直播任务的匹配方法中，通过获取账号的任务状态，并确定账号是否满足任务互动参与条件，在账号满足任务互动参与条件时，获取账号在任务互动匹配池中的任务互动匹配状态。若账号已加入任务互动匹配池并且匹配成功，则在匹配成功的双方账号的直播间中创建互动任务，最后根据双方账号在任务结算时间内的任务状态确定任务互动结果，并根据任务互动结果向相应的账号下发任务资源。本公开示例实施方式中的直播任务的匹配方法，提供了一套完整的直播场景下的直播任务互动的技术方案，通过将任务作为互动的参与主体而非主播账号本身，并将完成任务的效率作为双方主播竞争的目标，一方面，将主播账号之间相互独立的独立任务和互动性强的互动任务进行融合，以独立任务为主，以互动任务为辅，为直播任务赋予额外的互动属性，增强直播任务的竞争性，提升直播的任务效率，增强直播任务的互动性，从而提升服务器、网络等资源利用率；另一方面，独立任务实现方案、互动任务实现方案、匹配策略、资源下发方案等不受限制，可根据具体场景进行适当调整，增强了方案的适应性和可扩展性。

下面，结合图2至图7对本示例实施方式的上述步骤进行更加详细的说明。

在步骤S110中，针对所有处于开播状态的账号，获取账号的任务状态，并确定账号是否满足任务互动参与条件。

本示例实施方式中，处于开播状态的账号指的是处于开播状态的主播账号，针对所有处于开播状态的主播账号，首先获取所有账号的任务状态，其中，账号的任务状态指的是任务的完成状态或者完成进度，包括未开始、已完成、已过期等。同时，确定该账号是否满足任务互动参与条件，任务互动参与条件可以根据任意需求进行设置，例如，当直播间人数达到一定阈值时，该账号可以满足任务互动参与条件。

本示例实施方式中，如图2所示，确定账号是否满足任务互动参与条件，具体可以包括以下几个步骤：

步骤S210.从账号数据存储系统中获取账号的任务互动状态，并根据账号的任务互动状态判断账号是否处于上一局互动任务中。

账号的任务互动状态可以存储在账号数据存储系统，例如redis系统中，根据账号的任务互动状态可以判断该账号是否仍处于上一局的互动任务中，或者上一局互动任务已结算等等。

若该账号仍处于上一局互动任务中，则不做处理，等待下一次任务扫描处理。

步骤S220.若上一局互动任务不存在或者已结算，则判断账号是否满足任务互动参与条件。

若上一局互动任务不存在或者已结算，则检查判断该账号是否满足任务互动参与条件，例如直播间人数是否达标等。

步骤S230.若账号不满足任务互动参与条件，则在账号的直播间中创建普通任务。

若该账号不满足任务互动参与条件，则根据产品策略，在该账号的直播间中创建普通任务。

继续参考图1所示，在步骤S120中，在账号满足任务互动参与条件时，获取账号在任务互动匹配池中的任务互动匹配状态。

若该账号满足任务互动参与条件，则检查当前任务的匹配状态。如果当前任务尚未加入互动匹配池，则调用匹配池服务，将该账号加入匹配池。

本示例实施方式中，如图3所示，获取账号在任务互动匹配池中的任务互动匹配状态，具体可以包括以下几个步骤：

步骤S310.根据预设的匹配时间间隔，从账号数据存储系统获取任务互动匹配池中的待匹配账号以及相应的匹配策略。

本示例实施方式中，所有账号中的待匹配账号在经过分片(shard)处理后，以有序集合(zset)的形式存储在账号数据存储系统中，而匹配策略以键值对(kv)结构的形式存储在账号数据存储系统中。

步骤S320.根据匹配策略，按照待匹配账号加入任务互动匹配池中的顺序，为待匹配账号匹配相应的互动账号。

匹配任务定时从redis中获取匹配时间内的待匹配账号以及任务对应的策略上下文，根据产品策略按照加入匹配池的顺序为待匹配账号匹配相应的互动账号。

步骤S330.若匹配成功，则将双方账号移出任务互动匹配池，将双方账号的任务互动匹配状态初始化为已匹配状态，并创建双方账号的互动记录。

如果匹配成功，则将双方账号移出任务互动匹配池，并初始化一条已匹配状态的互动记录。

步骤S340.若匹配失败，则不对待匹配账号进行任何处理，并等待下次匹配任务的执行。

如果匹配失败，则不做任何处理，等待下次匹配任务执行。

步骤S350.当待匹配账号在任务互动匹配池中的存留时长超过最大匹配时间时，将待匹配账号移出任务互动匹配池。

另外，还可以通过定时任务轮询所有匹配池记录，如果超过最大匹配时间，则将待匹配账号从匹配池中移除。

继续参考图1所示，在步骤S130中，若账号已加入任务互动匹配池并且匹配成功，则在匹配成功的双方账号的直播间中创建互动任务。

本示例实施方式中，若主播账号已加入任务互动匹配池并且匹配成功，则根据产品策略创建特殊的直播任务，即互动任务。

本示例实施方式中的一种直播任务的匹配方法还可以包括：根据任务同步时间间隔从任务数据存储系统中获取所有正在进行中的互动记录，并根据互动记录将互动双方账号的任务状态持久化存储在任务数据存储系统中。任务数据存储系统用于存储互动记录、任务值等与互动任务相关的数据。

图4示出了本公开的一个具体实施方式中的账号任务状态同步的时序流程图，该时序流程图具体可以包括以下几个步骤：

步骤S402.获取所有正在进行中的互动记录。

任务PVP服务定时向任务数据存储系统(mysql)获取所有正在进行中的互动记录。

步骤S404.查询互动双方的任务值。

根据互动记录查询任务框架获取PK双方的任务值，其中，PK指的是主播账号之间通过连麦等形式进行互动和任务对战。

步骤S406.持久化任务值。

将PK双方的任务值持久化存储到任务数据存储系统中。

继续参考图1所示，在步骤S140中，根据双方账号在任务结算时间内的任务状态确定任务互动结果，并根据任务互动结果向相应的账号下发任务资源。

本示例实施方式中，如图5所示，根据双方账号在任务结算时间内的任务状态确定任务互动结果，具体可以包括以下几个步骤：

步骤S510.根据任务状态查询时间间隔从任务数据存储系统中获取所有任务互动匹配状态为已匹配状态的互动记录，并查询已匹配状态的互动双方账号是否在任务创建时间内创建互动任务。

通过定时任务轮询所有已匹配状态的记录，向任务框架查询匹配双方的任务创建记录，判断已匹配状态的互动双方账号是否在任务创建时间内创建互动任务。

步骤S520.若任务创建时间内有任意一方账号创建互动任务失败，则将已匹配状态的互动双方账号的互动记录转为废弃。

如果在任务创建时间内有任意一方账号创建互动任务失败，例如关播、断播等，则将互动记录扭转为废弃。

步骤S530.若任务创建时间内互动双方账号均成功创建互动任务，则将已匹配状态的互动双方账号的任务互动匹配状态转为互动中状态。

如果在任务创建时间内互动双方账号均创建成功，则将互动记录扭转为互动中状态。

步骤S540.从任务数据存储系统中获取所有任务互动匹配状态为互动中状态的互动记录，并查询互动中状态的互动双方账号的任务状态。

通过任务PVP服务定时向任务数据存储系统获取所有正在进行中的互动记录，并根据互动记录查询任务框架获取互动双方账号的任务状态。

步骤S550.在任务结算时间内，根据互动中状态的互动双方账号的任务状态确定任务互动结果。

本示例实施方式中，如图6所示，在任务结算时间内，根据互动中状态的互动双方账号的任务状态确定任务互动结果，具体可以包括以下几个步骤：

步骤S610.在任务结算时间内，若互动中状态的互动双方账号中的任意一个账号的任务状态为已完成状态，并且另一个账号的任务状态为未完成状态，则将已完成状态的账号的任务状态更新为已获胜状态。

在任务结算时间内，如果一方先完成了任务，则更新对局为一方获胜并持久化。

步骤S620.在任务结算时间内，若互动中状态的互动双方账号任务状态同时转换为已完成状态，则将互动双方账号的任务状态都更新为已获胜状态。

在任务结算时间内，如果双方同时完成了任务，则更新双方都获胜并持久化。

步骤S630.在任务结算时间内，若互动中状态的互动双方账号的任务状态均为未完成状态，则不进行任何处理。

在任务结算时间内，如果双方均未完成，则不做处理，双方继续完成任务。

步骤S640.在任务结算时间结束时，若互动中状态的互动双方账号的任务状态均为未完成状态，则将互动双方账号的任务状态都更新为任务失败状态。

如果超出任务结算时间，双方均未完成，则直接将记录更新为双方都失败并持久化。

最后，通过定时任务轮询所有已结束的记录，根据产品策略进行具体的任务资源的下发。下发成功时将记录扭转为已归档。

图7示出了本公开的一个具体实施方式中的互动结算条件判定的时序流程图，该时序流程图具体可以包括以下几个步骤：

步骤S702.获取所有正在进行中的互动记录。

任务PVP服务定时向数据库获取所有正在进行中的记录。

步骤S704.查询互动双方的任务值。

根据互动记录查询任务框架获取PK双方的任务状态。

步骤S706.不做处理。

如果AB双方均未完成，则不做处理。

步骤S708.更新A获胜。

如果一方先完成了任务，则更新对局为一方获胜并持久化。

步骤S710.更新双方都获胜。

如果双方都完成了任务，则更新双方都获胜并持久化。

步骤S712.获取所有超出结算时间的互动记录。

任务PVP服务定时向数据库获取所有超出结算时间的记录。

步骤S714.更新为双方都失败。

对于超出结算时间的互动记录，直接将记录更新为双方都失败并持久化。

如图8所示是本公开的一个具体实施方式中的直播任务的匹配方法的原理框图，是对本示例实施方式中的上述步骤的举例说明，该框图主要包括4个模块：主播任务模块801、主播任务与任务PVP联动模块802、匹配模块803和任务PVP模块804。

主播任务模块801以主播任务为载体，不同的主播任务系统实现大同小异，但总体上可归纳总结为以下环节：任务创建、任务进行、任务结算、任务奖励。具体如下：

1、任务创建

通过定时任务轮询所有直播间，并查询直播间对应的任务状态：当单个直播间的任务尚未创建、任务已完成、任务已过期时，根据具体产品策略选择合适的时间创建任务。常用的策略有固定时间范围内容重复创建任务；固定周期内仅创建有限次任务；整个周期内仅创建有限次任务等。

2、任务进行

通过消费礼物消息、点赞消息、评论消息等直播间基础互动消息，按照具体产品策略将消息转化为一定比例的分数，持久化存储为主播任务值。

3、任务结算

通过定时任务轮询所有直播间，并查询直播间对应的任务状态，根据主播任务的任务值和时间配置进行结算：如果在有效时间内任务值达到目标值，则将任务标记为任务完成，并发送任务完成消息；如果任务值没有达成目标值但时间耗尽，则将任务标记为任务失败，并发送任务失败消息；如果任务值没有达成目标值但时间未耗尽，则不做任务处理。

4、任务奖励

接收任务完成或任务失败的消息，根据消息中携带的任务细节信息，结合具体产品策略进行资源下发。

主播任务与任务PVP联动模块802在主播任务的基础上，扩展了主播任务的生命周期，并与PK对局的生命周期进行联动，包括主播状态检查、主播任务分数同步、对决结算条件检查。如图9所示是本公开的一个具体实施方式中的主播任务与任务PVP联动模块802的时序流程图，该流程图的具体步骤如下：

步骤S902.获取所有开播中的主播。

对任务框架的任务创建模块进行扩展，任务创建任务查询所有开播中的主播。

步骤S904.获取所有未开始/已完成/已过期的任务。

获取主播当前的任务状态(未开始/已完成/已过期)。

步骤S906.更新任务PVP状态。

查询任务PVP服务获取任务PVP状态。

步骤S908.读取任务PVP状态。

步骤S910.返回需要等待。

步骤S912.不做处理等待下次任务执行。

如果任务PVP状态是上一局PVP存在且结算中，则任务创建任务不做处理，等待下一次任务扫描处理。

步骤S914.检查主播参与条件。

如果任务PVP状态是上一局PVP不存在或已结算，则检查主播参与条件。

步骤S916.返回可以创建任务。

步骤S918.根据产品策略创建任务。

如果主播不满足参与条件，任务创建任务根据产品策略创建普通的主播任务。

步骤S920.检查当前任务的匹配状态。

如果主播满足参与条件，则检查当前任务的匹配状态。

步骤S922.加入匹配池。

步骤S924.返回需要等待。

步骤S926.不做处理等待下次任务执行。

如果当前任务尚未加入匹配池，则任务PVP服务调用匹配池服务，将主播任务加入匹配池，任务创建任务不做处理等待下次任务执行。

步骤S928.返回需要等待。

步骤S930.不做处理等待下次任务执行。

如果当前任务已加入匹配池且匹配未超时，则任务创建任务不做处理，等待下一次任务扫描处理。

步骤S932.返回可以创建任务。

步骤S934.根据产品策略创建任务。

如果当前任务已加入匹配池且匹配已超时，则任务创建任务根据产品策略创建普通的主播任务。

步骤S936.返回可以创建任务。

步骤S938.根据产品策略创建任务。

如果当前任务已加入匹配池且匹配成功，则任务创建任务根据产品策略创建特殊的主播任务。

匹配模块803包括策略匹配、加入匹配池和清理超时主播。如图10所示是本公开的一个具体实施方式中的匹配模块803的时序流程图，该流程图的具体步骤如下：

步骤S1002.加入匹配池接口。

任务PVP服务调用加入匹配池接口。

步骤S1004.根据产品策略获取匹配策略上下文。

匹配池服务根据产品策略获取匹配策略上下文(如观众在线人数、任务执行能力、任务完成数等)。

步骤S1006.分片。

匹配池服务根据主播id分shard。

步骤S1008.存储匹配策略上下文和加入匹配池。

将匹配池策略上下文使用kv结构存储redis，将主播使用zset存储redis。

步骤S1010.获取匹配池中的主播和匹配策略上下文。

在活动时间内，匹配任务定时从redis中获取匹配时间内的主播以及任务对应的策略上下文。

步骤S1012.根据产品策略进行匹配。

根据产品策略按照加入匹配池的顺序为主播匹配对手。

步骤S1014.初始化匹配记录。

如果匹配成功，则将匹配双方初始化一条已匹配状态的互动记录。

步骤S1016.匹配双方移出匹配池。

如果匹配失败，则不做任何处理，等待下次匹配任务执行。

步骤S1018.移除超出匹配时间的主播。

通过定时任务轮询所有匹配池记录，如果超过最大匹配时间，则将记录从匹配池中移除。

任务PVP模块804以主播任务为PK单位，任务率先完成一方视为PK获胜，包括PK对局创建、PK对局结算和PK对局奖励。如图11所示是本公开的一个具体实施方式中的任务PVP模块804的时序流程图，该流程图的具体步骤如下：

步骤S1102.初始化匹配记录。

由匹配模块的匹配任务初始化PK记录视为创建了一场PK对局。

步骤S1104.获取所有状态为已匹配的记录。

通过定时任务轮询所有已匹配状态的记录。

步骤S1106.查询匹配双方的任务创建记录。

向任务框架查询匹配双方的任务创建记录。

步骤S1108.扭转为PK中。

如果在兜底时间内创建成功，则将记录扭转为PK中状态。

步骤S1110.扭转为废弃。

如果在兜底时间内双方均没有创建成功(关播、断播等)，则将记录扭转为废弃。

步骤S1112.获取所有状态为PK中的记录。

步骤S1114.查询匹配双方的任务进度。

步骤S1116.扭转为失败平局。

步骤S1118.扭转为A获胜。

步骤S1120.扭转为胜利平局。

步骤S1122.获取所有状态为已结束的记录。

步骤S1124.根据产品策略下发资源奖励。

通过定时任务轮询所有已结束的记录，根据产品策略进行具体资源的下发。

步骤S1126.扭转为已归档。

下发成功时将记录扭转为已归档。任务互动状态的转换示意图如图12所示。

应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

需要说明的是，本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)，均为经用户授权或者经过各方充分授权的信息。

进一步的，本公开还提供了一种直播任务的匹配装置。参考图13所示，该直播任务的匹配装置可以包括参与条件确定模块1310、匹配状态获取模块1320、互动任务创建模块1330以及互动结果确定模块1340。其中：

参与条件确定模块1310被配置为针对所有处于开播状态的账号，获取账号的任务状态，并确定账号是否满足任务互动参与条件；

匹配状态获取模块1320被配置为在账号满足任务互动参与条件时，获取账号在任务互动匹配池中的任务互动匹配状态；

互动任务创建模块1330被配置为若账号已加入任务互动匹配池并且匹配成功，则在匹配成功的双方账号的直播间中创建互动任务；

互动结果确定模块1340被配置为根据双方账号在任务结算时间内的任务状态确定任务互动结果，并根据任务互动结果向相应的账号下发任务资源。

在本公开的一些示例性实施例中，参与条件确定模块1310可以包括任务互动状态获取单元、互动参与条件判断单元以及普通账号任务创建单元。其中：

任务互动状态获取单元，被配置为从账号数据存储系统中获取账号的任务互动状态，并根据账号的任务互动状态判断账号是否处于上一局互动任务中；

互动参与条件判断单元被配置为若上一局互动任务不存在或者已结算，则判断账号是否满足任务互动参与条件；

普通账号任务创建单元被配置为若账号不满足任务互动参与条件，则在账号的直播间中创建普通任务。

在本公开的一些示例性实施例中，匹配状态获取模块1320可以包括待匹配账号获取单元、互动账号匹配单元、互动记录创建单元、匹配任务等待单元以及超时账号移除单元。其中：

待匹配账号获取单元被配置为根据预设的匹配时间间隔，从账号数据存储系统获取任务互动匹配池中的待匹配账号以及相应的匹配策略；

互动账号匹配单元被配置为根据匹配策略，按照待匹配账号加入任务互动匹配池中的顺序，为待匹配账号匹配相应的互动账号；

互动记录创建单元被配置为若匹配成功，则将双方账号移出任务互动匹配池，将双方账号的任务互动匹配状态初始化为已匹配状态，并创建双方账号的互动记录；

匹配任务等待单元被配置为若匹配失败，则不对待匹配账号进行任何处理，并等待下次匹配任务的执行；

超时账号移除单元被配置为当待匹配账号在任务互动匹配池中的存留时长超过最大匹配时间时，将待匹配账号移出任务互动匹配池。

在本公开的一些示例性实施例中，本公开提供的一种直播任务的匹配装置还可以包括任务状态持久化存储模块，被配置为根据任务同步时间间隔从任务数据存储系统中获取所有正在进行中的互动记录，并根据互动记录将互动双方账号的任务状态持久化存储在任务数据存储系统中。

在本公开的一些示例性实施例中，互动结果确定模块1340可以包括任务创建状态查询单元、互动记录废弃单元、互动中状态转换单元、互动中记录查询单元以及任务互动结果确定单元。其中：

任务创建状态查询单元被配置为根据任务状态查询时间间隔从任务数据存储系统中获取所有任务互动匹配状态为已匹配状态的互动记录，并查询已匹配状态的互动双方账号是否在任务创建时间内创建互动任务；

互动记录废弃单元被配置为若任务创建时间内有任意一方账号创建互动任务失败，则将已匹配状态的互动双方账号的互动记录转为废弃；

互动中状态转换单元被配置为若任务创建时间内互动双方账号均成功创建互动任务，则将已匹配状态的互动双方账号的任务互动匹配状态转为互动中状态；

互动中记录查询单元被配置为从任务数据存储系统中获取所有任务互动匹配状态为互动中状态的互动记录，并查询互动中状态的互动双方账号的任务状态；

任务互动结果确定单元被配置为在任务结算时间内，根据互动中状态的互动双方账号的任务状态确定任务互动结果。

在本公开的一些示例性实施例中，任务互动结果确定单元可以包括获胜账号确定单元、平局互动确定单元、未完成状态持续单元以及失败状态确定单元。其中：

获胜账号确定单元被配置为在任务结算时间内，若互动中状态的互动双方账号中的任意一个账号的任务状态为已完成状态，并且另一个账号的任务状态为未完成状态，则将已完成状态的账号的任务状态更新为已获胜状态；

平局互动确定单元被配置为在任务结算时间内，若互动中状态的互动双方账号任务状态同时转换为已完成状态，则将互动双方账号的任务状态都更新为已获胜状态；

未完成状态持续单元被配置为在任务结算时间内，若互动中状态的互动双方账号的任务状态均为未完成状态，则不进行任何处理；

失败状态确定单元被配置为在任务结算时间结束时，若互动中状态的互动双方账号的任务状态均为未完成状态，则将互动双方账号的任务状态都更新为任务失败状态。

上述直播任务的匹配装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明，此处不再赘述。

图14示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图14示出的电子设备的计算机系统1400仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图14所示，计算机系统1400包括中央处理单元(CPU)1401，其可以根据存储在只读存储器(ROM)1402中的程序或者从存储部分1408加载到随机访问存储器(RAM)1403中的程序而执行各种适当的动作和处理。在RAM 1403中，还存储有系统操作所需的各种程序和数据。CPU1401、ROM 1402以及RAM 1403通过总线1404彼此相连。输入/输出(I/O)接口1405也连接至总线1404。

以下部件连接至I/O接口1405：包括键盘、鼠标等的输入部分1406；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1407；包括硬盘等的存储部分1408；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1409。通信部分1409经由诸如因特网的网络执行通信处理。驱动器1410也根据需要连接至I/O接口1405。可拆卸介质1411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1410上，以便于从其上读出的计算机程序根据需要被安装入存储部分1408。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1409从网络上被下载和安装，和/或从可拆卸介质1411被安装。在该计算机程序被中央处理单元(CPU)1401执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。