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

Abstract

本申请涉及通信技术领域，尤其涉及一种消息处理方法、装置、电子设备及存储介质，接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识；当所述多个接收方的数目超过预设数目阈值，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中；当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方，这样，单独维护一个群体级别的多人通知消息流，多人通知消息独立管理，提高消息处理效率和速度，减少并发写入和存储压力。

Description

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

技术领域

本申请涉及通信技术领域，尤其涉及一种消息处理方法、装置、电子设备及存储介质。

背景技术

随着通信技术发展，用户可以很方便地通过即时通讯(Instant Messaging，IM)应用进行消息通信，现有的消息逻辑处理，主要是每个用户都有自己的个人消息流，用户可以从个人消息流中获取消息，对于多人通知消息的变更和触达，也是通过个人消息流实现，例如多人通知消息为企业消息等。

但是通常多人通知消息例如企业消息的变更和触发，同时有大量成员需要触达，这样，就需要轮询逐个给各个成员推送，并且需要写的数据也越多，对于同一份数据，需要复制多份到不同成员的个人消息流内，效率较低也浪费存储资源，并且在多人通知消息变更时，因为不同的变更可能涉及的用户较多，多次变更，也无法保证每个成员的个人消息流内的消息都是按照固定顺序写入的，不可控，容易出现错误或发送不及时等问题。

发明内容

本申请实施例提供一种消息处理方法、装置、电子设备及存储介质，以提高消息处理效率。

本申请实施例提供的具体技术方案如下：

本申请一个实施例中提供了一种消息处理方法，包括：

接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识；

当所述多个接收方的数目超过预设阈值，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，其中，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方。

本申请另一个实施例中提供了一种消息处理方法，包括：

按照设定周期向服务器发送多人通知消息获取请求，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息获取请求中至少携带群体标识，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

接收所述服务器返回的多人通知消息，所述多人通知消息是所述服务器当所述多人通知消息对应的多个接收方的数目超过预设阈值，从对应所述群体标识维护的多人通知消息流中获取的，所述多人通知消息中至少包括群体标识，以及所述多人通知消息是由发送方发送至所述服务器后，由所述服务器存储在对应所述群体标识维护的多人通知消息流中的。

本申请另一个实施例中提供了一种消息处理装置，包括：

第一接收模块，用于接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识；

第一存储模块，用于当所述多个接收方的数目超过预设阈值，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，其中，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

第一发送模块，用于当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方。

本申请另一个实施例中提供了一种消息处理装置，包括：

发送模块，用于按照设定周期向服务器发送多人通知消息获取请求，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息获取请求中至少携带群体标识，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

接收模块，用于接收所述服务器返回的多人通知消息，所述多人通知消息是所述服务器当所述多人通知消息对应的多个接收方的数目超过预设阈值，从对应所述群体标识维护的多人通知消息流中获取的，所述多人通知消息中至少包括群体标识，以及所述多人通知消息是由发送方发送至所述服务器后，由所述服务器存储在对应所述群体标识维护的多人通知消息流中的。

本申请另一个实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一种消息处理方法的步骤。

本申请另一个实施例中提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一种消息处理方法的步骤。

本申请实施例中，接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识，并当所述多个接收方的数目超过预设阈值，则将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，进而当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方，这样，针对多人通知消息，通过群体标识单独维护一个群体级别的多人通知消息流，接收到多人通知消息时，不需要复制多份到各个用户，而只需要写一份到多人通知消息流中即可，减少并发写入和存储压力，也提高了效率和处理速度，多人通知消息和个人消息分开，接收方只需要一次数据拉取就可以获取到多人通知消息，也可以更好地顺序控制多人通知消息，保证各个用户能够顺序获取到同样的数据。

附图说明

图1为本申请实施例中消息处理方法的应用架构示意图；

图2为本申请实施例中一种消息处理方法流程图；

图3为本申请实施例中多人通知消息类型示例图；

图4为本申请实施例中服务器下发多人通知消息的逻辑示意图；

图5为本申请实施例中另一种消息处理方法流程图；

图6为相关技术中消息处理方法的逻辑原理示意图；

图7为本申请实施例中消息处理方法的逻辑原理示意图；

图8为本申请实施例中一种消息处理装置结构示意图；

图9为本申请实施例中另一种消息处理装置结构示意图；

图10为本申请实施例中电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，并不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例，主要针对多人通知消息的处理逻辑，提供了一种新的消息处理方法，可以根据消息所对应的接收方的数目，将多人通知消息和个人消息的处理逻辑独立分开，分别对应维护多人通知消息流和个人消息流，对于多人通知消息，根据群体标识对应维护多人通知消息流，具体地，服务器接收发送方发送的多人通知消息，其中，多人通知消息中至少包括群体标识，并当多个接收方的数目超过预设阈值，将多人通知消息存储在对应群体标识维护的多人通知消息流中，进而当接收到接收方按照设定周期发送的至少携带群体标识的多人通知消息获取请求时，将多人通知消息流中的多人通知消息发送给接收方，这样，对于接收方的数目超过预设阈值的多人通知消息，只需要写一份存储在对应的多人通知消息流中，仅在群体级别存储，减少并发写入压力和存储压力，也提升了速度和效率，接收方只需要一次数据拉取就可以触达，多人通知消息与个人消息分开，并且通过多人通知消息流对多人通知消息统一管理，一个多人通知消息流中各个多人通知消息通过消息标识唯一区别，也可以更好地顺序控制多人通知消息，保证群体中各成员用户可以获取到相同的消息。

参阅图1所示，为本申请实施例中消息处理方法的应用架构示意图，包括发送方100、接收方200和服务器300。

发送方100和接收方200为消息交互的客户端，可以是智能手机、平板电脑、便携式个人计算机、台式计算机、智能电视、智能机器人、车载电子设备等任何智能设备，智能设备中可以安装有各种即时通讯应用程序(Application，APP)，例如一些企业即时通讯APP等，本申请实施例中，可以通过即时通讯应用程序，创建团队、企业、聊天群等，进而一个群体的成员之间可以进行消息交互，也可以发送多人通知消息。

服务器300能够为发送方100和接收方200提供各种网络服务，对于不同的应用程序，服务器300可以认为是相应的后台服务器，例如，本申请实施例中，发送方100可以发送多人通知消息，服务器300接收到多人通知消息后，当多个接收方的数目超过预设阈值，将多人通知消息存储在对应维护的多人通知消息流中，接收方200的客户端可以定期拉取多人通知消息，进而当接收到接收方200发送的多人通知消息获取请求时，将对应的多人通知消息流中的多人通知消息发送给该接收方200。

其中，服务器300可以是一台服务器、若干台服务器组成的服务器集群或云计算中心。

发送方100与服务器300，以及接收方200与服务器300之间可以通过互联网相连，实现相互之间的通信。可选地，上述的互联网使用标准通信技术和/或协议。互联网通常为因特网、但也可以是任何网络，包括但不限于局域网(Local Area Network，LAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合。在一些实施例中，使用包括超文本标记语言(Hyper Text Mark-up Language，HTML)、可扩展标记语言(Extensible MarkupLanguage，XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer，SSL)、传输层安全(Transport Layer Security，TLS)、虚拟专用网络(Virtual Private Network，VPN)、网际协议安全(Internet ProtocolSecurity，IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

需要说明的是，本申请实施例中的应用架构图是为了更加清楚地说明本申请实施例中的技术方案，并不构成对本申请实施例提供的技术方案的限制，也可以应用于任何即时通讯的应用场景，例如企业消息、群消息等，并不进行限制，对于其它的应用架构和业务应用，本申请实施例提供的技术方案对于类似的问题，同样适用。

本申请各个实施例中，以消息处理方法应用于图1所示的应用架构为例进行示意性说明。

基于上述实施例，参阅图2所示，为本申请实施例中一种消息处理方法流程图，应用于服务器侧，具体该方法包括：

步骤200：接收发送方发送的多人通知消息，其中，多人通知消息表示向多个接收方发送的消息，并多个接收方具有同一群体标识，多人通知消息中至少包括群体标识。

其中，本申请实施例中多人通知消息流，例如为企业消息流、群消息流等，根据群体维度，有序存储，即每个群体标识对应维护一个多人通知消息流，当群体数据变化，需要对群体中所有用户进行推送而产生的一条消息流，每个群体内的用户可以定期去获取多人通知消息以方便更新群体级的消息变更。

并且，本申请实施例中，每个多人通知消息流中的每个多人通知消息都具有一个消息标识，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的，多人通知消息顺序可控。

本申请实施例中的消息处理方法，可以应用于所有需要通知的企业级、或者其它大规模群体级别的多人消息通知，当需要通知的接收方为一个群体，可以发送多人通知消息，多人通知消息中至少群体标识，进而服务器可以针对群体标识，仅在以群体标识为维度的数据内进行变更读写以及消息控制。

步骤210：当多个接收方的数目超过预设阈值，将多人通知消息存储在对应群体标识维护的多人通知消息流中，其中，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识。

本申请实施例中，针对每个群体标识对应维护一个多人通知消息流，即可以在群体维度上有序存储各个多人通知消息，并且，每个多人通知消息对应有一个消息标识，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的，可以保证多人通知消息的有序性。

具体地执行步骤210时，包括：

1)确定对应群体标识维护的多人通知消息流中已存储的多人通知消息的消息标识。

2)根据已存储的多人通知消息的消息标识的生成规则，生成多人通知消息的消息标识，并将多人通知消息按照时间顺序存储在群体标识对应维护的多人通知消息流中。

其中，生成规则例如为按照预设步长递增，本申请实施例中并不进行限制，例如预设步长为1，群体标识a对应维护的多人通知消息流中已存储有多人通知消息1，多人通知消息2，…，多人通知消息99，则新接收到的群体标识a的多人通知消息时，可以生成该多人通知消息的消息标识为100，并将该多人通知消息100顺序存储在群体标识a的多人通知消息流中。

另外，本申请实施例中多人通知消息类型并不进行限制，例如，参阅图3所示，为本申请实施例中多人通知消息类型示例图，如图3所示，多人通知消息的类型可以为普通文本消息、应用消息、控制消息等，当然也可以包括其它类型的多人通知消息，对此并不进行限制。

这样，本申请实施例中，服务器写存储时仅需要更新以群体维度维护的一块多人通知消息存储，无需复制多份到各个群体内用户的个人消息流，减少对群体内各个用户的同样消息的插入，减少存储空间浪费，全群体统一存储群体级消息数据，并且因为一个群体只需维护一个多人通知消息流，一个多人通知消息流中的各个多人通知消息可以通过消息标识来唯一辨识，因此这份数据内的消息数据顺序可控。

另外，本申请实施例中，接收到多人通知消息后，还可以判断多人通知消息对应的接收方的数目，当接收方的数目超过预设阈值，说明该多人通知消息所需要通知的用户较多，则可以存储在该多人通知消息中携带的群体标识所对应的多人通知消息流中，而无需分别复制下发到各个接收方的个人消息流中，减少写并发压力和写存储，进一步地，当接收方的数目不超过预设阈值，说明接收方数目较少，同时并发下发影响也不大，因此针对该情况本申请实施例中还提供了一种可能的实施方式：当多个接收方的数目不超过预设阈值，将多人通知消息分别存储在群体标识对应群体中的各个接收方的个人消息流中，并将多人通知消息分别发送给各个接收方。

这样，对于接收方数目较少的多人通知消息，可以直接分发到各个接收方的个人消息流中，可以保证消息及时触达。

步骤220：当接收到接收方按照设定周期发送的至少携带群体标识的多人通知消息获取请求时，将多人通知消息流中的多人通知消息发送给接收方。

执行步骤220时，具体包括：

S1、接收接收方按照设定周期发送的多人通知消息获取请求，其中，多人通知消息获取请求中至少携带群体标识和上一次获取到的最后一个多人通知消息的消息标识。

本申请实施例中，接收方的客户端增加一个拉取多人通知消息的消息行为交互，可以按照设定周期来主动拉取，其中，设定周期的时间间隔可以根据后台服务器配置调整，并不进行限制。

接收方每次发送多人通知消息获取请求时，需要携带上一次发送多人通知消息获取请求时获取到的最后一个多人通知消息的消息标识，也即最大的消息标识。

S2、确定群体标识对应的多人通知消息流中，存储有符合预设条件的多人通知消息时，将符合预设条件的多人通知消息发送给接收方，其中，预设条件包括：消息标识大于上一次获取到的最后一个多人通知消息的消息标识。

例如，多人通知消息获取请求中的上一次获取到的最后一个多人通知消息的消息标识为last-max，服务器判断对应的多人通知消息流中有群体标识大于该last-max时，则认为数据需要更新，服务器可以下发从上次更新后最新的多人通知消息。

并且，服务器在下发多人通知消息时，可以整体下发多条多人通知消息，服务器可以设置最大下发的数目阈值，这样也可以提高消息下发效率，具体地，将符合预设条件的多人通知消息发送给接收方时，本申请实施例中还提供了一种可能的实施方式：

在符合预设条件的多人通知消息中，按照消息标识的排序，读取不超过预设数目阈值的多人通知消息；将读取到的多人通知消息发送给接收方。

例如，接收方在打开即时通讯APP时，才会拉取多人通知消息，可能某用户很长时间每次打开手机或打开该即时通讯APP，则可能就会有很多多人通知消息待拉取；又例如，多人通知消息更新速度较快，而接收方定期拉取多人通知消息，则可能接收方在拉取时，可能也会有很多多人通知消息待拉取，这时，服务器可以根据预设数目阈值同时下发多条多人通知消息。

具体例如参阅图4所示，为本申请实施例中服务器下发多人通知消息的逻辑示意图，接收方的客户端发送的多人通知消息获取请求中上一次获取到的最后一个多人通知消息的消息标识为last-max 100，多人通知消息流中存储的有多人通知消息1，多人通知消息2，…，多人通知消息100，多人通知消息101，多人通知消息102，…，多人通知消息144，预设数目阈值为20，大于last-max100的多人通知消息有44个，则可以将多人通知消息101，多人通知消息102，…，多人通知消息120下发给接收方。

当然，本申请实施例中，也可以不设置每次下发的最大数目阈值，而是每次都将最新的多人通知消息下发给接收方，具体可以根据实际情况设置，本申请实施例中并不进行限制。

这样，本申请实施例中，服务器根据企业维度有序存储多人通知消息，并且根据上次下发的多人通知消息而顺序下发最新的多人通知消息。

进一步地，本申请实施例中，服务器在下发多人通知消息时，还可以结合其它方式实现消息发送逻辑，例如，服务器可以通过分析用户的用户习惯以及用户画像等，确定用户对哪些更新的多人通知消息感兴趣，并且可以优先向接收方发送这些用户更感兴趣的多人通知消息，提高用户的可读性和消息发送的准确性，又例如，在进行推送时，可以确定出用户更感兴趣的多人通知消息，并将这些确定出的多人通知消息置顶或高亮推送给用户，而其余的多人通知消息则可以折叠推送，这样选择性下发消息，更加灵活，适用于更多业务场景。

进一步地，本申请实施例中，由于是对多人通知消息进行统一管理，因此还可以将接收到的所有多人通知消息缓存到同一服务器，具体的，由于是群体级别的数据变更，数据在一定时间内，全群体变更的数据是一致的，因此在某个时间段内，对于某群体变更下发的多人通知消息，可以根据统一路有逻辑，后台服务器进行有效的缓存，可以先缓存到同一服务器即存储路径下，这样，当接收到多人通知消息获取请求时，可以直接由该服务器统一下发缓存数据，而不需要再走其它存储逻辑，可以更好保护后端的数据模块，尤其在密集型多人通知消息的数据变更期间，可以有效保护接收方的客户端的数据过载，以及保护后端服务器的多人通知消息的突然拉取，并且也可以提高下发效率。

另外，需要说明的是，本申请实施例中针对个人消息，还是通过维护个人消息流来实现，个人消息流表示个人消息的流水，根据个人维度存在，每个用户可以从自己的消息存储内获取个人消息流，本申请实施例中，个人消息流和多人通知消息流是两个独立的处理逻辑，多人通知消息是接收方按照一定间隔来获取，个人消息及时触达，而在某些多人通知消息变化不敏感的场景下，群体的变化数据其实是可以稍落后于个人消息数据触达，因此，可以通过控制多人通知消息的获取间隔，在传统意义的消息通知的逻辑外，多人通知消息只需要保证在固定时间段内用户可以进行更新即可，并且在更多较频繁时，还可以通过合并一定时间段内的多人通知消息，作为一条多人通知消息来下发，进行偶发的延缓下发多人通知消息的能力，而保证用户个人消息的及时触达。

进一步地，针对个人消息的处理逻辑，本申请实施例中还提供了一种可能的实施方式：接收发送方发送的个人消息，其中，个人消息中至少包括接收方标识；将个人消息存储在接收方标识对应的个人消息流中，并将个人消息发送给接收方标识对应的接收方。

即本申请实施例中，每个用户对应维护一个个人消息流，接收到个人消息时，可以向接收方触发消息通知机制，进而接收方可以接收到通知消息后，及时向服务器拉取个人消息，保证个人消息的及时性，另外对于多人通知消息，本申请实施例中可以不设置通知机制，接收方定期拉取即可，但是也可以根据多人通知消息的重要程度，对于一些重要程度很高或比较紧急的多人通知消息，则也可以触发通知机制。

本申请实施例中，接收发送方发送的多人通知消息，其中，多人通知消息中至少包括群体标识，并当多个接收方的数目超过预设阈值，将多人通知消息存储在对应群体标识维护的多人通知消息流中，进而当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将多人通知消息流中的多人通知消息发送给接收方，这样，将原来不可控的、糅合了个人消息数据的多人通知消息，提取出来，进行单独的存储和处理，减少跟个人消息的耦合，提高了多人通知消息的到达率和效率，并且为多人通知消息提供了更多的稳定性，提高了日后多元化多人通知消息的扩展性。

基于上述实施例，参阅图5所示，为本申请实施例中另一种消息处理方法流程图，应用于接收方的客户端，具体包括：

步骤500：按照设定周期向服务器发送多人通知消息获取请求，多人通知消息表示向多个接收方发送的消息，并多个接收方具有同一群体标识，多人通知消息获取请求中至少携带群体标识，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识。

其中，多人通知消息获取请求中还至少携带上一次获取到的最后一个多人通知消息的消息标识。

并且设定周期也可以根据实际情况进行设置，相对于个人消息而言，可以通过后台服务器调整周期间隔以降低多人通知消息的获取优先级。

步骤510：接收服务器返回的多人通知消息，多人通知消息是服务器当多人通知消息对应的多个接收方的数目超过预设阈值，从对应群体标识维护的多人通知消息流中获取的，多人通知消息中至少包括群体标识，以及多人通知消息是由发送方发送至服务器后，由服务器存储在对应群体标识维护的多人通知消息流中的。

其中，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的。

则执行步骤510时，具体包括：

接收服务器返回的符合预设条件的多人通知消息，预设条件包括：消息标识大于上一次获取到的最后一个多人通知消息的消息标识；其中，服务器返回的多人通知消息是按照消息标识的排序，从对应群体标识维护的多人通知消息中依次读取到的，且读取到的多人通知消息的总数目不超过预设数目阈值。

也就是说，本申请实施例中，在服务器侧针对多人通知消息，按照群体标识单独维护一个多人通知消息流，并且在客户端侧也相应增加一个针对多人通知消息的读取变更逻辑，不耦合用户个人消息变更的写入和读取操作，接收方的客户端在获取到服务器发送的多人通知消息后，可以将多人通知消息单独存储，不与个人消息耦合。

本申请实施例中，按照设定周期向服务器发送多人通知消息获取请求，进而接收服务器发送的对应的多人通知消息流中的多人通知消息，这样，接收方增加了拉取多人通知消息的行为交互逻辑，可以按照一定周期获取多人通知消息，保证了多人通知消息的获取的及时性，并且与个人消息分开，提高了对多人通知消息的处理效率。

基于上述实施例，下面对本申请实施例中的消息处理方法的逻辑原理进行说明，例如，参阅图6所示，为相关技术中消息处理方法的逻辑原理示意图，如图6所示，相关技术中，将个人消息和多人通知消息耦合在一起，当有多人通知消息更新时，需要复制多份到不同用户的个人消息流内，逐个向团队内各个用户进行推送，即将多人通知消息写扩散到各个用户的个人消息流中，例如，写扩散到用户A、用户B、用户C，…用户N。

参阅图7所示，为本申请实施例中消息处理方法的逻辑原理示意图，如图7所示，本申请实施例中，针对个人消息和多人通知消息分别进行管理，个人消息对应个人消息流存储，多人通知消息对应多人通知消息流存储，每次有多人通知消息更新并多人通知消息的接收方的数目超过预设阈值时，服务器在多人通知消息流中插入一条对应的多人通知消息，客户端定期获取多人通知消息，这样，本申请实施例中可以根据群体以及个人属性差异，实现分别下发多人通知消息和个人消息的通知能力，可以更及时地将群体数据变更触达用户，并且通过对多人通知消息的独立管理，更好地保证了多人通知消息的有序性，也减少了存储和运营成本，提高了处理效率。

基于同一发明构思，本申请实施例中还提供了一种消息处理装置，该消息处理装置可以是硬件结构、软件模块、或硬件结构加软件模块，该消息处理装置可以为前述的服务器。基于上述实施例，参阅图8所示，本申请实施例中一种消息处理装置，具体包括：

第一接收模块80，用于接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识；

第一存储模块81，用于当所述多个接收方的数目超过预设阈值，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，其中，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

第一发送模块82，用于当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方。

可选的，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中时，第一存储模块81具体用于：

确定对应所述群体标识维护的多人通知消息流中已存储的多人通知消息的消息标识，其中，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的；

根据已存储的多人通知消息的消息标识的生成规则，生成所述多人通知消息的消息标识，并将所述多人通知消息按照时间顺序存储在所述群体标识对应维护的多人通知消息流中。

可选的，当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方时，第一发送模块82具体用于：

接收接收方按照设定周期发送的多人通知消息获取请求，其中，所述多人通知消息获取请求中至少携带所述群体标识和上一次获取到的最后一个多人通知消息的消息标识；

确定所述群体标识对应的多人通知消息流中，存储有符合预设条件的多人通知消息时，将所述符合预设条件的多人通知消息发送给所述接收方，其中，所述预设条件包括：消息标识大于所述上一次获取到的最后一个多人通知消息的消息标识。

可选的，将所述符合预设条件的多人通知消息发送给所述接收方时，第一发送模块82具体用于：

在所述符合预设条件的多人通知消息中，按照消息标识的排序，读取不超过预设数目阈值的多人通知消息；

将读取到的多人通知消息发送给所述接收方。

可选的，第一存储模块81进一步用于：

当所述多个接收方的数目不超过预设阈值，将所述多人通知消息分别存储在所述群体标识对应群体中的各个接收方的个人消息流中，并将所述多人通知消息分别发送给所述各个接收方。

可选的，进一步包括：

第二接收模块83，用于接收所述发送方发送的个人消息，其中，所述个人消息中至少包括接收方标识；

第二存储模块84，用于将所述个人消息存储在所述接收方标识对应的个人消息流中；

第二发送模块85，用于将所述个人消息发送给所述接收方标识对应的接收方。

基于同一发明构思，本申请实施例中还提供了一种消息处理装置，该训练数据的处理装置可以是硬件结构、软件模块、或硬件结构加软件模块，该装置可以为前述的接收方的智能设备。基于上述实施例，参阅图9所示，本申请实施例中另一种消息处理装置，具体包括：

发送模块90，用于按照设定周期向服务器发送多人通知消息获取请求，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息获取请求中至少携带群体标识，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

接收模块91，用于接收所述服务器返回的多人通知消息，所述多人通知消息是所述服务器当所述多人通知消息对应的多个接收方的数目超过预设阈值，从对应所述群体标识维护的多人通知消息流中获取的，所述多人通知消息中至少包括群体标识，以及所述多人通知消息是由发送方发送至所述服务器后，由所述服务器存储在对应所述群体标识维护的多人通知消息流中的。

可选的，所述多人通知消息获取请求中还至少携带上一次获取到的最后一个多人通知消息的消息标识，其中，每个多人通知消息对应有一个消息标识，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的，则所述接收所述服务器返回的多人通知消息时，接收模块91具体用于：

接收所述服务器返回的符合预设条件的多人通知消息，所述预设条件包括：消息标识大于所述上一次获取到的最后一个多人通知消息的消息标识；

其中，所述服务器返回的所述多人通知消息是按照消息标识的排序，从对应所述群体标识维护的多人通知消息中依次读取到的，且读取到的所述多人通知消息的总数目不超过预设数目阈值。

基于上述实施例，参阅图10所示为本申请实施例中电子设备的结构示意图。

本申请实施例提供了一种电子设备，该电子设备可以是终端或服务器，本申请实施例以电子设备为服务器为例进行说明，该电子设备可以包括处理器1010(CenterProcessing Unit，CPU)、存储器1020、输入设备1030和输出设备1040等。

存储器1020可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器1010提供存储器1020中存储的程序指令和数据。在本申请实施例中，存储器1020可以用于存储本申请实施例中任一种消息处理方法的程序。

处理器1010通过调用存储器1020存储的程序指令，处理器1010用于按照获得的程序指令执行本申请实施例中任一种消息处理方法。

基于上述实施例，本申请实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意方法实施例中的消息处理方法。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (12)

1.一种消息处理方法，其特征在于，包括：

接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识；

当所述多个接收方的数目超过预设阈值，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，其中，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方。

2.如权利要求1所述的方法，其特征在于，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，具体包括：

确定对应所述群体标识维护的多人通知消息流中已存储的多人通知消息的消息标识，其中，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的；

根据已存储的多人通知消息的消息标识的生成规则，生成所述多人通知消息的消息标识，并将所述多人通知消息按照时间顺序存储在所述群体标识对应维护的多人通知消息流中。

3.如权利要求2所述的方法，其特征在于，当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方，具体包括：

接收接收方按照设定周期发送的多人通知消息获取请求，其中，所述多人通知消息获取请求中至少携带所述群体标识和上一次获取到的最后一个多人通知消息的消息标识；

确定所述群体标识对应的多人通知消息流中，存储有符合预设条件的多人通知消息时，将所述符合预设条件的多人通知消息发送给所述接收方，其中，所述预设条件包括：消息标识大于所述上一次获取到的最后一个多人通知消息的消息标识。

4.如权利要求3所述的方法，其特征在于，将所述符合预设条件的多人通知消息发送给所述接收方，具体包括：

在所述符合预设条件的多人通知消息中，按照消息标识的排序，读取不超过预设数目阈值的多人通知消息；

将读取到的多人通知消息发送给所述接收方。

5.如权利要求1所述的方法，其特征在于，进一步包括：

当所述多个接收方的数目不超过预设阈值，将所述多人通知消息分别存储在所述群体标识对应群体中的各个接收方的个人消息流中，并将所述多人通知消息分别发送给所述各个接收方。

6.如权利要求1-5任一项所述的方法，其特征在于，进一步包括：

接收所述发送方发送的个人消息，其中，所述个人消息表示向一个接收方发送的消息，所述个人消息中至少包括接收方标识；

将所述个人消息存储在所述接收方标识对应的个人消息流中，并将所述个人消息发送给所述接收方标识对应的接收方。

7.一种消息处理方法，其特征在于，包括：

按照设定周期向服务器发送多人通知消息获取请求，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息获取请求中至少携带群体标识，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

接收所述服务器返回的多人通知消息，所述多人通知消息是所述服务器当所述多人通知消息对应的多个接收方的数目超过预设阈值，从对应所述群体标识维护的多人通知消息流中获取的，所述多人通知消息中至少包括群体标识，以及所述多人通知消息是由发送方发送至所述服务器后，由所述服务器存储在对应所述群体标识维护的多人通知消息流中的。

8.如权利要求7所述的方法，其特征在于，所述多人通知消息获取请求中还至少携带上一次获取到的最后一个多人通知消息的消息标识，其中，一个多人通知消息流中的每个多人通知消息的消息标识是按照接收到多人通知消息的时间顺序依次递增的，则所述接收所述服务器返回的多人通知消息，具体包括：

接收所述服务器返回的符合预设条件的多人通知消息，所述预设条件包括：消息标识大于所述上一次获取到的最后一个多人通知消息的消息标识；

其中，所述服务器返回的所述多人通知消息是按照消息标识的排序，从对应所述群体标识维护的多人通知消息中依次读取到的，且读取到的所述多人通知消息的总数目不超过预设数目阈值。

9.一种消息处理装置，其特征在于，包括：

第一接收模块，用于接收发送方发送的多人通知消息，其中，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息中至少包括群体标识；

第一存储模块，用于当所述多个接收方的数目超过预设阈值，将所述多人通知消息存储在对应所述群体标识维护的多人通知消息流中，其中，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

第一发送模块，用于当接收到接收方按照设定周期发送的至少携带所述群体标识的多人通知消息获取请求时，将所述多人通知消息流中的多人通知消息发送给所述接收方。

10.一种消息处理装置，其特征在于，包括：

发送模块，用于按照设定周期向服务器发送多人通知消息获取请求，所述多人通知消息表示向多个接收方发送的消息，并所述多个接收方具有同一群体标识，所述多人通知消息获取请求中至少携带群体标识，每个群体标识对应维护一个多人通知消息流，并每个多人通知消息流中的每个多人通知消息对应有一个消息标识；

接收模块，用于接收所述服务器返回的多人通知消息，所述多人通知消息是所述服务器当所述多人通知消息对应的多个接收方的数目超过预设阈值，从对应所述群体标识维护的多人通知消息流中获取的，所述多人通知消息中至少包括群体标识，以及所述多人通知消息是由发送方发送至所述服务器后，由所述服务器存储在对应所述群体标识维护的多人通知消息流中的。

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

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现权利要求1-6或7-8任一项所述方法的步骤。

Images