CN112100556A - 优化消息推送方式的方法及其系统 - Google Patents

Abstract

本申请提供优化消息推送方式的方法及其系统，方法包括：S1：客户端与服务端建立长链接；S2：服务端发送消息至客户端之前，判断客户端是否被记录在延迟名单中；若是，则执行S3步骤：S3：延迟预设时长发送所述消息，返回执行S2步骤；S4：客户端接收消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；S5：服务端接收消息延迟发送状态码，记录客户端至延迟名单；S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。本发明能够针对客户端的资源动态地控制接收消息的效率，有效避免推送系统或应用崩溃。

Description

优化消息推送方式的方法及其系统

技术领域

本发明涉及消息推送领域，具体涉及优化消息推送方式的方法及其系统。

背景技术

移动互联网蓬勃发展的今天，大部分手机APP都提供有消息推送功能，如新闻客户端的热点新闻推荐、IM工具的聊天消息提醒、电商产品促销信息、企业应用的通知和审批流程等等。推送对于提高产品活跃度、提高功能模块使用率、提升用户粘性、提升用户留存率起到了重要作用。

消息推送的主要实现流程为：客户端预先访问服务端路由地址列表接口，获取可以正常接入的路由地址，选择其中一个地址进行长链接的建立。当成功建立起长链接之后，服务端与客户端将会进行正常的消息通讯。一般情况下是服务端把对应的消息通过上述长链接发送至客户端；客户端接收到消息后，会返回成功或者失败的服务端状态码；当失败场景下，服务端会执行重试策略，直至客户端成功接收消息为止。

正常场景之下，当客户端资源足够时，服务端发送的消息能够正常发送至客户端，并且客户端也能正常返回状态码。而当客户端资源不足时，服务端如有大量的推送消息继续向下推送，将会导致如下问题(该问题存在的前提条件为长链接的正常建立)：1、客户端未能够正常接收推送消息，并且无法返回成功状态码，而后续服务端会继续并且重复执行消息推送，此时，将会继续增大客户端的处理压力，由于客户端资源不足，最终将导致推送功能奔溃。2、客户端能够正常接收推送消息，并响应成功状态码，此时，由于待推送消息众多，服务端将会继续执行推送，客户端被迫继续处理推送消息，此时客户端资源已经不足，继续处理消息最终将导致推送功能奔溃。

因此，有必要对上述推送方法进行优化。

发明内容

本发明所要解决的技术问题是：提供优化消息推送方式的方法及其系统，能够灵活控制消息推送速率，有效防止应用崩溃。

为了解决上述技术问题，本发明采用的技术方案为：

优化消息推送方式的方法，包括：

S1：客户端与服务端建立长链接；

S2：服务端发送消息至客户端之前，判断所述客户端是否被记录在延迟名单中；若是，则执行S3步骤：

S3：延迟预设时长发送所述消息，返回执行S2步骤；

S4：客户端接收所述消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

S5：服务端接收所述消息延迟发送状态码，记录对应的客户端至延迟名单；

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

本发明提供的另一个技术方案为：

优化消息推送方式的系统，包括：

服务端；

客户端；

计算机程序，所述计算机程序被分配成由所述服务端和所述客户端执行以下步骤：

S1：客户端与服务端建立长链接；

S2：服务端发送消息至客户端之前，判断所述客户端是否被记录在延迟名单中；若是，则执行S3步骤：

S3：延迟预设时长发送所述消息，返回执行S2步骤；

S4：客户端接收所述消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

S5：服务端接收所述消息延迟发送状态码，记录对应的客户端至延迟名单；

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

本发明的有益效果在于：本发明通过在客户端设置待处理消息数量阈值，在每次接收消息时进行判断，若超出阈值，则将消息延迟发送状态码作为返回码，以使服务端将自身列入消息延迟名单；客户端将在本地积压消息全部处理后及时通知服务端将自身移出延迟名单；而服务端每间隔一个延迟周期都以名单为依据判断是否继续延迟。通过上述方式，能够在客户端资源不足时，通过返回码来控制服务端的消息推送速率，并在资源充足后即可恢复正常，以此有效防止客户端超负荷而引发应用崩溃；进而提升客户端推送系统和应用的稳定性。

附图说明

图1为本发明一实施例一种优化消息推送方式的方法的流程示意图。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于:客户端依据处理消息数量阈值判断是否将自己列入服务端的延迟消息推送名单，并在堆积消息处理完毕后及时通知服务端将自己移出名单；而服务端依据名单每个延迟周期判断是否恢复正常推送。

请参照图1，本发明提供优化消息推送方式的方法，包括：

S1：客户端与服务端建立长链接；

S2：服务端发送消息至客户端之前，判断所述客户端是否被记录在延迟名单中；若是，则执行S3步骤：

S3：延迟预设时长发送所述消息，返回执行S2步骤；

S4：客户端接收所述消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

S5：服务端接收所述消息延迟发送状态码，记录对应的客户端至延迟名单；

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

从上述描述可知，本发明的有益效果在于：能够在客户端资源不足时，通过返回码来控制服务端的消息推送速率，并在资源充足后即可恢复正常，以此有效防止客户端超负荷而引发应用崩溃；进而提升客户端推送系统和应用的稳定性。

进一步地，所述客户端接收所述消息，判断待处理的消息数量是否达到阈值，包括：

客户端接收所述消息，并将其存入本地队列；

统计本地队列的消息数量；

判断所述消息数量是否达到预设的阈值。

由上述描述可知，通过引入本地队列，可以对待处理消息进行统一、有序、准确而高效地管理，从而提高消息处理性能，减少错误。

进一步地，所述记录对应的客户端至延迟名单，包括：

记录所述消息延迟发送状态码对应的客户端的标识至服务端缓存中。

由上述描述可知，上述标识能够确定唯一的一个客户端，以记录标识的方式登记需要进行消息延迟的客户端，即保证对应性的准确无误，又能简化记录数据。

进一步地，还包括：

S7：当服务端接收到所述客户端发起的重新建立长链接的请求，则判断所述客户端是否被记录在延迟名单中，若是，则将所述客户端从延迟名单中移除。

由上述描述可知，若由于网络切换、断网等网络原因而导致需要重新建立长链接，则同步删除服务端中对应客户端的延迟记录，以确保客户端正常接收消息推送，真正的重连。

进一步地，所述S5步骤中的所述记录对应的客户端至延迟名单，之后，还包括：

设置所述客户端在所述延迟名单中的有效时长；

当所述客户端在所述延迟名单中的时间达到所述有效时长，则将所述客户端从延迟名单中移除。

由上述描述可知，设置合理的客户端在延迟名单中的失效时间，能避免客户端因故障而无法及时回复消息推送命令，从而导致消息推送功能永久失效。

本发明提供的另一个技术方案为：

优化消息推送方式的系统，包括：

服务端；

客户端；

计算机程序，所述计算机程序被分配成由所述服务端和所述客户端执行以下步骤：

S1：客户端与服务端建立长链接；

S2：服务端发送消息至客户端之前，判断所述客户端是否被记录在延迟名单中；若是，则执行S3步骤：

S3：延迟预设时长发送所述消息，返回执行S2步骤；

S4：客户端接收所述消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

S5：服务端接收所述消息延迟发送状态码，记录对应的客户端至延迟名单；

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

进一步的，所述客户端接收所述消息，判断待处理的消息数量是否达到阈值，包括：

客户端接收所述消息，并将其存入本地队列；

统计本地队列的消息数量；

判断所述消息数量是否达到预设的阈值。

进一步的，所述记录对应的客户端至延迟名单，包括：

记录所述消息延迟发送状态码对应的客户端的标识至服务端缓存中。

进一步的，还包括：

S7：当服务端接收到所述客户端发起的重新建立长链接的请求，则判断所述客户端是否被记录在延迟名单中，若是，则将所述客户端从延迟名单中移除。

进一步的，所述S5步骤中的所述记录对应的客户端至延迟名单，之后，还包括：

设置所述客户端在所述延迟名单中的有效时长；

当所述客户端在所述延迟名单中的时间达到所述有效时长，则将所述客户端从延迟名单中移除。

从上述描述可知，对应本领域普通技术人员可以理解实现上述技术方案中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来实现的，所述的程序可存储于一计算机可读取的存储介质中，该程序在执行时，可包括如上述各方法的流程。所述程序在被处理器执行后，同样能够实现对应各方法的有益效果。

其中，所述的存储介质可以是磁盘、光碟、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

实施例一

本实施例提供一种优化消息推送方式的方法，能够针对客户端的资源动态地控制接收消息的效率，从而有效避免推送系统或应用崩溃。

所述方法可以包括以下步骤：

S1：客户端与服务端建立长链接；

具体而言，通过客户端与服务端建立长链接，以使客户端能够正常接收推送消息。

S2：服务端发送消息至客户端之前，均会判断该客户端是否被记录在延迟名单中；若是，则执行S3步骤：若否，则执行S21；

S21：服务端正常发送消息至客户端；客户端接收推送消息后，优选将记录该消息至本地队列中，待后续线程任务顺序地处理队列中的消息。在此，通过本地队列存储待处理的消息，能够实现依据接收顺序，有序而高效地处理消息；同时也有利于对堆积的待处理消息数量进行准确地统计，为本实施例后续步骤提供支持。

S3：延长预设时长发送所述消息，返回执行S2步骤；

即，在每一次所述预设时长结束时，要发送消息之前，都将再次判断该客户端是否还被记录在延迟名单内，以明确是否还需要再次延迟，若是，则依照流程，需要继续延长发送时间，若不在延迟名单内，则可以正常发送消息至客户端。

S4：客户端每一次接收到服务端发来的消息，都将判断本地队列中待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

具体而言，客户端将预先针对客户端的消息处理能力，预设待处理的消息数量阈值。例如，当待处理的消息数超过30条后，如果继续增加消息数，将会有较大概率导致内存溢出，进而导致推送系统奔溃。因此，可以预设待处理的消息数量阈值为30，在超出该阈值时做出相应举措来有效预防。

当客户端接收到消息，都将统计本地队列的消息数量；判断所述消息数量是否达到预设的阈值；若未达到预设的阈值，则按照旧有逻辑正常处理该消息，并返回成功状态码；若达到预设的阈值，则客户端将放回消息延迟发送状态码至服务端。

另外，若客户端将所有待处理的消息处理完成，即清空了本地队列中的消息，则表示客户端又具有足够的资源来处理消息了，因此，客户端将及时地发送恢复发送命令至服务端，用于告知其可以正常发送消息至客户端了。

S5：服务端接收到客户端发来的消息延迟发送状态码后，记录对应的客户端至延迟名单；

可选的，所述延迟名单位于服务端缓存，数据格式为key,value格式，其中，key为消息延迟类型_客户端设备Id(由此可以确定唯一的一个客户端),value为1，表示需要延迟。

客户端被记录至延迟名单后，将不会再接收到服务端发来的推送消息，而会集中资源处理本地队列中的消息，以此高效完成堆积消息处理，并确保不会出现推送系统或应用崩溃。

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

客户端被移出延迟名单后，服务端将按照旧有逻辑推送消息至客户端。

S7：若服务端接收到所述客户端发起的重新建立长链接的请求，则判断所述客户端是否被记录在延迟名单中，若是，则将所述客户端从延迟名单中移除。

其中，重建长链接的情况包括网络切换、断网重连等。重新建立长链接由客户端进行控制。

在一具体实例中，所述S5步骤中的所述记录对应的客户端至延迟名单，之后，还包括：

设置该客户端在所述延迟名单中的有效时长；当该客户端在所述延迟名单中的时间达到所述有效时长，则自动将该客户端从延迟名单中移除。以此能够在客户端故障无法自动发送恢复发送命令时，避免客户端的推送功能失效。

实施例二

本实施例对应实施例一，提供一具体运用场景：

1、存在一个客户端APP与一套推送的服务端程序，APP与推送服务通过长链接进行通信服务。

2、正常场景下，服务端发送推送消息至客户端，由客户端预先记录在本地队列中，由专门的线程处理本地队列中的消息。

3、假设客户端本地队列中缓存消息未超过30条时，执行旧有推送消息处理逻辑。

4、当客户端本地队列中堆积消息超过30条时，按照本实施例的新处理逻辑进行处理。服务端推送消息至客户端时，旧有逻辑客户端将直接返回成功状态码(success)，而对应本实施例，客户端将返回延迟发送状态码(delay)。

5、服务端获取到delay状态码时，在服务端缓存中记录相关信息。缓存格式为key,value形式；其中，key为delay_客户端设备id,value可为1或者不设置。设置缓存过期时间为1小时。该缓存存在的意义为：每次推送消息前，预先查询该缓存是否存在，存在，则说明需要进行消息延迟发送；否则，则直接进行正常消息发送。

6、当步骤4中需要进行消息延迟发送时，服务端发送推送消息至延迟队列中，设置延迟时间为5分钟，待5分钟之后再次进行消息推送，并再次检查缓存信息，明确是否还需要再次延迟。如需要再次延迟，则继续延迟处理，否则直接发送消息。

7、当客户端本地队列已超过预设阀值后，经过步骤3，4，5处理后，客户端将不会再次接收推送消息，此时会集中资源处理本地队列中消息。当本地队列中消息已处理完毕后，客户端将发送恢复消息推送命令给服务端。

8、服务端接收到恢复消息推送命令后，将直接删除步骤4中的缓存记录，后续消息发送将按照旧有逻辑进行判断与发送。

9、当客户端与服务端断网或者网络切换需要重新建立起长链接时，由服务端同步删除步骤4中的缓存。

实施例三

本实施例对应实施例一和实施例二，提供优化消息推送方式的系统，包括：服务端；客户端；计算机程序，所述计算机程序被分配成由所述服务端和所述客户端执行上述实施例一或实施例二中包含的步骤。具体步骤内容在此不进行复述，详情请参阅实施例一或实施例二的记载。

综上所述，本发明提供的优化消息推送方式的方法及其系统，能够针对客户端的资源动态地控制接收消息的效率，不仅能有效避免推送系统或应用崩溃；而且能维持正常推送消息；能够对待处理消息进行统一管理，确保进行有序处理和准确统计；能够确保客户端在重连后能正常接收消息推送；能够确保客户端的消息推动功能正常。因此，本申请具备较高实用性。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.优化消息推送方式的方法，其特征在于，包括：

S1：客户端与服务端建立长链接；

S2：服务端发送消息至客户端之前，判断所述客户端是否被记录在延迟名单中；若是，则执行S3步骤：

S3：延迟预设时长发送所述消息，返回执行S2步骤；

S4：客户端接收所述消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

S5：服务端接收所述消息延迟发送状态码，记录对应的客户端至延迟名单；

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

2.如权利要求1所述的优化消息推送方式的方法，其特征在于，所述客户端接收所述消息，判断待处理的消息数量是否达到阈值，包括：

客户端接收所述消息，并将其存入本地队列；

统计本地队列的消息数量；

判断所述消息数量是否达到预设的阈值。

3.如权利要求1所述的优化消息推送方式的方法，其特征在于，所述记录对应的客户端至延迟名单，包括：

记录所述消息延迟发送状态码对应的客户端的标识至服务端缓存中。

4.如权利要求1所述的优化消息推送方式的方法，其特征在于，还包括：

S7：当服务端接收到所述客户端发起的重新建立长链接的请求，则判断所述客户端是否被记录在延迟名单中，若是，则将所述客户端从延迟名单中移除。

5.如权利要求1所述的优化消息推送方式的方法，其特征在于，所述S5步骤中的所述记录对应的客户端至延迟名单，之后，还包括：

设置所述客户端在所述延迟名单中的有效时长；

当所述客户端在所述延迟名单中的时间达到所述有效时长，则将所述客户端从延迟名单中移除。

6.优化消息推送方式的系统，其特征在于，包括：

服务端；

客户端；

计算机程序，所述计算机程序被分配成由所述服务端和所述客户端执行以下步骤：

S1：客户端与服务端建立长链接；

S2：服务端发送消息至客户端之前，判断所述客户端是否被记录在延迟名单中；若是，则执行S3步骤：

S3：延迟预设时长发送所述消息，返回执行S2步骤；

S4：客户端接收所述消息，判断待处理的消息数量是否达到阈值；若是，则返回消息延迟发送状态码至服务端，并在所有待处理的消息处理完成后发送恢复发送命令至服务端；若否，则返回成功状态码；

S5：服务端接收所述消息延迟发送状态码，记录对应的客户端至延迟名单；

S6：若服务端接收到恢复发送命令，则将对应的客户端从延迟名单中移除。

7.如权利要求6所述的优化消息推送方式的系统，其特征在于，所述客户端接收所述消息，判断待处理的消息数量是否达到阈值，包括：

客户端接收所述消息，并将其存入本地队列；

统计本地队列的消息数量；

判断所述消息数量是否达到预设的阈值。

8.如权利要求6所述的优化消息推送方式的系统，其特征在于，所述记录对应的客户端至延迟名单，包括：

记录所述消息延迟发送状态码对应的客户端的标识至服务端缓存中。

9.如权利要求6所述的优化消息推送方式的系统，其特征在于，还包括：

S7：当服务端接收到所述客户端发起的重新建立长链接的请求，则判断所述客户端是否被记录在延迟名单中，若是，则将所述客户端从延迟名单中移除。

10.如权利要求6所述的优化消息推送方式的系统，其特征在于，所述S5步骤中的所述记录对应的客户端至延迟名单，之后，还包括：

设置所述客户端在所述延迟名单中的有效时长；

当所述客户端在所述延迟名单中的时间达到所述有效时长，则将所述客户端从延迟名单中移除。

Images