CN112367149A - 消息获取方法、装置、设备及存储介质 - Google Patents

Abstract

本发明实施例公开了消息获取方法、装置、设备及存储介质。其中，该方法包括：向服务端发起消息获取请求，并记录本次请求的发起时间，消息获取请求用于指示服务端返回消息序号大于确认序号的消息，接收服务端返回的消息，并记录所接收到的消息中的最大消息序号，重复向服务端发起消息获取请求，并接收服务端返回的消息，从发起时间起经过预设时长后，向服务端反馈所述最大消息序号，其中，最大消息序号用于指示服务端将确认序号更新为所述最大消息序号。本发明实施例提供的技术方案，可以能够提高消息被成功获取的概率，有效解决客户端的消息获取缺失问题。

Description

消息获取方法、装置、设备及存储介质

技术领域

本发明实施例涉及通信技术领域，尤其涉及消息获取方法、装置、设备及存储介质。

背景技术

随着通信技术及互联网技术的快速发展，人与人之间的基于网络的信息交互越来越频繁，消息数量骤增。

以即时通信(Instant Messaging,IM)系统为例，发送者通过客户端发送一条消息到达服务端，服务端将新消息到达以某种形式通知给接收者客户端，接收者客户端收到服务端通知后主动从服务端获取新到达的消息，然后服务端将新消息置为已读状态，当客户端下次过来获取新消息时候，就获取不到这条消息了。目前，由于服务端与客户端的网络连接状况的不确定性，导致客户端可能无法收到新消息到达的通知，或者获取到的消息顺序错乱，抑或因设置消息已读状态失败导致重复获取到同样的消息等等，这些情况造成了服务端与客户端之间的数据状态不一致，严重影响了IM功能的正确性和用户的使用体验。

为了解决上述问题，现有技术中，发送者发送一条消息到达服务端后，服务端针对接收者生成一个唯一的自增序号(记为id，也即消息序号，其初始值为1，每接收到一条新消息都在原值的基础上加1)来标识这条消息，并存储到数据库中，客户端从服务端获取消息后，立即将获取到的消息集合中的最大id(记为ackid，也即确认序号，其初始值为0)返回给服务端保存起来。这样下次客户端再向服务端获取消息时，服务端在数据库存储的接收者的消息列表中找出id大于ackid的所有消息返回给客户端，然后客户端立即从返回的消息集合里取出最大id返回给服务端，服务端更新ackid的值为接收到的新值。这种方案在大部分场景下可以有效解决了消息的乱序和重复，但是在一些特殊情况下(如在高并发情况下，id值较小的消息在id值较大的消息被客户端确认收到后，才成功在服务端存储下来，客户端就不能接收到id值较小的消息；又如消息在发送过程中丢失)，仍然可能造成消息的丢失，即客户端获取不到某些消息。因此，目前的消息获取方案仍不够完善，需要改进。

发明内容

本发明实施例提供了消息获取方法、装置、设备及存储介质，可以优化现有的消息获取方案。

第一方面，本发明实施例提供了一种消息获取方法，应用于客户端，包括：

向服务端发起消息获取请求，并记录本次请求的发起时间，其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置；

接收所述服务端返回的消息，并记录所接收到的消息中的最大消息序号；

重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息；

从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号，其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔。

第二方面，本发明实施例提供了一种消息获取装置，配置于客户端，包括：

发起时间记录模块，用于向服务端发起消息获取请求，并记录本次请求的发起时间，其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置；

最大消息序号记录模块，用于接收所述服务端返回的消息，并记录所接收到的消息中的最大消息序号；

消息重复获取模块，用于重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息；

最大消息序号反馈模块，用于从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号，其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔。

第三方面，本发明实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如本发明实施例提供的消息获取方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例提供的消息获取方法。

本发明实施例中提供的消息获取方案，向服务端发起消息获取请求，并记录本次请求的发起时间，消息获取请求用于指示服务端返回消息序号大于其存储的确认序号的消息，接收服务端返回的消息，并记录所接收到的消息中的最大消息序号，重复向服务端发起消息获取请求并接收服务端返回的消息，从发起时间起经过预设时长后，向服务端反馈所述最大消息序号，指示服务端将确认序号更新为最大消息序号。通过采用上述技术方案，客户端在接收到服务端返回的消息后，先记录下最大消息号，但暂不向服务端反馈该最大消息号，而是经过一段时间后再反馈，在所经过的这段时间内，重复向服务端发起消息获取请求，由于服务端的确认序号未发生变化，因此，部分消息会被重复返回，能够提高消息被成功获取的概率，实现消息的冗余获取，有效解决客户端的消息获取缺失问题。

附图说明

图1为本发明实施例提供的一种消息获取方法所适用的应用场景的场景架构图；

图2为本发明实施例提供的一种消息获取方法的流程示意图；

图3为本发明实施例提供的又一种消息获取方法的流程示意图；

图4为本发明实施例提供的一种消息获取时序示意图；

图5为本发明实施例提供的再一种消息获取方法的流程示意图；

图6为本发明实施例提供的另一种消息获取方法的流程示意图；

图7为本发明实施例提供的一种消息获取装置的结构框图；

图8为本发明实施例提供的一种计算机设备的结构框图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

图1为本发明实施例提供的一种消息获取方法所适用的应用场景的场景架构图。具体的，参考图1，该应用场景中可以包括客户端101和服务端102，客户端101可以是任意的通信应用程序，例如IM应用等。假设客户端101的使用者为用户A，当其他用户向用户A发送消息时，消息会先到达服务端102。示例性的，假设用户B发送给用户A的消息到达服务端102后，服务端102可以在消息体中添加一个当前时间戳，然后将消息写入到消息队列，写入消息队列成功后返回给用户B消息发送成功。服务端102中的消息队列消费者读出消息，为读出的消息生成一个唯一自增id(也即消息序号，假设用户A为新用户，则id初始值可以为1，然后从1开始自增)，随后将消息写入到数据库，在写入数据库成功后，设置消息队列中该消息已被消费，可以通知用户A的客户端101有新消息到达(也可以不通知，而是等客户端101主动发起消息获取请求)。服务端102中存储有确认序号，该确认序号可以表示数据库中存储的用户A对应的消息序号小于或等于确认序号的消息已经返回给客户端101。

现有技术中，客户端101向服务端102发起消息获取请求并接收服务端102返回的消息后，会立即将所接收到的消息中的最大消息序号反馈给服务端102，服务端102就会将原来存储的确认序号更新为刚刚接收到的最大消息序号，下次再接收到客户端101发起的消息获取请求时，就会将消息序号大于更新后的确认序号的消息返回给客户端101。然而，在一些特殊情况下，如其他用户同一时段内向用户A发送的消息数量较多，服务端102采用并发存储的方式将这些消息存储到数据库中，假设对于多条消息中的消息a和消息b，消息a先于消息b到达服务端102，因此，消息a的消息序号小于消息b的消息序号，但对消息a和消息b进行并发存储时，消息b先于消息a存储成功，而在消息a存储成功之前，客户端101发起了消息获取请求，此时服务端102就无法将消息a返回给客户端101，但消息b能够被客户端101接收，因此，若消息b的消息序号为最大消息序号，则客户端101会立即向服务端102反馈消息b的消息序号，服务端102会将本地存储的确认序号更新为b的消息序号，那么当客户端101再次发起消息获取请求时，由于消息a的消息序号小于消息b的消息序号，因此不会被服务端102返回给客户端101，甚至可能在将本地存储的确认序号更新为b的消息序号之后，就将消息序号小于b的消息序号的消息删除(包括消息a)，因此，就会出现客户端的消息获取缺失问题。另外，若在消息返回过程中，由于网络不稳定等因素，也可能出现消息丢失。

本发明实施例中，客户端101在接收到服务端102返回的消息后，延迟反馈最大消息号，能够提高消息被成功获取的概率，实现消息的冗余获取，有效解决客户端的消息获取缺失问题。

图2为本发明实施例提供的一种消息获取方法的流程示意图，该方法可以由消息获取装置执行，其中该装置可由软件和/或硬件实现，一般可集成在作为客户端的计算机设备中。其中，计算机设备可以是手机、平板电脑、笔记本电脑等移动终端，也可以是台式机等固定终端，具体不做限定。如图2所示，该方法包括：

步骤201、向服务端发起消息获取请求，并记录本次请求的发起时间，其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置。

本发明实施例中，对客户端向服务端发起消息获取请求的具体时机不做限定，例如，可以包括检测到客户端启动时(也即用户打开客户端时)，还可以包括接收到服务端发送的新消息达到通知(如Push通知)时，还可以包括客户端定时触发(如周期性触发)发起消息获取请求。

示例性的，消息获取请求具体可以是消息拉取请求，服务端在接收到消息获取请求后，查询服务端存储的消息序号大于当前确认序号的消息，并将查询到的消息发送给客户端。例如，服务端当前存储的确认序号为6，数据库中存储的消息序号大于6的消息有消息7、消息8和消息10，而消息9因此时未成功存储至数据库，因此，服务端无法查询到消息9，那么服务端就会将消息7、消息8和消息10返回给客户端。

示例性的，客户端在向服务端发起消息获取请求时，可以记录本次请求的发起时间，可用于确定后续反馈最大消息序号的时机，以及所需要反馈的最大消息序号。

步骤202、接收所述服务端返回的消息，并记录所接收到的消息中的最大消息序号。

示例性的，客户端接收服务端针对本次请求返回的消息，若接收过程中不存在异常，则客户端能够成功接收到消息7、消息8和消息10。但若受到网络不稳定等因素的影响，客户端也可能无法收到服务端返回的全部消息，假设消息8在发送过程中丢失，那么客户端仅能够收到消息7和消息10。

客户端在接收到服务端返回的消息后，查看所接收的各消息的消息序号，记录其中的最大消息序号，如上文举例，最大消息序号为10。在现有技术中，客户端会立即将序号10反馈给服务端，则服务端会将原来的确认序号6更新为10，后续再接收到客户端的消息获取请求时，序号10以及之前的消息都不会再返回给客户端。

本发明实施例中，可以将步骤201中记录的发起时间和步骤202中记录的最大消息序号进行绑定存储，便于后续需要反馈最大消息序号时，根据对应的发起时间查询到对应的最大消息序号。

步骤203、重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息。

本发明实施例中，在得到最大消息序号后，不会立即反馈给服务端，而是重复向服务端发起消息获取请求。重复发起请求的时机以及重复次数等均不作限定。假设重复次数为1，重复发起请求的时间为与上述记录的发起时间的时间间隔为第一时间间隔，那么经过第一时间间隔后，之前未成功存储的消息可能已经存储成功，由于服务端存储的确认序号并未更新，那么服务端会将该存储成功的消息一起返回给客户端。如前文举例，经过第一时间间隔后，消息9可能已经存储成功，数据库中存储的消息序号大于6的消息有消息7、消息8、消息9和消息10，此时，由于服务端的确认序号仍为6，因此，可以查询到消息有消息7、消息8、消息9和消息10，并返回给客户端。

此外，客户端再次接收服务端返回的消息时，网络状况可能已发生变化，可能会完整地接收到消息7、消息8、消息9和消息10，或者即使网络仍不稳定，客户端也可能成功接收到消息9，而丢失其他消息(如消息10)。

综上，通过延迟反馈最大消息序号并重复发起消息获取请求的方式，可以有效提高消息被成功获取的概率。

步骤204、从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号，其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔。

示例性的，预设时长也可以理解为延迟反馈的时长，可以根据实际情况进行设置，如3分钟等。经过预设时长后，及时向服务端反馈之前记录的最大消息序号，使得服务端对所存储的确认序号进行更新，以便控制后续响应消息获取请求时所返回的消息数量。可以理解的是，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔，即大于上述第一时间间隔。

本发明实施例中提供的消息获取方法，向服务端发起消息获取请求，并记录本次请求的发起时间，消息获取请求用于指示服务端返回消息序号大于其存储的确认序号的消息，接收服务端返回的消息，并记录所接收到的消息中的最大消息序号，重复向服务端发起消息获取请求并接收服务端返回的消息，从发起时间起经过预设时长后，向服务端反馈所述最大消息序号，指示服务端将确认序号更新为最大消息序号。通过采用上述技术方案，客户端在接收到服务端返回的消息后，先记录下最大消息号，但暂不向服务端反馈该最大消息号，而是经过一段时间后再反馈，在所经过的这段时间内，重复向服务端发起消息获取请求，由于服务端的确认序号未发生变化，因此，部分消息会被重复返回，能够提高消息被成功获取的概率，实现消息的冗余获取，可以有效解决由于消息序号靠前消息未及时在服务端成功存储或网络状况不稳定等原因导致的客户端的消息获取缺失问题。

在上述各可选实施例基础上，在所述重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息之后，还包括：根据消息序号对已接收到的消息进行去重处理。这样设置的好处在于，可以在多次获取消息后，统一进行去重处理，节省客户端的存储空间。其中，消息序号是服务端根据消息接收顺序进行递增配置的，也就是说，每条消息都有唯一且自增的id，因此，可以基于消息id的顺序进行去重，若存在多条对应同一id的消息，则说明存在重复，针对每个id仅保留一条消息。

在上述各可选实施例基础上，还可在每次发起消息获取请求并接收所述服务端返回的消息之后，根据消息序号对已接收到的消息进行去重处理。这样设置的好处在于，每获取一次消息，就进行一次去重处理，防止重复消息在客户端过久停留，进一步节省客户端的存储空间。

图3为本发明实施例提供的又一种消息获取方法的流程示意图，在上述各可选实施例基础上，针对重复向服务端发起消息获取请求并接收服务端返回的消息的技术细节进行优化。

示例性的，所述重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息，包括：以预设获取周期向所述服务端重复发起预设次数的消息获取请求，并接收所述服务端返回的消息。这样设置的好处在于，周期性的重复发起消息获取请求，可以更合理地管理消息获取请求的发起时机，有利于消息循环获取周期的叠加。其中，关于消息循环获取周期的内容将在下文中进行详细介绍。

示例性的，该方法可包括：

步骤301、向服务端发起消息获取请求，并记录本次请求的发起时间。

其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置。

示例性的，客户端采用定时触发的方式发起消息获取请求，具体的定时触发方式可以是周期性触发。

步骤302、接收服务端返回的消息，并记录所接收到的消息中的最大消息序号。

步骤303、以预设获取周期向服务端重复发起预设次数的消息获取请求，接收服务端返回的消息，并根据消息序号对已接收到的消息进行去重处理。

示例性的，周期性触发发起消息获取请求对应的触发周期可以与预设获取周期相等。

图4为本发明实施例提供的一种消息获取时序示意图，假设预设获取周期为a(如60秒)，预设次数为K＝2。步骤301中向服务端发起消息获取请求(图中以实线箭头表示，以k表示重复发起次数，首次发起时k＝0)时，服务端的ackid为7，发起时间记为t0，此时，服务端中存储的消息序号大于7的有消息8和消息10，向客户端返回消息8和消息10，假设不考虑网络因素，客户端能够成功接收到服务端返回的消息，则客户端能够接收到消息8和消息10，记录最大消息序号为Maxid0＝10，将t0和Maxid0＝10绑定存储。经过一个预设获取周期(a)之后，消息9存储成功，当客户端第一次重复发起(k＝1)消息获取请求时(发起时间t1)，由于服务端的ackid仍为7，因此，客户端会收到消息8、消息9和消息10。此时，可以与之前收到的消息8和消息10一起进行去重处理，在客户端保存消息8、消息9和消息10。若经过一个a之后，消息9仍未存储成功，那么可能在第二个a期间存储成功，那么通过第二次重复发起(k＝2)消息获取请求(发起时间t2)，客户端就能够成功获取到消息9。

步骤304、从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号。

其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号。

示例性的，所述预设时长为预设获取周期的倍数，所述倍数大于或等于所述预设次数。例如，该倍数可以等于预设次数。

继续参考图4，预设时长可以是K*a，也即在经过2个a之后，也即t2时刻之后，客户端获取消息完毕后，t3时刻之前，向服务端反馈t0时刻对应的Maxid0＝10(图中以虚线箭头表示)。当然，也可以在t3时刻，在向服务端发起消息获取请求的同时向服务端反馈t0时刻对应的Maxid0＝10。假设在第二个a期间，服务端又成功存储了消息11，那么第二次重复发起消息获取请求时，客户端能够接收到消息8、消息9、消息10和消息11。当客户端在t2时刻后向服务端反馈t0时刻对应的Maxid0＝10之后，服务端会将ackid更新为10，因此，客户端再向服务端发起消息获取请求时，如t3时刻，服务端会查找到大于10的消息为消息11，将消息11返回给客户端。

示例性的，可以将一次消息请求的发起时间作为起点，向服务端反馈最大消息序号的时间作为终点，将起点到终点之间经过的时间称为消息循环获取周期T。从图4中可以看出，每个K＝0的时刻均可以视为消息循环获取周期的起点，从而可以实现消息循环获取周期的叠加。在每个消息循环获取周期内，每条消息都有机会被获取K次，也即在首次被获取的基础上，被重复获取K次，换句话说，每个a时间段内的消息都有机会被客户端重复获取K次(如图中的消息11，在服务端响应t2时刻的请求后，消息11首次被获取，在后面的t3和t4时刻之后又重复被获取2次)，本发明实施例将这种获取方式称为冗余获取。此外，每个a时间段的消息的最大序号延迟K*a时间后才被客户端发往服务端用于更新ackid，本发明实施例将这种方式称为延迟确认。由于每条消息有唯一且自增的id，客户端在获取到消息后会和本地比对，本地存在的消息丢弃，不存在的消息才予以保留，消息在客户端的展示顺序也是基于消息id的顺序，本发明实施例将这种方式称为基于唯一序号去重。

本发明实施例在客户端与服务端进行交互的过程中，采用冗余获取、延迟确认以及基于唯一序号去重相结合的方式，使得因消息乱序写入数据库或其他情况导致新消息通知乱序到达客户端，或新消息通知因为某些原因丢失的情况下，依然能保证服务器和客户端状态最终一致，即消息不乱序、不重复以及不丢失，提升即时通信系统的可靠性和准确性。

图5为本发明实施例提供的再一种消息获取方法的流程示意图，在上述各可选实施例基础上，针对向服务端反馈最大消息序号的技术细节进行优化。

示例性的，所述向所述服务端反馈所述最大消息序号，包括：判断所述最大消息序号是否大于本地确认序号，其中，所述本地确认序号与当前服务端存储的确认序号一致；若大于，则将向所述服务端反馈所述最大消息序号，并将所述本地确认序号更新为所述最大消息序号。这样设置的好处在于，在有必要更新时才向服务端反馈最大消息序号，减少数据交互。

进一步的，在向服务端发起消息获取请求，并记录本次请求的发起时间之前，还包括：获取所述服务端中存储的确认序号，并将所获取到的确认序号记为本地确认序号。这样设置的好处在于，可以保证本地确认序号的准确性。

可选的，所述获取所述服务端中存储的确认序号，包括：检测到所述客户端启动后，获取所述服务端中存储的确认序号。这样设置的好处在于，在客户端启动时及时获取确认序号，进一步保证本地确认序号的准确性。

示例性的，该方法可包括：

步骤501、检测到客户端启动时，获取服务端中存储的确认序号，并将所获取到的确认序号记为本地确认序号。

步骤502、向服务端发起消息获取请求，并记录本次请求的发起时间。

步骤503、接收服务端返回的消息，并记录所接收到的消息中的最大消息序号。

步骤504、以预设获取周期向服务端重复发起预设次数的消息获取请求，接收服务端返回的消息，并根据消息序号对已接收到的消息进行去重处理。

步骤505、从发起时间起经过预设时长后，判断发起时间对应的最大消息序号是否大于本地确认序号，若是，则执行步骤506；否则，返回执行步骤502。

步骤506、向服务端反馈最大消息序号，并将本地确认序号更新为最大消息序号，返回执行步骤502。

本发明实施例在在上述实施例中的采用冗余获取、延迟确认以及基于唯一序号去重相结合的方式基础上，在客户端启动时获取服务端的确认序号并记录到客户端本地，在向服务端发送最大消息序号之前，判断最大消息序号是否大于本地确认序号，若大于，则发送最大消息序号，从而在有必要更新时才向服务端反馈最大消息序号，减少数据交互。

图6为本发明实施例提供的另一种消息获取方法的流程示意图，在上述各可选实施例基础上，针对客户端较长时间未上线的情况进行优化。

示例性的，在向服务端发起消息获取请求，并记录本次请求的发起时间之前，还包括：检测到所述客户端启动时，向所述服务端发起消息获取请求，并接收所述服务端返回的消息；判断所接收到的消息的总数量是否大于预设阈值，若大于，则确定目标确认序号；向所述服务端发送所述目标确认序号，其中，所述目标确认序号用于指示所述服务端将所述确认序号更新为所述目标确认序号，所述目标确认序号小于所接收到的消息中的最大消息序号。这样设置的好处在于，更合理地更新服务端的确认序号。

进一步的，所述确定目标确认序号，可包括：获取所述服务端返回消息时的回包时间戳；筛选出所接收到的消息中的目标消息，其中，所述目标消息中的消息时间戳与所述预设时长的和小于或等于所述回包时间戳；将所述目标消息中的最大消息序号确定为目标确认序号。这样设置的好处在于，更加合理地确定目标确认序号。

可选的，该方法包括：

步骤601、检测到客户端启动时，向服务端发起消息获取请求，并接收服务端返回的消息。

步骤602、判断所接收到的消息的总数量是否大于预设阈值，若是，则执行步骤603；否则，执行步骤606。

示例性的，若用户一段时间内未使用客户端，则服务端会积压较多未读消息，因此，可以通过判断消息总数量是否大于预设阈值来确定是否存在这种情况。预设阈值可以根据实际需求设置，具体不做限定。

步骤603、获取服务端返回消息时的回包时间戳，筛选出所接收到的消息中的目标消息。

其中，目标消息中的消息时间戳与预设时长的和小于或等于回包时间戳。

示例性的，客户端每次请求服务器得到的回包中都包含有一个服务器当前的时间戳，此处称为回包时间戳，可记为t。在获取积压消息结束后，可以取出每条消息中的时间戳msg_t，也即消息时间戳。假设预设时长为K*a，则目标消息即为msg_t+K*a小于t的消息。

步骤604、将目标消息中的最大消息序号确定为目标确认序号，并向服务端发送目标确认序号。

其中，目标确认序号用于指示服务端将确认序号更新为目标确认序号。

可以理解的是，服务端将确认序号更新为目标确认序号后，对于msg_t+K*a大于或等于t的消息，将会得到重复获取，保证这些消息被成功获取的概率。

步骤605、将目标确认序号记为本地确认序号，执行步骤607。

步骤606、获取服务端中存储的确认序号，并将所获取到的确认序号记为本地确认序号。

步骤607、向服务端发起消息获取请求，并记录本次请求的发起时间。

步骤608、接收服务端返回的消息，并记录所接收到的消息中的最大消息序号。

步骤609、以预设获取周期向服务端重复发起预设次数的消息获取请求，接收服务端返回的消息，并根据消息序号对已接收到的消息进行去重处理。

步骤610、从发起时间起经过预设时长后，判断发起时间对应的最大消息序号是否大于本地确认序号，若是，则执行步骤611；否则，返回执行步骤607。

步骤611、向服务端反馈最大消息序号，并将本地确认序号更新为最大消息序号。

本发明实施例在在上述实施例基础上，针对客户端较长时间未上线的情况进行优化，若确定积压未读消息较多，则可以将距离当前时刻较近的几条未读消息作为重复获取的目标，确定目标确认序号并反馈给服务端进行确认序号的更新，以便在后续的消息获取过程中，能够重复获取近期消息，保证近期消息被成功获取。

图7为本发明实施例提供的一种消息获取装置的结构框图，该装置可由软件和/或硬件实现，一般可集成在作为客户端的计算机设备中，可通过执行消息获取方法来进行消息获取。如图7所示，该装置包括：

发起时间记录模块701，用于向服务端发起消息获取请求，并记录本次请求的发起时间，其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置；

最大消息序号记录模块702，用于接收所述服务端返回的消息，并记录所接收到的消息中的最大消息序号；

消息重复获取模块703，用于重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息；

最大消息序号反馈模块704，用于从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号，其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔。

本发明实施例提供的消息获取装置，向服务端发起消息获取请求，并记录本次请求的发起时间，消息获取请求用于指示服务端返回消息序号大于其存储的确认序号的消息，接收服务端返回的消息，并记录所接收到的消息中的最大消息序号，重复向服务端发起消息获取请求并接收服务端返回的消息，从发起时间起经过预设时长后，向服务端反馈所述最大消息序号，指示服务端将确认序号更新为最大消息序号。通过采用上述技术方案，客户端在接收到服务端返回的消息后，先记录下最大消息号，但暂不向服务端反馈该最大消息号，而是经过一段时间后再反馈，在所经过的这段时间内，重复向服务端发起消息获取请求，由于服务端的确认序号未发生变化，因此，部分消息会被重复返回，能够提高消息被成功获取的概率，实现消息的冗余获取，有效解决客户端的消息获取缺失问题。

本发明实施例提供了一种计算机设备，该计算机设备中可集成本发明实施例提供的消息获取装置。图8为本发明实施例提供的一种计算机设备的结构框图。计算机设备800包括存储器801、处理器802及存储在存储器801上并可在处理器802上运行的计算机程序，所述处理器802执行所述计算机程序时实现本发明实施例提供的消息获取方法。

本发明实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行本发明实施例提供的消息获取方法。

上述实施例中提供的消息获取装置、设备以及存储介质可执行本发明任意实施例所提供的消息获取方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的消息获取方法。

注意，上述仅为本发明的较佳实施例。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由权利要求范围决定。

Claims (12)

1.一种消息获取方法，其特征在于，应用于客户端，包括：

向服务端发起消息获取请求，并记录本次请求的发起时间，其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置；

接收所述服务端返回的消息，并记录所接收到的消息中的最大消息序号；

重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息；

从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号，其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔。

2.根据权利要求1所述的方法，其特征在于，所述重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息，包括：

以预设获取周期向所述服务端重复发起预设次数的消息获取请求，并接收所述服务端返回的消息。

3.根据权利要求2所述的方法，其特征在于，所述预设时长为所述预设获取周期的倍数，所述倍数大于或等于所述预设次数。

4.根据权利要求1所述的方法，其特征在于，所述向所述服务端反馈所述最大消息序号，包括：

判断所述最大消息序号是否大于本地确认序号，其中，所述本地确认序号与当前服务端存储的确认序号一致；

若大于，则将向所述服务端反馈所述最大消息序号，并将所述本地确认序号更新为所述最大消息序号。

5.根据权利要求4所述的方法，其特征在于，在向服务端发起消息获取请求，并记录本次请求的发起时间之前，还包括：

获取所述服务端中存储的确认序号，并将所获取到的确认序号记为本地确认序号。

6.根据权利要求5所述的方法，其特征在于，所述获取所述服务端中存储的确认序号，包括：

检测到所述客户端启动时，获取所述服务端中存储的确认序号。

7.根据权利要求2所述的方法，其特征在于，在向服务端发起消息获取请求，并记录本次请求的发起时间之前，还包括：

检测到所述客户端启动时，向所述服务端发起消息获取请求，并接收所述服务端返回的消息；

判断所接收到的消息的总数量是否大于预设阈值，若大于，则确定目标确认序号，其中，所述目标确认序号小于所接收到的消息中的最大消息序号；

向所述服务端发送所述目标确认序号，其中，所述目标确认序号用于指示所述服务端将所述确认序号更新为所述目标确认序号。

8.根据权利要求7所述的方法，其特征在于，所述确定目标确认序号，包括：

获取所述服务端返回消息时的回包时间戳；

筛选出所接收到的消息中的目标消息，其中，所述目标消息中的消息时间戳与所述预设时长的和小于或等于所述回包时间戳；

将所述目标消息中的最大消息序号确定为目标确认序号。

9.根据权利要求1所述的方法，其特征在于，在所述重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息之后，或者，在每次发起消息获取请求并接收所述服务端返回的消息之后，还包括：

根据消息序号对已接收到的消息进行去重处理。

10.一种消息获取装置，其特征在于，配置于客户端，包括：

发起时间记录模块，用于向服务端发起消息获取请求，并记录本次请求的发起时间，其中，所述消息获取请求用于指示所述服务端返回消息序号大于确认序号的消息，所述确认序号存储于所述服务端中，所述消息序号由所述服务端根据消息接收顺序进行递增配置；

最大消息序号记录模块，用于接收所述服务端返回的消息，并记录所接收到的消息中的最大消息序号；

消息重复获取模块，用于重复向所述服务端发起消息获取请求，并接收所述服务端返回的消息；

最大消息序号反馈模块，用于从所述发起时间起经过预设时长后，向所述服务端反馈所述最大消息序号，其中，所述最大消息序号用于指示所述服务端将所述确认序号更新为所述最大消息序号，所述预设时长大于从所述发起时间到首次重复发起消息获取请求之间的时间间隔。

11.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1-9任一项所述的方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-9中任一所述的方法。

Images