技术领域
[0001] 本申请涉及视频推送技术领域，尤其涉及一种推送视频的回收方法、装置、电子设备和存储介质。
相关背景技术
[0002] 目前视频都是基于用户偏好进行推送，一般来说，为了保证用户体验，一次视频的推送数量大于终端屏幕上的展示数量，这导致用户没有看到的视频实际上已经被记录在推荐历史数据库中，而下次访问时，推荐历史数据库中的数据不会再推送给用户，这导致已经给用户推送、但用户未看过的视频会被过滤掉，造成视频资源浪费。
具体实施方式
[0047] 为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0048] 在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本申请的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。
[0049] 为了解决背景技术中提及的问题，根据本申请实施例的一方面，提供了一种推送视频的回收方法的实施例。
[0050] 可选地，在本申请实施例中，上述推送视频的回收方法可以应用于如图1所示的由终端101和服务器103所构成的硬件环境中。如图1所示，服务器103通过网络与终端101进行连接，可用于为终端或终端上安装的客户端提供服务，可在服务器上或独立于服务器设置数据库105，用于为服务器103提供数据存储服务，上述网络包括但不限于：广域网、城域网或局域网，终端101包括但不限于PC、手机、平板电脑等。
[0051] 本申请实施例提供了一种推送视频的回收方法，可以应用于服务器，用于避免造成视频资源浪费。
[0052] 下面将结合具体实施方式，对本申请实施例提供的一种推送视频的回收方法进行详细的说明，如图2所示，具体步骤如下：
[0053] 步骤201：获取推荐日志数据流和多个终端发送的已展示数据流，并获取多个终端检测到的第二未展示数据；
[0054] 步骤202：根据推荐日志数据流和已展示数据流确定第一未展示数据；
[0055] 步骤203：确定第一未展示数据和第二未展示数据的交集数据，其中，交集数据包括视频的推送批次和用户id；
[0056] 步骤204：若交集数据存在于推荐历史库中，则从推荐历史库中删除交集数据，以将推送批次中的视频重新推送给用户id对应的用户，其中，推荐历史库中的视频不再推荐给相应用户。
[0057] 后台服务器会根据用户偏好给用户推荐视频，包括但不限于长视频、热门视频、短视频等，服务台在推送视频时会产生推荐日志数据流，推荐日志数据流中包括了每一次推荐的日志，单条日志中包括推送给多个用户的一批视频。
[0058] 后台推送给终端的视频往往大于终端界面能够显示的视频，那么用户在终端上能够看到的视频只是部分视频，这样就造成另外一部分视频已推送给用户但用户并未看到，造成视频资源浪费。而终端会自己将推送的视频分流，用户能够看到的视频归入已展示视频流，用户未能看到的视频归入未展示视频数据。
[0059] 无论是推荐日志数据流还是已展示数据流，都属于后台的实时数据流，一般来说，后台可以从推荐日志数据流将已展示数据流筛选出去，剩下的即为用户未看到的视频数据(第一未展示数据)，但数据从终端传输到服务器的过程中，可能会受到网络波动、信号干扰等不稳定因素的影响，数据流中的数据有丢失风险，采用这种方式得到的第一未展示数据是不够准确的。
[0060] 终端自动将视频分流后得到第二未展示数据，第二未展示数据是由终端检测出来的，结果比较可靠，若简单的将第二未展示数据中的视频重新发送给用户，视频回传的通路同样会有丢失风险，造成回收不准确。
[0061] 针对后台的实时数据流和终端检测到的未展示数据流均有丢失风险的基础上，本申请将根据实时数据流得到的第一未展示数据和终端检测到的第二未展示数据取交集，得到的交集数据包括视频的推送批次evid和用户id，本申请实施例中，默认每个用户id对应一个终端id。一般来说，一批推送的视频具有相同的推送批次，如果视频丢失是该推送批次中的视频全部丢失，不会出现同一推送批次中的部分视频丢失的情况。因此，第一未展示数据和第二未展示数据取交集时，只需要根据推送批次和用户id取交集即可，这样得到的交集数据同时存在于实时数据流和终端，那么该交集数据是准确的。
[0062] 推荐历史库中包括多个已推送的视频，那么存在于推荐历史库中的视频不会再推荐给相应用户，为了能够将已推送给用户但用户未看过的视频重新推送给用户，需要将这些视频从推荐历史库中删除，因此，服务器判断上述得到的交集数据是否存在于推荐历史库中，若存在，则将从推荐历史库中删除交集数据，从而将推送批次中的视频重新推送给用户id对应的用户，实现推送视频的回收；若不存在，则回到步骤201。
[0063] 由于第一未展示数据和第二未展示数据都可能受到不稳定因素的影响，直接使用其中任何一种数据进行视频回收都可能存在风险。通过将两种数据取交集，可以确保得到的交集数据同时存在于实时数据流和终端检测中，从而降低因数据丢失或错误而导致的风险。取交集后的数据准确性更高，因为它经过了双重验证。一方面，它存在于后台的实时数据流中，说明这些视频确实被推送过；另一方面，它也存在于终端检测到的未展示数据中，说明这些视频是用户未看过的，这种双重验证机制大大降低了数据丢失或错误的可能性。
[0064] 本申请中，一方面通过推荐日志数据流和已展示数据流确定实时数据流中的未展示数据，另一方面获取终端检测到的未展示数据，通过对两种未展示数据取交集，保证已给用户推送过的、且用户未看过的视频数据是准确的，最后将推荐历史库中的交集数据删除，从而将该用户未看到过的推荐视频重新推送给用户，本申请通过三方数据的融合实现准确的视频数据回收，避免视频资源的浪费。
[0065] 在步骤202中，根据推荐日志数据流和已展示数据流确定第一未展示数据包括如下内容：确定已展示数据流中的目标数据记录，其中，目标数据记录包括目标推送批次、目标用户id和已展示视频id；在推荐日志数据流中查找目标推送批次和目标用户id对应的推送视频id；将推送视频id中除已展示视频id的之外的视频id作为未展示视频id；根据目标推送批次、目标用户id和未展示视频id作为第一未展示数据中的一条数据记录；遍历已展示数据流中的全部数据记录，并生成第一未展示数据中的多条数据记录。
[0066] 推荐日志数据流和已展示数据流中均包括多条数据记录，每条数据记录中的内容包括：推送批次、用户id以及至少一条视频id，不同的是，推荐日志数据流中是推送视频id，已展示数据流中是已展示视频id。即推荐日志数据流的数据记录包括：推送批次、用户id以及推送视频id，已展示数据流的数据记录包括：推送批次、用户id以及已展示视频id。
[0067] 服务器遍历已展示数据流中的每条数据记录，具体来说，将任意一条数据记录作为目标数据记录，那么目标数据记录的内容包括：目标推送批次、目标用户id和已展示视频id。然后，服务器在推荐日志数据流中搜索与目标推送批次和目标用户id相匹配的推送视频id，这一步骤的目的是找出该用户在此批次推送中可能看过的所有视频。服务器从获取的推送视频id中，排除那些已经被用户观看过的视频id(即已展示视频id)，这样可以识别出哪些视频尚未被用户观看，即未展示视频id。对于每个目标推送批次、目标用户id和未展示视频id的组合，将它们作为一条新的数据记录添加到第一未展示数据中。最后，遍历整个已展示数据流，重复上述过程，以便为每个目标推送批次和目标用户id生成对应的未展示视频id。这样就可以得到一个全面的、反映用户未观看视频情况的数据集。
[0068] 通过遍历已展示数据流并结合推荐日志数据流，服务器能够准确识别出哪些视频是用户尚未观看的，确保了数据集的完整性和准确性，因为每个目标推送批次和目标用户id的组合都被详细考虑，从而避免了遗漏任何潜在的未观看视频。通过这一系列的步骤，可以根据实时数据流确定已给用户推送、但用户未观看的视频数据。
[0069] 在步骤203中，获取多个终端检测到的第二未展示数据包括如下内容：：获取每个终端发送的http消息；解析http消息得到一条解析记录，其中，每条解析记录包括视频的推送批次、用户id以及场景标识；若根据场景标识确定解析记录中的视频允许回收，则将解析记录写入队列。
[0070] 当终端检测到界面上未展示的视频数据时，它会发送一个HTTP消息至服务器，服务器接收到这个HTTP消息后，会对其进行解析，从中提取出适用于该终端的一条解析记录，这条解析记录包含了视频的推送批次、用户id以及场景标识。
[0071] 场景标识是一个重要的信息，它用于指示视频内容是否支持回收。如果视频内容不支持回收，例如冷门视频或展示期限已超期的视频，那么在处理第二未展示数据时，服务器会丢弃这条解析记录，这样做可以避免在后续计算中产生与这些不支持回收的视频内容相关的交集数据，从而减少不必要的计算量。
[0072] 然而，如果根据场景标识确定视频内容支持回收，那么服务器会将这条解析记录写入队列，这个队列是一个临时存储区域，用于保存待处理的解析记录。后续服务器会从队列中取出这条解析记录，并与实时数据流中的第一未展示数据进行比较，取它们的交集。通过这种方式，可以判断该解析记录是否既存在于终端检测的第二未展示数据中，也存在于实时数据流中的第一未展示数据中。
[0073] 这种处理方式确保了只有支持回收的视频内容才会被纳入考量，从而提高了系统的处理效率和准确性，同时，它也避免了将不支持回收的视频内容错误地纳入推荐范围，保证了用户体验的质量。
[0074] 本申请实施例中的队列可以为kafka队列，也可以为Pulsar提供的队列，本申请对消息队列类型不做限制。
[0075] 其中，视频回收指的是将之前推送给用户但未被观看的视频重新纳入推荐池中，以便在未来有机会再次推荐给用户。是否允许某个视频回收取决于多种因素，包括视频的热门程度、用户的观看历史、视频的新鲜度等。以下是一些可能影响视频回收决策的因素：
[0076] 视频的热门程度：热门视频通常有更高的观看概率，因此即使用户之前没有观看，也可能会允许这些视频回收，以便抓住用户可能改变兴趣的机会。
[0077] 用户的观看历史：如果用户对某类内容表现出持续的兴趣，那么即使他们之前没有观看某些视频，这些视频也可能被允许回收。相反，如果用户明确表示对某些类型的内容不感兴趣，那么这些视频可能不会被回收。
[0078] 视频的新鲜度：新发布的视频可能有更高的优先级，因为它们更有可能是用户感兴趣的内容。因此，即使是热门视频，如果它们已经存在一段时间，可能也不允许回收，以给新内容腾出空间。
[0079] 用户反馈：用户的直接反馈(如点赞、评论、分享)可以作为是否允许视频回收的重要依据。如果用户对某个视频有积极的互动，即使他们之前没有观看，这个视频也可能被允许回收。
[0080] 推荐策略：不同的推荐系统可能有不同的推荐策略。有些系统可能更倾向于推荐新内容，而有些则可能更注重个性化和用户的历史偏好。
[0081] 商业考虑：有时，商业目标也会影响视频回收的决策。例如，如果某个视频与即将到来的广告活动相关，即使它不是热门视频，也可能会被允许回收以增加曝光率。
[0082] 作为一种可选的实施方式，确定第一未展示数据和第二未展示数据的交集数据之前，方法还包括：确定第一未展示数据最后一次产生数据记录的最终时刻，其中，第一未展示数据每隔设定时段产生数据记录；确定最终时刻与当前系统时刻之间的间隔时长；若间隔时长未超过时长阈值，则确定推荐日志数据流和已展示数据流的数据流无异常。
[0083] 在服务器对第一未展示数据和第二未展示数据进行交集操作之前，它需要通过一个名为mark校验的过程来确保数据流的正常运行，这个过程对于保证视频回收流程的准确性至关重要。
[0084] Mark校验的具体步骤如下：
[0085] 1.定期查找：服务器会定期在推荐日志数据流中查找已展示数据流中的数据内容，每当查找到一个匹配的数据时，就会在第一未展示数据中产生一条新的数据记录。
[0086] 2.获取第二未展示数据：当服务器从队列中获取到第二未展示数据后，它会确定当前的系统时刻，并找出第一未展示数据最后一次产生数据记录的时间点。
[0087] 3.计算间隔时长：接着，服务器会计算当前系统时刻与第一未展示数据最后一次产生数据记录的时间点之间的间隔时长。
[0088] 4.判断间隔时长：如果这个间隔时长没有超过预设的时长阈值，那么可以认为数据流是正常的，则正常执行两种未展示数据之间取交集的操作；反之，如果超过了时长阈值，则表明数据流异常，为了避免错误的回收行为，服务器会中断整个视频回收流程。
[0089] 举例来说，假设有一个视频推荐系统，它会不断地向用户推送新视频。为了确保用户体验，系统会记录哪些视频已经被推送过(推荐日志数据流)，同时系统获取终端发送的已展示数据流和检测到的第二未展示数据，系统定期在推荐日志数据流中查找已展示数据流，每查找到一条数据则生成第一未展示数据中的一条数据记录。
[0090] 在这个场景中，服务器可能会定期检查已展示数据流，比如每30秒检查一次。如果在最近半分钟内有10个视频被标记为已展示，那么这10个视频的信息就会被添加到第一未展示数据中作为新的未展示记录。随后，服务器会比较这些新记录与第二未展示数据中的视频id，找出那些既在第一未展示数据中也存在、又出现在第二未展示数据中的视频id集合。这个集合就是可能适合回收的视频列表。
[0091] 然而，在进行这一过程之前，服务器必须通过mark校验来确认数据流的状态。假设时长阈值设定为31秒，即服务器期望至少每隔31秒就能在已展示数据流中找到新的已展示视频记录。如果在连续两次mark校验之间，间隔时长超过了31秒，那么服务器就会认为数据流出现了异常，可能是由于网络延迟、系统故障或其他原因导致的数据传输问题。在这种情况下，服务器将不会执行任何视频回收操作，而是先解决数据流的问题，确保数据的完整性和准确性。
[0092] 作为一种可选的实施方式，将解析记录写入队列包括：将解析记录写入延迟队列，其中，延迟队列中的延迟时长大于推荐日志数据流和第一未展示数据流的延迟时长。
[0093] 在视频回收流程中，当服务器解析出一条适用于终端的解析记录后，这条记录会被写入一个特殊的队列，即延迟队列。延迟队列的特点是，它不会立即处理这些记录，而是会等待一段预设的时间(即延迟时长)后再进行处理。重要的是，这个延迟时长需要大于推荐日志数据流和第一未展示数据流之间的延迟时长。
[0094] 推荐日志数据流和第一未展示数据流之间的延迟时长主要源于以下几个方面：
[0095] 数据处理与传输时间：从用户观看视频到该信息被记录在推荐日志数据流中，以及从这些日志数据被处理并生成第一未展示数据，都需要一定的时间。这包括了数据的收集、传输、存储和处理等多个环节。每个环节都可能引入一定的延迟。
[0096] 系统负载与性能：在高并发的情况下，系统的负载会增加，可能导致数据处理速度变慢，从而增加延迟时长。此外，如果系统性能不足，也可能导致数据处理和传输的效率降低。
[0097] 网络状况：网络延迟也是导致推荐日志数据流和第一未展示数据流之间存在延迟的一个重要原因。在数据传输过程中，可能会受到网络拥堵、丢包等因素的影响，导致数据无法及时到达服务器。
[0098] 为了确保视频回收流程的准确性和有效性，需要将解析记录写入延迟队列，并设置一个足够长的延迟时长。这样，即使推荐日志数据流和第一未展示数据流之间存在延迟，也能确保在处理这些记录时，相关的数据已经全部到达服务器，并且已经被正确处理。这种设计能够提高系统的容错性和稳定性，减少因数据不一致或缺失而导致的错误操作。
[0099] 作为一种可选的实施方式，获取多个终端发送的已展示数据流之后，方法还包括：若已展示数据流的至少一条数据记录中缺乏视频id，则确定数据记录丢失，并中断视频回收流程。
[0100] 在视频回收流程中，服务器会收集来自多个终端的已展示数据流，这些数据流对于确定哪些视频已经被用户观看过至关重要，因为它们直接影响到视频回收的准确性和效率。当服务器获取到这些已展示数据流之后，它会对这些数据流进行综合分析和处理。在这个过程中，如果发现至少一条已展示数据记录中缺乏关键的视频id信息，那么服务器会采取一个重要的决策‑‑确定这条数据记录丢失，并中断整个视频回收流程。
[0101] 这种处理方式的效果是多方面的。首先，它能够确保视频回收流程的准确性和可靠性。视频id是识别视频的唯一标识符，如果数据记录中缺乏视频id，那么服务器无法准确判断该视频是否已经被用户观看过，也就无法确定该视频是否适合回收，在这种情况下，继续执行视频回收流程可能会导致错误的操作，比如将已经被用户观看过的视频再次推荐给用户，从而降低用户体验，因此，通过中断视频回收流程，服务器可以避免这种潜在的错误操作，保护用户体验。
[0102] 其次，这种处理方式还有助于及时发现和解决系统中的问题，如果数据记录中缺乏视频id是由于系统故障、网络问题或其他原因导致的，那么中断视频回收流程可以促使相关人员尽快排查和解决问题，恢复系统的正常运行，这有助于维护系统的稳定性和可靠性，确保后续的视频回收流程能够顺利进行。
[0103] 综上，当服务器获取到多个终端发送的已展示数据流后，若发现至少一条数据记录中缺乏视频id，则确定该数据记录丢失并中断视频回收流程是一种有效的处理方式，它能够确保视频回收流程的准确性和可靠性，同时及时发现和解决系统中的问题，保障用户体验和系统的稳定运行。
[0104] 综上，当服务器获取到多个终端发送的已展示数据流后，若发现已展示数据流中没有数据记录，则确定已展示数据丢失并中断视频回收流程是一种有效的处理方式。它能够确保视频回收流程的准确性和可靠性，同时及时发现和解决系统中的问题，保障用户体验和系统的稳定运行。
[0105] 图3为本申请提供的一种推送视频回收的系统流程示意图。包括如下步骤：
[0106] 步骤S1：系统在给多个用户推送视频时生成推荐日志数据流，推荐日志数据流中的每条数据记录包括：推送批次evid、用户id以及推送视频id(图3中的feed表示视频id，即feed1、feed2分别表示视频id1、视频id2，以此类推)，系统将推荐日志数据流写入show_data数据库并保存。
[0107] 步骤S2：客户端根据接收到的视频数据和界面展示的视频数据，区分出已展示数据流中和第二未展示数据，已展示数据流的每条数据记录包括：推送批次、用户id以及已展示视频id，第二未展示数据的每条数据记录包括：推送批次和用户id。
[0108] 步骤S3：已展示数据流写入并更新show_data数据库，更新逻辑：已展示视频从数据库中查询到一批推荐结果的批次号evid和用户id，设置该批次数据(数据记录)的展示状态为真，同时将同一批次未展示过的视频放入可回收列表中，供在线服务读取，每收到一个已展示视频重复以上过程。
[0109] 具体过程为：在推荐日志数据流中搜索与已展示数据流中目标推送批次、目标用户id相匹配的推送视频id，从获取的推送视频id中排除那些已经被用户观看过的视频id(即已展示视频id)，这样可以识别出哪些视频尚未被用户观看，即未展示视频id，得到第一未展示数据中的一条数据记录：目标推送批次、目标用户id和未展示视频id。遍历已展示数据流中的每条数据记录，从而得到第一未展示数据中的多条数据记录。
[0110] 步骤S4：客户端根据第二未展示数据发送http消息至服务器，服务器解析出视频的推送批次和用户id，然后进行基础校验，基础校验是指根据场景标识校验视频内容是否支持回收，如果支持回收则执行后续步骤，如果不支持回收则丢弃该解析记录。
[0111] 步骤S5：解析出的第二未展示数据保存至延迟队列，然后消费该数据。
[0112] 步骤S6：通过mark校验确定数据流是否正常运行，如果数据流异常，则中断视频回流；如果数据流正常，则继续执行以下步骤。
[0113] 步骤S7：第一未展示数据和第二未展示数据根据推送批次和目标用户id取交集数据。
[0114] 步骤S8：msg_list判断(交集数据是否存在于推荐历史库中)，若是，执行步骤S9，若否，执行步骤S10。
[0115] 步骤S9：若交集数据存在于推荐历史库中，则更新推荐历史库，即从推荐历史库中删除交集数据。
[0116] 步骤S10：结合推荐历史库，将已给用户推送过、但用户未看过的视频重新推送给用户。
[0117] 本申请通过将已给用户推送过、但用户未看过的视频重新推送给用户，避免了用户可能喜欢的视频没有展示就被过滤，提高用户体验感，也避免视频资源浪费。
[0118] 在回收过程中执行最严格的校验机制，只要校验不通过就可以放弃回收。这种机制可以有效地控制风险，避免因为数据错误而导致的线上服务问题。同时，由于三份数据之间存在一定的冗余性和互补性，即使其中一份数据出现问题，也可以通过其他两份数据进行校验和修正，降低数据丢失的风险。
[0119] 基于相同的技术构思，本申请实施例还提供了一种推送视频的回收装置，如图4所示，该装置包括：
[0120] 获取模块401，用于获取推荐日志数据流和多个终端发送的已展示数据流，并获取多个终端检测到的第二未展示数据；
[0121] 第一确定模块402，用于根据推荐日志数据流和已展示数据流确定第一未展示数据；
[0122] 第二确定模块403，用于确定第一未展示数据和第二未展示数据的交集数据，其中，交集数据包括视频的推送批次和用户id；
[0123] 推送模块404，用于若交集数据存在于推荐历史库中，则从推荐历史库中删除交集数据，以将推送批次中的视频重新推送给用户id对应的用户，其中，推荐历史库中的视频不再推荐给相应用户。
[0124] 可选地，第一确定模块402用于：
[0125] 确定已展示数据流中的目标数据记录，其中，目标数据记录包括目标推送批次、目标用户id和已展示视频id；
[0126] 在推荐日志数据流中查找目标推送批次和目标用户id对应的推送视频id；
[0127] 将推送视频id中除已展示视频id的之外的视频id作为未展示视频id；
[0128] 根据目标推送批次、目标用户id和未展示视频id作为第一未展示数据中的一条数据记录；
[0129] 遍历已展示数据流中的全部数据记录，并生成第一未展示数据中的多条数据记录。
[0130] 可选地，获取模块401用于：
[0131] 获取每个终端发送的http消息；
[0132] 解析http消息得到一条解析记录，其中，每条解析记录包括视频的推送批次、用户id以及场景标识；
[0133] 若根据场景标识确定解析记录中的视频允许回收，则将解析记录写入队列。
[0134] 可选地，该装置还用于：
[0135] 确定第一未展示数据最后一次产生数据记录的最终时刻，其中，第一未展示数据每隔设定时段产生数据记录；
[0136] 确定最终时刻与当前系统时刻之间的间隔时长；
[0137] 若间隔时长未超过时长阈值，则确定推荐日志数据流和已展示数据流的数据流无异常。
[0138] 可选地，该装置还用于：
[0139] 若间隔时长超过时长阈值，则确定推荐日志数据流和已展示数据流中至少一者的数据流异常，并中断视频回收流程。
[0140] 可选地，获取模块401用于：
[0141] 将解析记录写入延迟队列，其中，延迟队列中的延迟时长大于推荐日志数据流和第一未展示数据流的延迟时长。
[0142] 可选地，该装置还用于：
[0143] 若已展示数据流的至少一条数据记录中缺乏视频id，则确定数据记录丢失，并中断视频回收流程。
[0144] 基于相同的技术构思，本发明实施例还提供了一种电子设备，如图5所示，包括处理器501、通信接口502、存储器503和通信总线504，其中，处理器501，通信接口502，存储器503通过通信总线504完成相互间的通信，
[0145] 存储器503，用于存放计算机程序；
[0146] 处理器501，用于执行存储器503上所存放的程序时，实现上述步骤。
[0147] 上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
[0148] 通信接口用于上述电子设备与其他设备之间的通信。
[0149] 存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non‑Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
[0150] 上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field‑Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
[0151] 在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，计算机程序被处理器执行时实现上述任一方法的步骤，包括如下内容。
[0152] 获取推荐日志数据流和多个终端发送的已展示数据流，并获取多个终端检测到的第二未展示数据；
[0153] 根据推荐日志数据流和已展示数据流确定第一未展示数据；确定第一未展示数据和第二未展示数据的交集数据，其中，交集数据包括视频的推送批次和用户id；
[0154] 若交集数据存在于推荐历史库中，则从推荐历史库中删除交集数据，以将推送批次中的视频重新推送给用户id对应的用户，其中，推荐历史库中的视频不再推荐给相应用户。
[0155] 可选地，根据推荐日志数据流和已展示数据流确定第一未展示数据包括：
[0156] 确定已展示数据流中的目标数据记录，其中，目标数据记录包括目标推送批次、目标用户id和已展示视频id；
[0157] 在推荐日志数据流中查找目标推送批次和目标用户id对应的推送视频id；
[0158] 将推送视频id中除已展示视频id的之外的视频id作为未展示视频id；
[0159] 根据目标推送批次、目标用户id和未展示视频id作为第一未展示数据中的一条数据记录；
[0160] 遍历已展示数据流中的全部数据记录，并生成第一未展示数据中的多条数据记录。
[0161] 可选地，获取多个终端检测到的第二未展示数据包括：
[0162] 获取每个终端发送的http消息；
[0163] 解析http消息得到一条解析记录，其中，每条解析记录包括视频的推送批次、用户id以及场景标识；
[0164] 若根据场景标识确定解析记录中的视频允许回收，则将解析记录写入队列。
[0165] 可选地，确定第一未展示数据和第二未展示数据的交集数据之前，方法还包括：
[0166] 确定第一未展示数据最后一次产生数据记录的最终时刻，其中，第一未展示数据每隔设定时段产生数据记录；
[0167] 确定最终时刻与当前系统时刻之间的间隔时长；
[0168] 若间隔时长未超过时长阈值，则确定推荐日志数据流和已展示数据流的数据流无异常。
[0169] 可选地，确定最终时刻与当前系统时刻之间的间隔时长之后，方法还包括：
[0170] 若间隔时长超过时长阈值，则确定推荐日志数据流和已展示数据流中至少一者的数据流异常，并中断视频回收流程。
[0171] 可选地，将解析记录写入队列包括：
[0172] 将解析记录写入延迟队列，其中，延迟队列中的延迟时长大于推荐日志数据流和第一未展示数据流的延迟时长。
[0173] 可选地，获取多个终端发送的已展示数据流之后，方法还包括：
[0174] 若已展示数据流的至少一条数据记录中缺乏视频id，则确定数据记录丢失，并中断视频回收流程。
[0175] 在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一方法。
[0176] 在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
[0177] 需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0178] 以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。
