CN111884843B - 一种消息处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开提供了一种消息处理方法、装置、电子设备及存储介质，其中，该方法包括：响应于从客户端接收消息获取请求，获取客户端上次接收的消息标识和消息序列号；基于客户端上次接收的消息标识，获取针对客户端的最新消息列表，以及基于所述消息序列号获取与最新消息列表对应的最新消息序列号；将最新消息列表和最新消息序列号发送至客户端，并基于客户端上次接收的消息标识、最新消息列表中的消息标识和最新消息序列号，更新客户端的消息拉取日志；基于更新后的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果。

Description

一种消息处理方法、装置、电子设备及存储介质

技术领域

本公开涉及互联网通信技术领域，具体而言，涉及一种消息处理方法、装置、电子设备及存储介质。

背景技术

随着网络技术的发展，逐渐兴起供用户进行互动的实时通信应用场景，比如网络直播场景，该类应用场景依赖于实时消息系统，在实时消息系统中，客户端可以以固定的时间间隔向服务器拉取该服务器存储的最新消息。

但是在实时消息系统中，经常存在消息丢失的问题，即用户无法看到最新消息，在消息丢失后，需要对消息丢失原因及时进行分析，基于具体的消息丢失原因进行维护，因此，如何准确地确定实时消息系统中消息丢失的原因，为亟需解决的问题。

发明内容

本公开实施例至少提供一种消息处理方案，以在实时消息系统中进行消息丢失定位。

第一方面，本公开实施例提供了一种消息处理方法，包括：

响应于从客户端接收消息获取请求，获取所述客户端上次接收的消息标识和消息序列号；

基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表，以及基于所述消息序列号获取与所述最新消息列表对应的最新消息序列号；

将所述最新消息列表和所述最新消息序列号发送至所述客户端，并基于所述客户端上次接收的消息标识、所述最新消息列表中的消息标识和所述最新消息序列号，更新所述客户端的消息拉取日志；

基于更新后的所述消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果。

在一种可能的实施方式中，所述基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表，包括：

在消息存储库中查找与所述客户端匹配的候选消息列表；

基于所述客户端上次接收的消息标识，在所述候选消息列表中获取排序位于所述消息标识之后的最新消息列表。

在一种可能的实施方式中，按照以下步骤更新消息下发日志：

响应于从至少一个客户端接收写入消息，确定所述写入消息对应的消息标识、消息内容和目标接收端信息；

基于所述写入消息对应的消息标识、消息内容和目标接收端信息，将所述写入消息存储至预先构建的消息存储库，并结合存储结果更新消息下发日志。

在一种可能的实施方式中，所述基于更新后的所述客户端的消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果，包括：

响应于从客户端接收消息反馈信息，基于接收到所述消息反馈信息的时刻确定目标检测时间段；

在所述最新更新的消息下发日志中提取与所述目标检测时间段对应的目标消息下发日志，以及在针对所述客户端的更新后的所述消息拉取日志中提取与所述目标检测时间段对应的目标消息拉取日志；

基于所述目标消息下发日志和所述目标消息拉取日志，确定所述客户端丢失的消息标识。

在一种可能的实施方式中，所述基于所述目标消息下发日志和所述目标消息拉取日志，确定所述客户端丢失的消息标识，包括：

比对所述目标消息下发日志和所述目标消息拉取日志中的消息标识，筛选存在所述目标消息下发日志中，且不存在所述目标消息拉取日志中的目标消息标识；

将所述目标消息标识作为所述客户端丢失的消息标识。

在一种可能的实施方式中，所述基于更新后的所述客户端的消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果，还包括：

在确定所述客户端丢失的消息标识后，基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因。

在一种可能的实施方式中，所述基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因，包括：

在所述消息下发日志中，检测与所述丢失的消息标识匹配的存储状态；

在所述存储状态表示存储失败的情况下，确定所述丢失的消息标识对应的丢失原因为存储失败；

在所述存储状态表示存储成功的情况下，基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因。

在一种可能的实施方式中，所述基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因，包括：

在针对所述客户端的消息拉取日志中，查找是否存在与所述丢失消息标识对应的第一日志记录，所述第一日志记录中记录有所述客户端接收到所述丢失消息标识对应的消息；

在确定存在与所述丢失消息标识对应的第一日志记录的情况下，确定所述丢失消息标识对应的丢失原因为所述客户端解析失败；

在确定不存在与所述丢失消息标识对应的第一日志记录的情况下，查找是否存在与所述丢失消息标识对应的第二日志记录，所述第二日志记录中记录有服务器向所述客户端发送所述丢失消息标识对应的消息；

在确定存在与所述丢失消息标识对应的第二日志记录的情况下，确定所述丢失消息标识对应的丢失原因为所述服务器与所述客户端之间的网络传输中断。

在一种可能的实施方式中，所述基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因，还包括：

在确定不存在与所述丢失消息标识对应的第一日志记录和第二日志记录的情况下，获取包含所述丢失消息标识对应时刻所在的设定时长内的待检测消息拉取日志；

检测所述待检测消息拉取日志中包含的消息序列号是否连续；

在确定所述待检测消息拉取日志中包含的消息序列号连续的情况下，确定所述丢失消息标识对应的丢失原因为服务器故障；

在确定所述待检测消息拉取日志中包含的消息序列号不连续的情况下，确定所述丢失消息标识对应的丢失原因为客户端发送的消息获取请求存在消息丢失。

第二方面，本公开实施例提供了一种消息处理装置，包括：

第一获取模块，用于响应于从客户端接收消息获取请求，获取所述客户端上次接收的消息标识和消息序列号；

第二获取模块，用于基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表，以及基于所述消息序列号获取与所述最新消息列表对应的最新消息序列号；

更新模块，用于将所述最新消息列表和所述最新消息序列号发送至所述客户端，并基于所述客户端上次接收的消息标识、所述最新消息列表中的消息标识和所述最新消息序列号，更新所述客户端的消息拉取日志；

确定模块，用于基于更新后的所述消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果。

在一种可能的实施方式中，所述第二获取模块在用于基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表时，包括：

在消息存储库中查找与所述客户端匹配的候选消息列表；

基于所述客户端上次接收的消息标识，在所述候选消息列表中获取排序位于所述消息标识之后的最新消息列表。

在一种可能的实施方式中，所述更新模块还用于按照以下步骤更新消息下发日志：

响应于从至少一个客户端接收写入消息，确定所述写入消息对应的消息标识、消息内容和目标接收端信息；

基于所述写入消息对应的消息标识、消息内容和目标接收端信息，将所述写入消息存储至预先构建的消息存储库，并结合存储结果更新消息下发日志。

在一种可能的实施方式中，所述确定模块在用于基于更新后的所述客户端的消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果时，包括：

响应于从客户端接收消息反馈信息，基于接收到所述消息反馈信息的时刻确定目标检测时间段；

在所述最新更新的消息下发日志中提取与所述目标检测时间段对应的目标消息下发日志，以及在针对所述客户端的更新后的所述消息拉取日志中提取与所述目标检测时间段对应的目标消息拉取日志；

基于所述目标消息下发日志和所述目标消息拉取日志，确定所述客户端丢失的消息标识。

在一种可能的实施方式中，所述确定模块在用于基于所述目标消息下发日志和所述目标消息拉取日志，确定所述客户端丢失的消息标识时，包括：

比对所述目标消息下发日志和所述目标消息拉取日志中的消息标识，筛选存在所述目标消息下发日志中，且不存在所述目标消息拉取日志中的目标消息标识；

将所述目标消息标识作为所述客户端丢失的消息标识。

在一种可能的实施方式中，所述确定模块在用于基于更新后的所述客户端的消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果时，还包括：

在确定所述客户端丢失的消息标识后，基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因。

在一种可能的实施方式中，所述确定模块在用于基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因时，包括：

在所述消息下发日志中，检测与所述丢失的消息标识匹配的存储状态；

在所述存储状态表示存储失败的情况下，确定所述丢失的消息标识对应的丢失原因为存储失败；

在所述存储状态表示存储成功的情况下，基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因。

在一种可能的实施方式中，所述确定模块在用于基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因时，包括：

在针对所述客户端的消息拉取日志中，查找是否存在与所述丢失消息标识对应的第一日志记录，所述第一日志记录中记录有所述客户端接收到所述丢失消息标识对应的消息；

在确定存在与所述丢失消息标识对应的第一日志记录的情况下，确定所述丢失消息标识对应的丢失原因为所述客户端解析失败；

在确定不存在与所述丢失消息标识对应的第一日志记录的情况下，查找是否存在与所述丢失消息标识对应的第二日志记录，所述第二日志记录中记录有服务器向所述客户端发送所述丢失消息标识对应的消息；

在确定存在与所述丢失消息标识对应的第二日志记录的情况下，确定所述丢失消息标识对应的丢失原因为所述服务器与所述客户端之间的网络传输中断。

在一种可能的实施方式中，所述确定模块在用于基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因时，还包括：

在确定不存在与所述丢失消息标识对应的第一日志记录和第二日志记录的情况下，获取包含所述丢失消息标识对应时刻所在的设定时长内的待检测消息拉取日志；

检测所述待检测消息拉取日志中包含的消息序列号是否连续；

在确定所述待检测消息拉取日志中包含的消息序列号连续的情况下，确定所述丢失消息标识对应的丢失原因为服务器故障；

在确定所述待检测消息拉取日志中包含的消息序列号不连续的情况下，确定所述丢失消息标识对应的丢失原因为客户端发送的消息获取请求存在消息丢失。

第三方面，本公开实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如第一方面所述的消息处理方法的步骤。

第四方面，本公开实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如第一方面所述的消息处理方法的步骤。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种消息处理方法的流程图；

图2示出了本公开实施例所提供的一种消息存储过程的示意图；

图3示出了本公开实施例所提供的一种消息拉取过程的示意图；

图4示出了本公开实施例所提供的一种确定针对客户端的消息丢失结果的方法流程图；

图5示出了本公开实施例所提供的一种确定丢失的消息标识对应的丢失原因的方法流程图；

图6示出了本公开实施例所提供的一种确定丢失的消息标识对应的具体丢失原因的方法流程图；

图7示出了本公开实施例所提供的一种消息处理装置的结构示意图；

图8示出了本公开实施例所提供的一种电子设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

实时消息系统一般由客户端、服务器和存储器构成，客户端可以按照固定时间间隔向服务器拉取该服务器最新存储的信息，比如直播场景下，按照该方式，客户端可以向服务器拉取到最新的直播消息，但是经常会存在消息丢失的情况，如何准确地分析消息丢失原因，为本公开实施例要讨论的问题。

基于上述研究，本公开提供了一种消息处理方法，服务器每次向客户端返回最新消息时，会同时返回最新消息序列号，且该最新消息序列号与客户端上次接收到的消息序列号相关，这样在基于客户端上次接收到的消息标识、最新消息列表中的消息标识和最新消息序列号，更新的该客户端的消息拉取日志可以准确地反应该客户端拉取的消息以及接收到的消息，然后进一步基于针对该客户端的更新后的消息拉取日志，以及最新更新的消息下发日志，可以准确地确定该客户端在丢失消息结果，示例性地，可以准确地确定客户端丢失的消息以及对应的丢失原因。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种消息处理方法进行详细介绍，本公开实施例所提供的消息处理方法的执行主体一般为具有一定计算能力的计算机设备，该计算机设备例如包括：终端设备或服务器或其它处理设备。在一些可能的实现方式中，该消息处理方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

如图1所示，为本公开实施例提供的消息处理方法的流程示意图，具体包括以下S101～S104：

S101，响应于从客户端接收消息获取请求，获取客户端上次接收的消息标识和消息序列号。

其中，客户端(Client)或称为用户端，是指与服务器相对应，为客户提供本地服务的程序。除了一些只在本地运行的应用程序之外，一般安装在普通的客户机上，需要与服务器互相配合运行。

示例性地，本公开实施例中的客户端可以为安装在平板、手机、电脑等智能设备上的应用程序，比如可以包括直播软件、实时通信软件等。

客户端在登录实时通信系统后，可以按照固定时间间隔向服务器发送消息获取请求，以获取服务器存储的针对该客户端的最新消息列表，客户端在当前时刻向服务器发送消息获取请求时，该消息获取请求可以携带客户端上次接收的消息列表中每条消息对应的消息标识以及上次接收到的消息列表对应的消息序列号。

示例性地，消息列表中的每条消息的消息标识为唯一标识该条消息的标识，该标识可以是服务器在接收到该条消息对其进行编码，生成的标识，比如针对直播场景，服务器除了可以在接收到各个客户端发送的消息获取请求，将针对该客户端的最新消息发送至该客户端外，还可以接收各个客户端发送的写入消息，在接收到每条写入消息时，可以对该条写入消息进行编码，即生成该条写入消息的消息标识，在接收到客户端发送的消息获取请求时，可以将针对该客户端的最新消息以及对应的消息标识同时发送至该客户端。

示例性地，消息列表对应的消息序列号表示该消息列表的序列号，比如第一次向该客户端发送的消息列表对应的消息序列号可以为001，第二次向该客户端发送的消息列表对应的消息序列号可以为002，依次类推，通过该客户端上次接收的消息序列号，可以确定本次向该客户端发送消息列表时对应的最新消息序列号。

S102，基于客户端上次接收的消息标识，获取针对客户端的最新消息列表，以及基于消息序列号获取与最新消息列表对应的最新消息序列号。

示例性地，可以基于客户端上次接收的消息标识，在预先存储的消息存储库中查找针对该客户端的最新消息列表。

具体地，在基于客户端上次接收的消息标识，获取针对客户端的最新消息列表时，可以包括：

(1)在消息存储库中查找与客户端匹配的候选消息列表；

(2)基于客户端上次接收的消息标识，在候选消息列表中获取排序位于消息标识之后的最新消息列表。

消息存储库可以建立在实时消息系统中的存储器中，服务器接收到每条写入消息时，可以按照时间接收顺序，对该条写入消息进行编码，然后将该条写入消息和对应的编码存储至存储器中，具体在存储时，同时记录该条信息的发送方客户端的标识、接收方客户端的标识、写入时间信息等内容，并且同时标记该消息的存储状态，具体包括存储成功或者存储失败。

如图2所示，为消息存储过程，写入客户端可以接收用户输入的写入消息，并将该写入消息发送至服务器，服务器在接收到该写入消息时，可以获取该写入消息对应的发送方客户端的标识、接收方客户端的标识、写入时间、写入消息的具体内容等信息，并且对该写入消息进行编码，然后将该写入消息存储至存储器。

对应地，服务器在接收到客户端(该客户端可以为消息写入的写入客户端，也可以是其它客户端)发送的消息获取请求时，基于客户端上次接收到的消息标识，在消息存储库中查找与该客户端匹配的候选消息列表，比如可以按照该客户端的客户端标识，在消息存储库中查找发送给该客户端的候选消息列表，然后在该候选消息列表中查找排序位于该客户端上次接收到的消息标识之后的最新消息列表，这样可以得到本次要发送给该客户端的最新消息列表。

示例性地，具体在获取与最新消息列表对应的最新消息序列号时，可以将客户端上次接收消息序列号按顺序加1后得到，比如客户端上次接收消息序列号为n，则与最新消息列表对应的最新消息序列号为n+1。

特别地，如果客户端在当前发送的消息获取请求为第一次发送的消息获取请求，客户端上次接收到的消息标识可以为空，上次接收到的消息序列号可以为0。

S103，将最新消息列表和最新消息序列号发送至客户端，并基于客户端上次接收的消息标识、最新消息列表中的消息标识和最新消息序列号，更新客户端的消息拉取日志。

如图3所示，为客户端请求获取消息以及服务器返回最新消息列表的流程示意图，客户端首次向服务器发送消息获取请求时，该消息获取请求中不包含该客户端上次接收到的消息标识，且上次接收到的消息序列号为0，服务器从存储器中获取最新消息列表发送至该客户端，最新信息列表中包含消息标识为1,2,3的消息，以及该最新消息序列号为1，客户端第二次向服务器发送消息获取请求时，该消息获取请求中包含该客户端上次接收到的消息标识1,2,3，以及上次接收到的消息序列号1，服务器从存储器中获取最新消息列表发送至该客户端，最新信息列表中包含消息标识为4,5,6的消息，以及该最新消息序列号为2。

此外，服务器还可以基于客户端上次接收到的消息标识、最新消息列表中的消息标识和最新消息序列号，更新客户端的消息拉取日志，可以理解为服务器每次向客户端返回最新消息列表后，均会对该客户端的消息拉取日志进行更新，即增加针对该客户端的本次消息拉取日志。

其中，消息拉取日志中记录的该客户端上次接收到的消息标识可以记录客户端接收到的消息，消息拉取日志中的最新消息列表中的消息标识能够记录本次发送给客户端的消息，最新消息序列号可以记录本次发送给客户端的最新消息列表的序列号。

此外，消息拉取日志中还可以记录用于表示客户端的客户端设备号、消息发送时间、客户端版本以及网络类型等信息。

S104，基于更新后的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果。

示例性地，消息下发日志可以在消息存储时生成，即服务器每接收到客户端发送的写入消息时，同时更新消息下发日志。

最新更新的消息下发日志记录有全面的写入消息，针对每个客户端，该最新更新的消息下发日志中记录有针对该客户端的全部消息，包括单独发送给该客户端的，以及发送给所有消息的公共消息。

更新后的消息拉取日志中记录有发送给客户端的消息，这样基于更新后的消息拉取日志和最新更新的消息下发日志可以确定针对该客户端的消息丢失结果。

本公开实施例中，服务器每次向客户端返回最新消息时，会同时返回最新消息序列号，且该最新消息序列号与客户端上次接收到的消息序列号相关，这样在基于客户端上次接收到的消息标识、最新消息列表中的消息标识和最新消息序列号，更新的该客户端的消息拉取日志可以准确地反应该客户端拉取的消息以及接收到的消息，然后进一步基于针对该客户端的更新后的消息拉取日志，以及最新更新的消息下发日志，可以准确地确定该客户端在丢失消息结果，示例性地，可以准确地确定客户端丢失的消息以及对应的丢失原因。

具体地，在一种实施方式中，可以按照以下步骤更新消息下发日志：

(1)响应于从至少一个客户端接收写入消息，确定写入消息对应的消息标识、消息内容和目标接收端信息；

(2)基于写入消息对应的消息标识、消息内容和目标接收端信息，将写入消息存储至预先构建的消息存储库，并结合存储结果更新消息下发日志。

示例性地，目标接收端信息可以包含上文提到的接收方客户端的标识，具体可以包括客户端设备号、客户端用户登录名等，这些目标接收端信息用于唯一标识接收方客户端的信息。

在每次接收到客户端发送的写入消息，将写入消息存储至消息存储库时，均会基于写入消息对应的消息标识、消息内容、目标接收端信息以及存储结果(存储成功和存储失败)等来更新消息下发日志，得到最新消息下发日志，消息存储过程详见上文图2对应的描述，在此不再赘述。

在一种实施方式中，针对上述S104，在基于更新后的客户端的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果时，如图4所示，可以包括以下步骤S401～S404：

S401，响应于从客户端接收消息反馈信息，基于接收到消息反馈信息的时刻确定目标检测时间段。

用户在确定客户端中展示的消息存在丢失的情况下，可以触发消息反馈，此时客户端可以向服务器发送消息反馈信息，该消息反馈信息用于指示客户端存在消息丢失的情况。

一般情况下，在实时消息系统中，用户在发现客户端展示的消息存在丢失的情况下，会短时间内触发消息反馈，这样服务器接收到该消息反馈信息，可以基于接收到消息反馈信息的时刻来确定目标检测时间段，比如可以将接收到消息反馈信息的时刻向前的设定时间段作为该目标检测时间段，示例性地，接收到消息反馈信息的时刻为9:30，若设定时间段为30min，则目标检测时间段为9:00～9:30的30min。

S402，在最新更新的消息下发日志中提取与目标检测时间段对应的目标消息下发日志，以及在针对客户端的更新后的消息拉取日志中提取与目标检测时间段对应的目标消息拉取日志。

示例性地，以目标检测时间段为9:00～9:30为准，目标消息下发日志为9:00～9:30时间段内记录的消息下发日志，目标消息拉取日志为9:00～9:30时间段内记录针对该客户端的消息下发日志。

S403，基于目标消息下发日志和目标消息拉取日志，确定客户端丢失的消息标识。

具体地，在基于目标消息下发日志和目标消息拉取日志，确定客户端丢失的消息标识时，可以包括：

(1)比对目标消息下发日志和目标消息拉取日志中的消息标识，筛选存在目标消息下发日志中，且不存在目标消息拉取日志中的目标消息标识；

(2)将目标消息标识作为客户端丢失的消息标识。

示例性地，目标检测时间段9:00～9:30对应的目标消息下发日志中包含针对该客户端的消息标识为007～020的写入消息，而目标检测时间段9:00～9:30对应的目标消息拉取日志中不存在消息标识为008～010的消息，则可以确定目标消息标识为008～010。

示例性地，目标检测时间段9:00～9:30对应的目标消息拉取日志中不存在消息标识为008～010的消息，可以包括以下几种情况：

目标消息拉取日志中不存在指示客户端接收到消息标识008～010的记录；目标消息拉取日志中不存在指示向客户端发送了消息标识008～010的记录；以及目标消息拉取日志中既不存在指示客户端接收到消息标识008～010的记录，也不存在指示向客户端发送了消息标识008～010的记录。

示例性地，本公开实施例中可以基于目标消息下发日志和目标消息拉取日志中指示客户端接收到消息标识的记录，来确定目标消息标识，即客户端丢失的消息标识，比如若目标消息拉取日志中不存在指示客户端接收到消息标识008～010的记录，可以将消息标识008～010作为目标消息标识。

S404，在确定客户端丢失的消息标识后，基于消息下发日志和/或客户端的消息拉取日志，确定丢失的消息标识对应的丢失原因。

在确定客户端丢失的消息标识后，进一步可以基于消息下发日志来确定丢失的消息标识对应的丢失原因，或者，基于客户端的消息拉取日志来确定丢失的消息标识对应的丢失原因，或者，同时基于消息下发日志和客户端的消息拉取日志，来确定丢失的消息标识对应的丢失原因，详见下文描述。

这里的消息下发日志以及消息拉取日志对应的时间段大于上文提到的目标检测时间段，示例性地，可以为完整的时间段对应的消息下发日志以及消息拉取日志。

本公开实施例中，通过确定目标检测时间段来提取目标消息下发日志和目标消息拉取日志，从而无需基于完整的消息下发日志和消息拉取日志来确定客户端丢失的消息标识，提高了确定速度。

另外，在确定出客户端丢失的消息标识后，进一步基于完整的消息下发日志和/或客户端的消息拉取日志，来确定丢失的消息标识对应的丢失原因时，可以提高准确度。

具体地，在基于消息下发日志和/或客户端的消息拉取日志，确定丢失的消息标识对应的丢失原因时，如图5所示，可以包括以下S501～S503：

S501，在消息下发日志中，检测与丢失的消息标识匹配的存储状态。

上文提到，在每次接收到客户端发送的写入消息后，会结合存储结果共同生成消息下发日志，因此消息下发日志中，每条消息标识均对应有与存储结果对应的存储状态，包括存储成功或者存储失败。

S502，在存储状态表示存储失败的情况下，确定丢失的消息标识对应的丢失原因为存储失败。

考虑到服务器不会将这类存储失败的消息发送至客户端，因此若客户端丢失的消息标识为存储失败的消息，则可以确定丢失的消息标识对应的丢失原因为存储失败。

S503，在存储状态表示存储成功的情况下，基于针对客户端的消息拉取日志，确定丢失消息标识对应的丢失原因。

在丢失的消息标识对应的存储状态为存储成功时，可以进一步基于针对客户端的消息拉取日志，来确定丢失消息标识对应的丢失原因。

具体地，在一种实施方式中，在基于针对客户端的消息拉取日志，确定丢失消息标识对应的丢失原因时，如图6所示，可以包括以下步骤S601～S608：

S601，在针对客户端的消息拉取日志中，查找是否存在与丢失消息标识对应的第一日志记录，第一日志记录中记录有客户端接收到丢失消息标识对应的消息。

服务器在每次针对客户端的消息拉取日志进行更新时，均会保留该客户端上次接收到的消息标识，因此这里提出可以在针对客户端的消息拉取日志中查找是否存在记录有客户端接收到丢失消息标识对应的消息。

S602，在确定存在与丢失消息标识对应的第一日志记录的情况下，确定丢失消息标识对应的丢失原因为客户端解析失败。

在确定存在与丢失消息标识对应的第一日志记录的情况下，可以确定客户端接收到了与该丢失消息标识对应的消息，但是并未对丢失消息标识对应的消息进行展示，可以确定丢失原因为客户端解析失败，即客户端在接收到丢失消息标识对应的消息后，没有对该消息进行解析展示。

S603，在确定不存在与丢失消息标识对应的第一日志记录的情况下，查找是否存在与丢失消息标识对应的第二日志记录，第二日志记录中记录有服务器向客户端发送丢失消息标识对应的消息。

在确定不存在第一日志记录的情况下，继续在针对客户端的消息拉取日志中，查找是否存在记录有服务器向客户端发送的与丢失消息标识对应的消息，可以基于此确定服务器是否向客户端发送过与丢失消息标识对应的消息。

S604，在确定存在与丢失消息标识对应的第二日志记录的情况下，确定丢失消息标识对应的丢失原因为服务器与客户端之间的网络传输中断。

在确定第二日志记录的情况下，说明服务器向客户端发送过与丢失消息标识对应的消息，但是客户端却未接收到与丢失消息标识对应的消息，可以确定丢失原因为服务器在向客户端传输丢失消息标识对应的消息时，存在与客户端之间的网络传输中断的问题。

S605，在确定不存在与丢失消息标识对应的第一日志记录和第二日志记录的情况下，获取包含丢失消息标识对应时刻所在的设定时长内的待检测消息拉取日志。

进一步地，在确定既不存在第一日志记录，也不存在第二日志记录的情况下，可以获取包含丢失消息标识对应时刻所在的设定时长内的待检测消息拉取日志，该待检测消息拉取日志既可以包含位于丢失消息标识对应时刻之前时间段的消息拉取日志，也可以包含位于丢失消息标识对应时刻之后时间段的消息拉取日志，其中，丢失消息标识对应的时刻可以基于消息写入日志中获取。

S606，检测待检测消息拉取日志中包含的消息序列号是否连续。

正常情况下，每次针对客户端更新消息拉取日志的过程中，消息序列号是连续的，因此这里可以通过检测待检测消息拉取日志中包含的消息序列号是否连续来确定丢失消息标识的丢失原因。

S607，在确定待检测消息拉取日志中包含的消息序列号连续的情况下，确定丢失消息标识对应的丢失原因为服务器故障。

若待检测消息拉取日志中包含的消息序列号连续，可以说明服务器在每次针对客户端进行更新消息拉取日志时，接收到的客户端发送的消息获取请求中包含的上次接收的消息序列号是连续的，但是服务器却没有向客户端发送与丢失消息标识对应的消息，可以确定服务器在发送与丢失消息标识对应的消息时发生故障。

S608，在确定待检测消息拉取日志中包含的消息序列号不连续的情况下，确定丢失消息标识对应的丢失原因为客户端发送的消息获取请求存在消息丢失。

反之，若待检测消息拉取日志中包含的消息序列号不连续，可以说明服务器在每次针对客户端进行更新消息拉取日志时，接收到的客户端发送的消息获取请求中包含的上次接收的消息序列号就不是连续的，可以确定客户端发送的消息获取请求存在消息丢失，比如丢失了上次接收到的消息标识和消息序列号。

本公开实施例中，结合消息下发日志中每条消息的存储状态、消息拉取日志中针对每条消息的记录情况以及消息序列号，可以准确地确定客户端丢失消息标识对应的丢失原因，方便基于对应的丢失原因进行修正。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一技术构思，本公开实施例中还提供了与消息处理方法对应的消息处理装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述消息处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图7所示，为本公开实施例提供的一种消息处理装置700的结构示意图，该消息处理装置包括：

第一获取模块701，用于响应于从客户端接收消息获取请求，获取客户端上次接收的消息标识和消息序列号；

第二获取模块702，用于基于客户端上次接收的消息标识，获取针对客户端的最新消息列表，以及基于消息序列号获取与最新消息列表对应的最新消息序列号；

更新模块703，用于将最新消息列表和最新消息序列号发送至客户端，并基于客户端上次接收的消息标识、最新消息列表中的消息标识和最新消息序列号，更新客户端的消息拉取日志；

确定模块704，用于基于更新后的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果。

在一种可能的实施方式中，第二获取模块702在用于基于客户端上次接收的消息标识，获取针对客户端的最新消息列表时，包括：

在消息存储库中查找与客户端匹配的候选消息列表；

基于客户端上次接收的消息标识，在候选消息列表中获取排序位于消息标识之后的最新消息列表；

基于客户端上次接收到的消息序列号，确定最新消息列表对应的最新消息序列号。

在一种可能的实施方式中，更新模块703还用于按照以下步骤更新消息下发日志：

响应于从至少一个客户端接收写入消息，确定写入消息对应的消息标识、消息内容和目标接收端信息；

基于写入消息对应的消息标识、消息内容和目标接收端信息，将写入消息存储至预先构建的消息存储库，并结合存储结果更新消息下发日志。

在一种可能的实施方式中，确定模块704在用于基于更新后的客户端的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果时，包括：

响应于从客户端接收消息反馈信息，基于接收到消息反馈信息的时刻确定目标检测时间段；

在最新更新的消息下发日志中提取与目标检测时间段对应的目标消息下发日志，以及在针对客户端的更新后的消息拉取日志中提取与目标检测时间段对应的目标消息拉取日志；

基于目标消息下发日志和目标消息拉取日志，确定客户端丢失的消息标识。

在一种可能的实施方式中，确定模块704在用于基于目标消息下发日志和目标消息拉取日志，确定客户端丢失的消息标识时，包括：

比对目标消息下发日志和目标消息拉取日志中的消息标识，筛选存在目标消息下发日志中，且不存在目标消息拉取日志中的目标消息标识；

将目标消息标识作为客户端丢失的消息标识。

在一种可能的实施方式中，确定模块704在用于基于更新后的客户端的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果时，还包括：

在确定客户端丢失的消息标识后，基于消息下发日志和/或客户端的消息拉取日志，确定丢失的消息标识对应的丢失原因。

在一种可能的实施方式中，确定模块704在用于基于消息下发日志和/或客户端的消息拉取日志，确定丢失的消息标识对应的丢失原因时，包括：

在消息下发日志中，检测与丢失的消息标识匹配的存储状态；

在存储状态表示存储失败的情况下，确定丢失的消息标识对应的丢失原因为存储失败；

在存储状态表示存储成功的情况下，基于针对客户端的消息拉取日志，确定丢失消息标识对应的丢失原因。

在一种可能的实施方式中，确定模块704在用于基于针对客户端的消息拉取日志，确定丢失消息标识对应的丢失原因时，包括：

在针对客户端的消息拉取日志中，查找是否存在与丢失消息标识对应的第一日志记录，第一日志记录中记录有客户端接收到丢失消息标识对应的消息；

在确定存在与丢失消息标识对应的第一日志记录的情况下，确定丢失消息标识对应的丢失原因为客户端解析失败；

在确定不存在与丢失消息标识对应的第一日志记录的情况下，查找是否存在与丢失消息标识对应的第二日志记录，第二日志记录中记录有服务器向客户端发送丢失消息标识对应的消息；

在确定存在与丢失消息标识对应的第二日志记录的情况下，确定丢失消息标识对应的丢失原因为服务器与客户端之间的网络传输中断。

在一种可能的实施方式中，确定模块704在用于基于针对客户端的消息拉取日志，确定丢失消息标识对应的丢失原因时，还包括：

在确定不存在与丢失消息标识对应的第一日志记录和第二日志记录的情况下，获取包含丢失消息标识对应时刻所在的设定时长内的待检测消息拉取日志；

检测待检测消息拉取日志中包含的消息序列号是否连续；

在确定待检测消息拉取日志中包含的消息序列号连续的情况下，确定丢失消息标识对应的丢失原因为服务器故障；

在确定待检测消息拉取日志中包含的消息序列号不连续的情况下，确定丢失消息标识对应的丢失原因为客户端发送的消息获取请求存在消息丢失。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

对应于图1中的消息处理方法，本公开实施例还提供了一种电子设备800，如图8所示，为本公开实施例提供的电子设备800结构示意图，包括：

处理器81、存储器82、和总线83；存储器82用于存储执行指令，包括内存821和外部存储器822；这里的内存821也称内存储器，用于暂时存放处理器81中的运算数据，以及与硬盘等外部存储器822交换的数据，处理器81通过内存821与外部存储器822进行数据交换，当所述电子设备800运行时，所述处理器81与所述存储器82之间通过总线83通信，使得所述处理器81执行以下指令：响应于从客户端接收消息获取请求，获取客户端上次接收的消息标识和消息序列号；基于客户端上次接收的消息标识，获取针对客户端的最新消息列表，以及基于消息序列号获取与最新消息列表对应的最新消息序列号；将最新消息列表和最新消息序列号发送至客户端，并基于客户端上次接收的消息标识、最新消息列表中的消息标识和最新消息序列号，更新客户端的消息拉取日志；基于更新后的消息拉取日志和最新更新的消息下发日志，确定针对客户端的消息丢失结果。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的消息处理方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例所提供的消息处理方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行上述方法实施例中所述的消息处理方法的步骤，具体可参见上述方法实施例，在此不再赘述。

本公开实施例还提供一种计算机程序，该计算机程序被处理器执行时实现前述实施例的任意一种方法。该计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (11)

1.一种消息处理方法，其特征在于，应用于服务端，包括：

响应于从客户端接收消息获取请求，获取所述客户端上次接收的消息标识和消息序列号；所述消息序列号表示消息列表的序列号，一条消息对应于一个所述消息标识；

基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表，以及基于所述消息序列号获取与所述最新消息列表对应的最新消息序列号；

将所述最新消息列表和所述最新消息序列号发送至所述客户端，并基于所述客户端上次接收的消息标识、所述最新消息列表中的消息标识和所述最新消息序列号，更新所述客户端的消息拉取日志；

基于更新后的所述消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果；所述消息丢失结果用于指示所述客户端丢失的消息标识；

在确定所述客户端丢失的消息标识后，基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因。

2.根据权利要求1所述的消息处理方法，其特征在于，所述基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表，包括：

在消息存储库中查找与所述客户端匹配的候选消息列表；

基于所述客户端上次接收的消息标识，在所述候选消息列表中获取排序位于所述消息标识之后的最新消息列表。

3.根据权利要求1所述的消息处理方法，其特征在于，按照以下步骤更新消息下发日志：

响应于从至少一个客户端接收写入消息，确定所述写入消息对应的消息标识、消息内容和目标接收端信息；

基于所述写入消息对应的消息标识、消息内容和目标接收端信息，将所述写入消息存储至预先构建的消息存储库，并结合存储结果更新消息下发日志。

4.根据权利要求1所述的消息处理方法，其特征在于，所述基于更新后的所述客户端的消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果，包括：

响应于从客户端接收消息反馈信息，基于接收到所述消息反馈信息的时刻确定目标检测时间段；

在所述最新更新的消息下发日志中提取与所述目标检测时间段对应的目标消息下发日志，以及在针对所述客户端的更新后的所述消息拉取日志中提取与所述目标检测时间段对应的目标消息拉取日志；

基于所述目标消息下发日志和所述目标消息拉取日志，确定所述客户端丢失的消息标识。

5.根据权利要求4所述的消息处理方法，其特征在于，所述基于所述目标消息下发日志和所述目标消息拉取日志，确定所述客户端丢失的消息标识，包括：

比对所述目标消息下发日志和所述目标消息拉取日志中的消息标识，筛选存在所述目标消息下发日志中，且不存在所述目标消息拉取日志中的目标消息标识；

将所述目标消息标识作为所述客户端丢失的消息标识。

6.根据权利要求5所述的消息处理方法，其特征在于，所述基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因，包括：

在所述消息下发日志中，检测与所述丢失的消息标识匹配的存储状态；

在所述存储状态表示存储失败的情况下，确定所述丢失的消息标识对应的丢失原因为存储失败；

在所述存储状态表示存储成功的情况下，基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因。

7.根据权利要求6所述的消息处理方法，其特征在于，所述基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因，包括：

在针对所述客户端的消息拉取日志中，查找是否存在与所述丢失消息标识对应的第一日志记录，所述第一日志记录中记录有所述客户端接收到所述丢失消息标识对应的消息；

在确定存在与所述丢失消息标识对应的第一日志记录的情况下，确定所述丢失消息标识对应的丢失原因为所述客户端解析失败；

在确定不存在与所述丢失消息标识对应的第一日志记录的情况下，查找是否存在与所述丢失消息标识对应的第二日志记录，所述第二日志记录中记录有服务器向所述客户端发送所述丢失消息标识对应的消息；

在确定存在与所述丢失消息标识对应的第二日志记录的情况下，确定所述丢失消息标识对应的丢失原因为所述服务器与所述客户端之间的网络传输中断。

8.根据权利要求7所述的消息处理方法，其特征在于，所述基于针对所述客户端的消息拉取日志，确定丢失消息标识对应的丢失原因，还包括：

在确定不存在与所述丢失消息标识对应的第一日志记录和第二日志记录的情况下，获取包含所述丢失消息标识对应时刻所在的设定时长内的待检测消息拉取日志；

检测所述待检测消息拉取日志中包含的消息序列号是否连续；

在确定所述待检测消息拉取日志中包含的消息序列号连续的情况下，确定所述丢失消息标识对应的丢失原因为服务器故障；

在确定所述待检测消息拉取日志中包含的消息序列号不连续的情况下，确定所述丢失消息标识对应的丢失原因为客户端发送的消息获取请求存在消息丢失。

9.一种消息处理装置，其特征在于，应用于服务端，包括：

第一获取模块，用于响应于从客户端接收消息获取请求，获取所述客户端上次接收的消息标识和消息序列号；所述消息序列号表示消息列表的序列号，一条消息对应于一个所述消息标识；

第二获取模块，用于基于所述客户端上次接收的消息标识，获取针对所述客户端的最新消息列表，以及基于所述消息序列号获取与所述最新消息列表对应的最新消息序列号；

更新模块，用于将所述最新消息列表和所述最新消息序列号发送至所述客户端，并基于所述客户端上次接收的消息标识、所述最新消息列表中的消息标识和所述最新消息序列号，更新所述客户端的消息拉取日志；

确定模块，用于基于更新后的所述消息拉取日志和最新更新的消息下发日志，确定针对所述客户端的消息丢失结果；所述消息丢失结果用于指示所述客户端丢失的消息标识；

在确定所述客户端丢失的消息标识后，基于所述消息下发日志和/或所述客户端的所述消息拉取日志，确定丢失的消息标识对应的丢失原因。

10.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至8任一所述的消息处理方法的步骤。

11.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至8任一所述的消息处理方法的步骤。

Images