CN111277483A - 一种多端消息的同步方法、服务器及可存储介质 - Google Patents

Abstract

本发明实施例涉及通信领域，公开了一种多端消息的同步方法、服务器及可存储介质。本发明中，多端消息的同步方法，应用于服务器，包括：接收第一登录端上报的时间戳信息；在需将聊天消息抄送至第二登录端时，提取时间戳信息，利用时间戳信息标记所抄送的聊天消息的已读状态；将完成标记的待抄送聊天消息发送给第二登录端，供第二登录端显示所接收的聊天消息的已读状态；其中，第一登录端和第二登录端同属一个用户账户，使得多端消息在同步时可以更实时准确地显示消息的已读状态。

Description

一种多端消息的同步方法、服务器及可存储介质

技术领域

本发明实施例涉及通信领域，特别涉及多端消息的同步方法、服务器及可存储介质。

背景技术

随着全球移动业务的快速发展，人均拥有移动设备的数量也逐渐增多，包括：手机、智能手表、平板电脑PAD和笔记本电脑等，人们可能需要在不同的电子设备上查看电话、短信、聊天消息等。

RCS，即融合通信，可以把手机中原有的通话、消息、联系人这三个主要入口，从运营商的层面直接与手机整合，变为新通话、新消息、新联系。融合通信解决方案是面向互联网的ICT融合通信业务，它区别于网络层面的互联互通，是以人为本的应用层面融合与协同，是更高层次的理念和新一代通信与IT融合的业务。融合通信(RCS)是一个跨通信网、互联网的综合通信及信息共享平台。

本申请发明人发现：在多端信息同步时，对聊天记录同步后，显示的已读记号混乱，有时先显示为已读，再显示为未读，显示的不准确，会造成用户的混乱，也就影响用户消息查看时的体验。

发明内容

本发明实施方式的目的在于提供一种多端消息的同步方法、服务器及可存储介质，使得多端消息在同步时可以更实时准确地显示消息的已读状态。

为解决上述技术问题，本发明的实施方式提供了一种多端消息的同步方法，应用于服务器，包括：接收第一登录端上报的时间戳信息；存储所述时间戳信息；在需将聊天消息抄送至第二登录端时，提取所述时间戳信息，利用所述时间戳信息标记所抄送的聊天消息的已读状态；将完成标记的待抄送聊天消息发送给所述第二登录端，供所述第二登录端显示所接收的聊天消息的已读状态；其中，所述第一登录端和所述第二登录端同属一个用户账户。

本发明的实施方式还提供了一种服务器，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上述的多端消息的同步方法。

本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现如上述的多端消息的同步方法。

本发明实施方式相对于现有技术而言，新增关于时间戳的回执信息，服务器保存时间戳，在需要抄送消息至其他登录端时，先根据存储的时间戳信息判断待抄送信息的已读状态，并做相应标记，使得接收到抄送消息的登录端可以直接获知消息的已读状态，可见登录端可以准确快速地确定消息的已读状态，不会因为确认的时差造成用户先后看到不同已读状态的情况，提升用户体验。另一方面，由于时间戳信息由服务器侧维护，已读状态在消息下发前已被标记，所以登录端在收到消息时，已知消息的已读状态，所以登录端自己无需逐条判断，减小登录端的功耗。本发明实施方式改变了传统由用户侧判断消息的已读状态的处理方式，创新地提出由服务器侧进行判断，突破了常规解决思路，使得消息的同步更为实时准确。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是根据本发明第一实施方式中多端消息的同步方法的流程图；

图2是根据本发明第二实施方式中的多端消息的同步系统的结构示意图；

图3是根据本发明第二实施方式中多端消息的同步方法中时间戳信息的上报流程图；

图4是根据本发明第二实施方式中多端消息的同步方法中聊天消息下发流程图；

图5是根据本发明第二实施方式中的多端消息的同步方法示意图；

图6是根据本发明第三实施方式中的服务器的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

本发明的第一实施方式涉及一种多端消息的同步方法。本实施方式应用于一种服务器，服务器也称伺服器，是提供计算服务的设备。由于服务器需要响应服务请求，并进行处理，因此一般来说服务器应具备承担服务并且保障服务的能力。服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。在网络环境下，根据服务器提供的服务类型不同，分为文件服务器、数据库服务器、应用程序服务器、WEB服务器等。

本实施方式以RCS平台为例进行说明，服务器为提供融合通信RCS服务的服务器，RCS系统中用户可以以相同的手机号码、不同的域名(如“手机号”@pc.com或“手机号”@web.com)注册多个端，由RCS系统记录用户的注册信息，用于区分用户所发的消息属于哪个登录端。如果用户注册有多个登陆端，但只登录其中一个端，而其他端尚处于未登录状态，可以使用登录端进行文字聊天、语音聊天、视频聊天等。RCS系统会以不同端的不同注册信息为key值(键值，如PC端注册信息带PC域名，UE端注册信息带UE标示)将用户发送、接收的消息保存到该用户消息队列里。之后，用户登录其他注册过的端时，则根据登录端的注册信息生成相应key值，到用户消息队列里提取离线消息，抄送给该用户的其他登录端。

实际应用中，用户使用真实的手机号码作为登录帐号，可以通过RCS的PC客户端、Web客户端或手机客户端与联系人进行通信，也可以上传、下载、共享图片、音乐、视频、文本等内容。多端间的消息能够实现同步抄送，即用户使用一个端的聊天消息可以同步到用户的其他端，保证了用户多端间使用的无缝切换。

本实施方式中多端消息的同步方法的流程如图1所示，具体如下：

步骤101，接收第一登录端上报的时间戳信息。

具体的说，在第一登录端的活动窗口符合预设条件时，产生时间戳信息，该时间戳信息表示聊天消息的截止时间，其中可以包括发送方、接收方、时间戳等信息。预设条件具体可以是：活动窗口为聊天窗，且处于活动状态已达到一定时间或聊天窗中的聊天消息已达到一定数量。

如：预设条件为：第一登录端在活动窗口为聊天窗，且处于活动状态每持续10秒，则生成一个时间戳信息进行上报，适用于聊天消息较多的用户；预设条件也可以为：第一登录端在活动窗口为聊天窗，且每多收到5条聊天消息，则生成一个时间戳信息进行上报，适用于聊天消息较少的用户。根据以上例子可知，预设条件的不同设置原则各有利弊，可以根据实际需求进行设置，以满足不同用户的需求。

本实施方式中，第一登录端可以为处于在线状态的登录端或处于活跃状态的登录端，为用户通过手机、个人电脑、平板电脑或网页浏览器登录的登录端。比如，如果用户的多个端中仅有一个处于登录状态，那么第一登录端可以指该处于登录状态的端；如果用户注册的不同端均处于登录状态，但用户当前时间只可能使用一个端，RCS系统会记录各登录端的状态，并将当前时间使用的端标志为活跃端，此时第一登录端可以指活跃端。

更具体的说，终端可以根据以下条件判定用户聊天窗口活跃状态：用户点开某单聊或群聊会话界面，且停留在该页面一定时间，在该会话页面收到或发送的消息达到一定数量或达到一定时间则产生上述特殊已读回执消息。而对于用户只是打开RCS客户端，而未打开某一具体会话，则认为用户并没有真实阅读收到的聊天消息，也即不产生上述特殊已读回执消息。

还需说明的是，本实施方式中的时间戳信息可以以回执消息的形式发送，更利于融合现有的多端系统。

步骤102，存储时间戳信息。

具体的说，服务器存储接收到的时间戳信息，如果在接收到一个时间戳信息时，已存储有历史时间戳信息，则更新存储中的时间戳信息。实际应用中，可以设置时间戳管理进程，用于管理时间戳信息。

更具体的说，存储的时间戳信息对应有发送端信息，也就是记录有是哪个登陆端上报的时间戳信息，便于后续在抄送信息时确定信息的接收端。

步骤103，在需将聊天消息抄送至第二登录端时，提取时间戳信息，利用时间戳信息标记所抄送的聊天消息的已读状态。

具体的说，将所抄送的聊天消息的截止时间早于时间戳信息中时间的聊天消息标记为已读消息。更具体的说，实际应用中，存储的时间戳信息可以作为优先级最高的待发信息位于消息队列中，所以在抄送消息队列中的聊天消息时，消息队列优先弹出时间戳信息，并进行时间判断，从而确定消息队列中的聊天消息是否已读。

还需说明的是，将聊天消息标记为已读有多种方式，如通过在需标记的聊天消息中增加已读字段进行标记，用户终端在接收到增加过已读字段的聊天消息时进行解析，从而根据结果以已读方式或未读方式显示聊天消息。此外，实际应用中可能还有其他标记方式，在此不再一一列举。

本实施方式中，第二登录端也可以是多个，聊天消息可同时抄送多个第二登录端。其中，第一登录端和第二登录端同属一个用户账户。

步骤104，将完成标记的待抄送聊天消息发送给第二登录端，供第二登录端显示所接收的聊天消息的已读状态。

服务器可以设置有时间戳处理组件，主要用于维护RCS业务处理组件发送过来的消息，包括新增、更新、删除时间戳信息。并处理RCS业务处理组件发送过来的消息时间戳比较请求，将比较结果返回给RCS业务处理组件。

现有RCS系统中，对于点对点聊天消息会产生已读回执消息，即A用户发送给B用户一条聊天消息，B用户在阅读后会产生一条已读消息返回给A用户，告知A用户该聊天消息B用户已读。对于这种点对点已读回执消息，RCS系统也会抄送给A用户的其他端，而该已读回执消息顺序入A用户的消息队列，抄送给A用户的其他端时也是顺序从消息队列里弹出。带给A用户的体验就是，开始阶段消息显示未读，而待已读回执消息下发完成，未读消息又显示成已读，如果消息过多会导致用户体验不佳。另外，对于群聊消息，由于一个群里群成员可以有很多(RCS系统可支持到千人群)，出于节省用户流量和端能耗的考虑，群聊消息的已读回执不会返回给发送方。因此群聊已读回执消息无法同步到用户的其他端。用户在切换到其他端后，虽能够看到群里的所有消息以及切换过程中新收到的聊天消息，但是无法准确、快速的定位到切换前的聊天消息时间点，需要向上查找历史消息来确定，一定程度上影响了用户体验。

本实施方式中，新增关于时间戳的回执信息，服务器保存时间戳，在需要抄送消息至其他登录端时，先根据存储的时间戳信息判断待抄送信息的已读状态，并做相应标记，使得接收到抄送消息的登录端可以直接获知消息的已读状态，可见登录端可以准确快速地确定消息的已读状态，不会因为确认的时差造成用户先后看到不同已读状态的情况，提升用户体验。另一方面，由于时间戳信息由服务器侧维护，已读状态在消息下发前已被标记，所以登录端在收到消息时，已知消息的已读状态，所以登录端自己无需逐条判断，减小登录端的功耗。另外，由于时间戳信息表示聊天截止时间，所以在已读状态判断时，不仅可适用于点对点的聊天消息，还适用于群聊的聊天消息。本发明实施方式改变了传统由用户侧判断消息的已读状态的处理方式，创新地提出由服务器侧进行判断，突破了常规解决思路，使得消息的同步更为实时准确。

本发明的第二实施方式涉及一种多端消息的同步方法。第二实施方式从RCS系统的角度，具体描述了一种多端消息的同步方法。

本实施方式中，如图2所示，RCS系统可以包括用户的多端(UE端、PC端等)和服务器，服务器可以包括：RCS业务处理组件、时间戳信息处理组件和用户状态管理进程。

用户侧：UE端、PC端等可以支持时间戳信息的定期或定量上报，可以处理RCS业务处理组件发过来的新增已读字段消息，并将处理结果正确的展示在用户聊天界面。

服务器侧：RCS业务处理组件主要包括业务进程。业务进程负责RCS具体业务逻辑的处理，识别用户多端上报的时间戳信息，处理后提取出关键字段(发送方、接收方、时间戳)发送给时间戳信息处理组件。RCS业务处理组件在下发抄送消息前将消息时间戳取出，发送给时间戳信息处理组件进行时间戳判断。RCS业务处理组件根据时间戳比较结果判定是否在抄送消息扩展消息体里增加已读字段，然后将抄送消息下发给用户的端。为了满足大业务量要求，业务处理组件可能包含多节点，每个业务节点上都要部署业务进程。

时间戳信息处理组件主要维护RCS业务处理组件发送过来的消息，包括新增、更新、删除时间戳信息。并处理RCS业务处理组件发送过来的消息时间戳比较请求，将比较结果返回给RCS业务处理组件。

业务处理组件接收到用户的时间戳信息，协议解码后发送给时间戳信息处理组件；时间戳信息处理组件根据请求的发送方和接收方作为Key值判断是否已经存在记录，如果存在，则更新记录时间戳，如果没有存在，则新增记录。

具体的说，如图3所示，服务器在收到来自用户终端的时间戳信息后的处理过程如下：

步骤301，业务处理组件解码时间戳消息。

具体的说，业务处理进程进行协议解码，获取到关键字段，包括发送方号码、接收方号码和时间戳等字段。

步骤302，业务处理组件向时间戳信息模块发起更新请求。

步骤303，时间戳信息处理组件根据请求查询时间戳存储进程；若存在，则执行步骤304；若不存在，则执行步骤305。

步骤304，时间戳存储进程更新存储的时间戳信息。

步骤305，新增时间戳信息。

具体的说，步骤303至305，若时间戳存储进程确定已存在时间戳信息，则更新记录时间戳，若不存在时间戳信息，则新增记录。

步骤306，时间戳存储进程返回处理结果。

具体的说，返回的处理结果包括更新或新增。

可见，上述步骤301至步骤306也是时间戳信息的上报流程。

之后，如图4所示，服务器在需要抄送聊天消息的具体过程如下：

步骤401，业务处理进程收到用户发送/接收的消息，将消息存储到各端终呼消息队列。其中，对于用户发送的消息不存储到发送端对应的端终呼消息队列，而对于接收的消息，各端终呼消息队列都要存储。

步骤402，业务处理进程根据用户号码向用户状态管理进程发起查询请求，查询所属该用户的其他端的状态，以确定后续消息的下发。

步骤403，用户状态管理进程根据用户号码查询用户信息，将该用户各端的登录、在线、离线情况返回给业务处理进程。

步骤404，业务处理进程根据用户各端状态确定触发哪些终呼下发队列下发消息。基本原则是对于用户在线的端立马触发该端终呼下发队列消息的下发，而对于用户不在线的端需要等待该端上线后再触发消息的下发。

步骤405，业务处理进程处理终呼队列弹出的消息，解析出消息体中的时间戳，并连同发送方号码、接收方号码发送给时间戳信息进程查询。

步骤406，时间戳信息进程收到查询请求，根据发送方号码、接收方号码组key值到时间戳存储进程查询状态。

步骤407，时间戳存储进程根据key值查询已有记录，并将记录中的时间戳和查询请求中的时间戳进行比较，并返回比较结果。

步骤408，业务处理进程根据返回的结果确认是否在下发的抄送消息里增加已读字段，对于抄送消息时间戳先于已读回执记录时间戳的抄送消息，需要增加已读字段，而其他情况下不增加已读字段。

可见，上述步骤401至步骤408也是聊天消息下发流程中关于时间戳信息的处理过程。

更进一步地，图5以用户使用UE端接收/发送聊天消息，消息抄送PC端且PC端在线情况下为例，说明了多端已读回执同步的交互流程，具体流程包括如下步骤：

其中，步骤501～507为时间戳信息上报流程，步骤508～520为抄送PC端消息终呼流程。

步骤501，用户UE端定期或定量上报时间戳信息。

步骤502，RCS业务处理进程解码该时间戳信息，解析出其中的关键字段，包括发送方号码、接收方号码和时间戳。

步骤503，RCS业务处理进程给UE端回响应。

步骤504，RCS业务处理进程向时间戳管理进程发送时间戳更新请求，携带发送方号码、接收方号码和时间戳。

步骤505，时间戳管理进程收到更新请求，向时间戳存储进程发送查询请求，携带发送方号码、接收方号码和时间戳。

步骤506，时间戳存储进程收到查询请求，根据发送方号码、接收方号码生成查询的key值，到存储单元查询相关记录。如果查询到就更新该记录，将记录的时间戳更新为最新时间戳，如果没有查询到就插入新记录。时间戳存储进程返回查询结果。

步骤507，时间戳信息进程将时间戳存储进程返回的结果再返回给RCS业务处理进程。已读回执消息上报流程结束。

步骤508，用户UE端发送/接收到聊天消息，将消息上报给RCS业务处理模块。

步骤509，RCS业务处理模块将该消息缓存到用户的各端终呼下发队列，该用例中为缓存到用户的PC端终呼下发队列。

步骤510，RCS业务处理进程向用户状态管理进程查询用户的端状态，以确定用户的其他端是否在线，请求中携带的关键字段为用户号码。

步骤511，用户状态管理进程收到请求后，根据用户号码查询保存的用户信息，取出用户的端状态，并返回给RCS业务处理进程。

步骤512，RCS业务处理进程根据用户状态管理进程返回的结果判定该用户的PC端在线。

步骤513，RCS业务处理进程向用户PC端终呼下发队列发起消息下发请求，触发终呼队列弹消息出来。

步骤514，用户PC端终呼下发队列收到消息触发请求，从队列里弹出第一条消息返回给RCS业务处理进程。

步骤515，RCS业务处理进程向时间戳信息进程发起时间戳比较请求，携带关键字段包括发送方号码、接收方号码和消息时间戳。

步骤516，时间戳信息进程收到该请求，向时间戳存储进程发起时间戳比较请求，携带关键字段包括发送方号码、接收方号码和消息时间戳。

步骤517，时间戳存储进程收到比较请求，根据发送方号码、接收方号码生成查询的key值，到存储单元查询相关记录。如果查询到就比较存储的时间戳信息和消息时间戳，并将比较结果返回，如果没有查询到就返回特定响应码。

步骤518，时间戳信息进程收到响应，将结果返回给RCS业务处理进程。

步骤519，RCS业务处理进程根据返回的响应，确定是否在消息里增加已读字段。

步骤520，RCS业务处理进程将更新后的抄送消息发送给用户的PC端。结束终呼抄送消息下发流程。

可见，本实施方式从RCS系统的角度，具体描述了一种多端消息的同步方法。可以看出，第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第三实施方式涉及一种服务器。

如图6所示，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行如上述的第一实施方式或第二实施方式中的多端消息的同步方法。

其中，存储器和处理器采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器和存储器的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器。处理器负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器可以被用于存储处理器在执行操作时所使用的数据。

本发明第四实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (10)

1.一种多端消息的同步方法，其特征在于，应用于服务器，包括：

接收第一登录端上报的时间戳信息；

在需将聊天消息抄送至第二登录端时，提取所述时间戳信息，利用所述时间戳信息标记所抄送的聊天消息的已读状态；

将完成标记的待抄送聊天消息发送给所述第二登录端，供所述第二登录端显示所接收的聊天消息的已读状态；

其中，所述第一登录端和所述第二登录端同属一个用户账户。

2.根据权利要求1所述的多端消息的同步方法，其特征在于，所述提取所述时间戳信息之前，还包括：存储所述第一登录端上报的时间戳信息；

在所述存储第一登录端上报的时间戳信息中，包括：若已存储有历史时间戳信息，则更新存储中的时间戳信息。

3.根据权利要求1所述的多端消息的同步方法，其特征在于，在所述利用时间戳信息标记所抄送的聊天消息的已读状态中，具体包括：

将所抄送的聊天消息的截止时间早于所述时间戳信息中时间的聊天消息标记为已读消息。

4.根据权利要求3所述的多端消息的同步方法，其特征在于，利用以下方式标记已读信息：

通过在需标记的聊天消息中增加已读字段进行标记。

5.根据权利要求1所述的多端消息的同步方法，其特征在于，所述第一登录端为处于在线状态的登录端或处于活跃状态的登录端。

6.根据权利要求5所述的多端消息的同步方法，其特征在于，所述登录端为用户通过手机、个人电脑、平板电脑或网页浏览器登录的登录端。

7.根据权利要求1所述的多端消息的同步方法，其特征在于，所述时间戳信息利用以下方式产生：

在所述第一登录端的活动窗口符合预设条件时，产生所述时间戳信息。

8.根据权利要求1至7中任意一项所述的多端消息的同步方法，其特征在于，所述服务器为提供融合通信RCS服务的服务器。

9.一种服务器，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至8中任一所述的多端消息的同步方法。

10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一所述的多端消息的同步方法。

Images