CN109617949A - 一种消息同步方法、装置、存储介质和电子设备 - Google Patents
一种消息同步方法、装置、存储介质和电子设备 Download PDFInfo
- Publication number
- CN109617949A CN109617949A CN201811393611.1A CN201811393611A CN109617949A CN 109617949 A CN109617949 A CN 109617949A CN 201811393611 A CN201811393611 A CN 201811393611A CN 109617949 A CN109617949 A CN 109617949A
- Authority
- CN
- China
- Prior art keywords
- message
- target user
- user end
- synchronization
- record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供了一种消息同步方法及装置,涉及网络信息交互领域。本申请所提供的消息同步方法在实现时,消息记录端可以以目标用户端所提供的第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;并将查找到的所述第二消息发送给目标用户端。这种采用第一消息的编号作为查找基准的方式,精确定位了需要发送给目标用户端的消息,使得消息记录端发送给目标用户端的消息的数量降低了,缓解了由于发送消息而导致的网络资源被过多占用的情况。
Description
技术领域
本申请涉及网络信息交互领域,具体而言,涉及一种消息同步方法及装置、存储介质和电子设备。
背景技术
随着网络通信技术的发展,信息交互技术已经被广泛的应用到了日常的生产生活中。这些信息交互技术的主要技术目的是将一个用户所发出的信息快速且准确的传递给需要接收信息的另一个或多个用户,以完成信息的发送行为。
在具体实现时,由于接收信息的用户不可能永远保持在线状态,进而,根据接收信息的用户的在线情况,可以将信息交互技术的信息传递方式分为两种,分别是传递和延时传递。
如图1所示,示出了一种实现信息交互技术的网络架构,该网络架构中的服务器是进行信息中转的机构,终端A是由发出信息的用户所操作的终端,终端B是由接收信息的用户所操作的终端。
如果用户A和用户B均处于在线状态,则信息交互技术在实现时,就可以由先由用户A将需要发送的消息发送给服务器,服务器在接收到消息之后,再将消息传递给用户B(服务器传递消息的时候,也可以先对消息进行安全性验证,在安全性验证通过之后再将消息传递给用户B)。
如果用户B不处于在线状态,则服务器在接收到用户A所发出的消息之后,就需要将消息存储在服务器中,并在用户B上线后再将消息发送给用户B。
发明内容
本申请的目的在于提供一种消息同步方法及装置。
在一些实施例中,本申请提供了一种消息同步方法,包括:
消息记录端接收目标用户端上传的消息同步请求;消息同步请求中携带有第一消息的编号;
消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
消息记录端将查找到的所述第二消息发送给目标用户端。
在一些实施例中,消息记录端将查找到的所述第二消息发送给目标用户端,包括:
消息记录端将多个第二消息的摘要发送给目标用户端,以使目标用户端生成用于选择第二消息的选择指令;
消息记录端将选择指令所对应的第二消息发送给目标用户端。
在一些实施例中,消息记录端接收目标用户端上传的消息同步请求,包括:
消息记录端接收目标用户端在信息交互界面上通过响应用户的刷新操作而生成的消息同步请求;
消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息的编号之后,且消息生成时间最新的预定数量的消息作为第二消息。
在一些实施例中,若消息同步请求中还携带有批量调取指令;则消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息之前的消息作为第二消息。
在一些实施例中,若消息同步请求中还携带有多终端同步指令;则消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,
消息记录端将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之前的消息作为第二消息;所述多端消息队列中存储有使用所述目标用户端的用户通过其他用户端登录时所发出或接收的消息。
在一些实施例中,若消息同步请求中还携带有群消息同步指令;则消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端查找与所述群消息同步指令相对应的群消息队列;
消息记录端将群消息队列中,编号顺序排在第一消息的编号之后的消息作为第二消息;或,消息记录端将群消息队列中,编号顺序排在第一消息的编号之前的消息作为第二消息。
在一些实施例中,在所述消息记录端接收目标用户端上传的消息同步请求之前,所述方法还包括:
消息记录端获取目标用户端上传的待传递消息;
消息记录端按照预设编号顺序,根据与目标用户端相关联的所述消息队列中已经存储的消息的编号,为待传递消息生成编号,以使待传递消息的编号和所述消息队列中已经存储的消息的编号是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;
消息记录端将所述待传递消息和所述待传递消息的编号关联存储在与目标用户端相关联的所述消息队列中;
消息记录端将与待传递消息相对应的编号发送给目标用户端,以使目标用户端将所述待传递消息和与所述待传递消息相对应的编号进行关联存储。
本申请还提供了另一种消息同步方法,包括:
目标用户端生成携带有第一消息的编号的消息同步请求;
目标用户端向消息记录端上传消息同步请求;以使消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
目标用户端接收消息记录端所返回的第二消息。
在一些实施例中,在所述目标用户端生成携带有第一消息的编号的消息同步请求之前,所述方法还包括:
目标用户端根据已经存储在目标用户端中的第一消息的编号与预设编号顺序的匹配情况,确定目标用户端中未存储的消息;
目标用户端根据目标用户端中未存储的消息,确定第一消息的编号。
在一些实施例中,在所述目标用户端生成携带有第一消息的编号的消息同步请求之前,所述方法还包括:
目标用户端在消息交互页面上接收到用户所下达的消息刷新指令后,根据目标用户端中已存储的编号顺序最后的消息的编号,确定第一消息的编号。
在一些实施例中,本申请还提供了一种消息同步装置,该消息同步装置设置于消息记录端,所述消息同步装置包括:
第一接收模块,用于接收目标用户端上传的消息同步请求;消息同步请求中携带有第一消息的编号;
第一查找模块,用于以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
第一发送模块,用于将查找到的所述第二消息发送给目标用户端。
在一些实施例中,本申请还提供了一种消息同步装置,该消息同步装置设置于目标用户端,所述消息同步装置包括:
第一生成模块,用于生成携带有第一消息的编号的消息同步请求;
第一上传模块,用于向消息记录端上传消息同步请求;以使消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
第二接收模块,用于接收消息记录端所返回的第二消息。
在一些实施例中,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行消息记录端所执行的消息同步方法的步骤。
在一些实施例中,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行目标用户端所执行的消息同步方法的步骤。
在一些实施例中,本申请还提供了一种电子设备,包括:处理器、存储介质和总线,所述存储介质存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,以执行消息记录端所执行的消息同步方法的步骤。
在一些实施例中,本申请还提供了一种电子设备,包括:处理器、存储介质和总线,所述存储介质存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,以执行目标用户端所执行的消息同步方法的步骤。
本申请实施例提供的消息同步方法,在实现时,先由消息记录端接收目标用户端上传的消息同步请求;其中,消息同步请求中携带有第一消息的编号;而后,消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;最后,消息记录端将查找到的所述第二消息发送给目标用户端。
这种采用第一消息的编号作为查找基准的方式,精确定位了需要发送给目标用户端的消息,使得消息记录端发送给目标用户端的消息的数量降低了,缓解了由于发送消息而导致的网络资源被过多占用的情况。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了示出了相关技术中一种实现信息交互技术的网络架构的示意图;
图2示出了本申请实施例所提供的由消息记录端所执行的消息同步方法的基本流程图;
图3示出了本申请实施例所提供的由消息记录端所执行的消息同步方法的细节优化流程图;
图4示出了本申请实施例所提供的由消息记录端所执行的消息同步方法中,同一个用户所使用的多个用户端与服务器(消息记录端)进行连接的示意图;
图5示出了本申请实施例所提供的第一电子设备的示意图;
图6示出了本申请实施例所提供的第二电子设备的示意图。
具体实施方式
下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
相关技术中,在进行网络消息传递的时候,如果接收消息的用户端处于在线状态,则中转消息的服务器可以直接将消息发送给该用户端;如果接收消息的用户端处于离线状态,则中转消息的服务器就不能直接将消息发送给该用户端(离线状态下,用户端接收不到消息),而是要等用户端上线后,再将消息发送给用户端。
相关技术中,为了保证用户端接收消息的准确性和全面性,在用户端上线后,服务器会将和用户端相关的所有消息都发送给用户端(不论用户端中是否已有该消息),很明显,这会导致服务器需要占用大量的网络资源,并且需要通过较长的时间才能够将与用户端相关的所有消息都发送给用户端。
针对上述这种服务器需要耗费大量网络资源和时间来将消息同步给用户端的方式,本申请的发明人认为可以采用其他更合理的方式来完成网络端与用户端的消息同步,进而,如图2所示,本申请所提供的消息同步方法包括如下三个步骤:
S101,消息记录端接收目标用户端上传的消息同步请求;消息同步请求中携带有第一消息的编号;
S102,消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;目标用户端中和消息队列中的相同消息的编号是一致的;消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
S103,消息记录端将查找到的第二消息发送给目标用户端。
步骤S101中,消息记录端是用于记录(存储)与目标用户端有一定关联性的消息的网络端。消息记录端的具体存在形式是多种多样的,比如,消息记录端可以是如图1所示的网络架构中的服务器。通常情况下,消息记录端就是负责中转各个用户端(至少是目标用户端)所发出的消息的中转网络端;消息记录端还是可以是负责专门存储各个用户端(至少是目标用户端)所发出的消息的存储网络端(比如,可以是负责中转各个用户端所发出的消息的中转网络端将所有消息存于该存储网络端)。一般情况下,消息记录端应当保存有与目标用户端相关联的全部消息。
目标用户端所上传的消息同步请求可以是目标用户端在启动后自动发出的(如开机后,或启动某个程序后自动发出的),也可以是在用户(用户端的使用者)在对用户端下达操作指令后,用户端响应于该操作指令所发出的。
消息同步请求的主要作用是告知消息记录端,以使消息记录端将与自己(目标用户端)相关联的消息提供给自己,为了能够让消息记录端提供消息更加具有针对性,可以是在消息同步请求中携带上第一消息的编号,其中,第一消息可以是已经存储在目标用户端内的消息,也可以是未存储在目标用户端内的消息。通过告知消息记录端第一消息的编号,使得消息记录端可以以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息。此处,消息同步规则用于描述第一消息的编号和第二消息的编号的关系。该消息同步规则的作用说明目标用户端所需要的消息(第二消息)和第一消息之间的关系(主要是编号的位置关系,如第二消息的编号排在第一消息的编号之后/之前)。
本方案中,所述目标用户端中和所述消息队列中的相同消息的编号是一致的,指的是目标用户端中的每个消息都有对应的编号,该编号是用来区分目标用户端中不同消息的(实际上,目标用户端中的消息也是按照消息队列进行存储的);同样的,消息记录端的消息队列中,每个消息也都有对应的编号,该编号是用来区分消息队列中不同消息的。并且,相同的消息(不仅仅指消息内容相同,还要通过消息的生成时间来区分消息是否相同)在目标用户端中和消息记录端中的编号是一致的,这样第一消息的编号就能够唯一的指向消息记录端中的一个消息了。
对于任一个消息,在目标用户端中的编号和在消息记录端中的编号应当是相同的,也就是,根据相同的编号,消息记录端所查找到的消息和目标用户端所查找到的消息是相同的消息。这也保证了,消息记录端根据消息同步请求中携带的第一消息的编号能够查找到在消息记录端中存储的唯一一个消息。
不论是存储在消息记录端中的消息,还是存储在目标用户端中的消息,所述每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的。
此处,需要对消息生成时间进行解释,消息生成时间指的是和消息有关的一个时间,通过该消息生成时间能够确定出不同消息的出现顺序。具体而言,消息生成时间是指由用户端(目标用户端或其他用户端)生成该消息的时间、发出该消息的时间等等,也可以是指有消息记录端/中转消息的服务接收,或存储等对该消息进行处理的时间,但应当保证的是,每个消息的消息生成时间的统计规则应当是一致的(如都是按照用户端生成该消息的时间来计算)。
预设编号顺序指的是,不同消息的编号之间的排列顺序,该排列顺序是固定的,也就是,在知晓了预设编号顺序之后,可以根据前一个消息的编号推测出下一个消息的编号,或者是说,在知晓了预设编号顺序之后,可以推测出指定位次的消息的编号;如已知A消息是该消息队列中第10个消息(10就是位次),则可以确定出A消息所对应的编号。
具体的,预设编号顺序可以是按照自然数的方式递增的方式进行排列的,比如编号顺序可以是1、2、3、4、5、6、7…,也就是位次在第一位的消息的编号为1;位次在第二位的消息的编号为2;位次在第三位的消息的编号为3等。
预设编号顺序还可以是按照奇数的方式递增的方式进行排列的,比如编号顺序可以是1、3、5、7…,也就是,位次在第一位的消息的编号为1;位次在第二位的消息的编号为3;位次在第三位的消息的编号为5等。
预设编号顺序还可以是按照偶数的方式递增的方式进行排列的,比如编号顺序可以是2、4、5、6…,也就是,位次在第一位的消息的编号为2;位次在第二位的消息的编号为4;位次在第三位的消息的编号为6等。
预设编号顺序还可以是按照其他编号的排列方式的方式递增的方式进行排列的,比如编号顺序可以是1212、5361、6436、124315…,也就是,位次在第一位的消息的编号为1212;位次在第二位的消息的编号为5361;位次在第三位的消息的编号为6436等。也就是,预设编号顺序并不必然是按照某个已知的数列顺序排列出来的,也可以是系统或者是目标用户端自行定义的。但应当保证的是,目标用户端和消息记录端都应当知晓该预设编号顺序。
上述例子中列举了数字形式的编号,编号还可以是英文字母、中文等其他能够起到标识性的符号。
进而,消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的,指的是就是消息的生成时间靠前的,则编号的位次越靠前,并且,在消息的位次确定后,编号也就能够唯一的确定的。
如下表1所示,示出了消息记录端中的消息队列的一种表现形式。
表1
编号 | 生成时间 | 消息内容 |
1 | 10:12 | AAAA |
2 | 10:14 | BBBB |
3 | 10:16 | CCCC |
4 | 10:21 | DDDD |
5 | 10:22 | EEEE |
从表1中可以看出,各个消息的编号是按照自然数列严格排列的(位次在第一位的消息的编号为1;位次在第二位的消息的编号为2;位次在第三位的消息的编号为3),并且消息的生成时间决定的消息的位次,每个位次所对应的编号均是确定的。
类似的,在目标用户端中也可以存在有和表1相类似的表,区别在于,目标用户端中表的内容是有缺失的,如目标用户端中的消息队列如表2所示。
表2
编号 | 生成时间 | 消息内容 |
1 | 10:12 | AAAA |
2 | 10:14 | BBBB |
3 | 10:16 | CCCC |
很明显的,表2和表1相比,表2中缺少了编号为4和5的消息,进而,在步骤S101中,目标用户端可以将编号3(S101中第一消息的编号,也是目标用户端中生成时间最晚的消息的编号,或者说是编号的位次在最后一位的消息的编号)携带在消息同步请求中,并发送给消息记录端。在步骤S102中,消息记录端可以根据编号3在表1中查找目标用户端中所缺失的消息,也就是编号为4和5的消息,而后,在步骤S103中就可以将查找到的消息(S102中的第二消息)发送给目标用户端了,当然,在发送消息的时候,也可以一并将消息的编号发送给目标用户端,使得目标用户端可以更新存储在目标用户端内的消息队列。
需要说明的是,步骤S102,查找符合消息同步规则的第二消息中,消息同步规则反映了第一消息的编号和第二消息的编号的关系,消息同步规则可以是“将第一消息和编号位次在第一消息的编号之后的消息同步给目标用户端”,也可以是“将编号位次在目标消息的编号之后的消息同步给目标用户端,其中,目标消息的编号位次在第一消息的编号位次之后的两位(如表1中,第一消息的编号是2,则目标消息的编号就是4)”。也就是消息同步规则不仅是可以说明将编号位次在第一消息之后或之前的消息发送给目标用户端,还可以是说明将编号位次在指定消息之后或之前的消息发送给目标用户端,并且说明指定消息的编号和第一消息的编号的关系。进而,消息同步规则可以是消息记录端和目标用户端之间预先约定好的,也可以是目标用户端将消息同步规则携带在消息同步请求中发送给消息记录端的。
S102中,与目标用户端相关联的消息队列,可以理解为和使用目标用户端的用户(此处的用户是根据唯一的账号密码确定的)有关系的消息队列。比如使用目标用户端的用户通过操作其他网络端所发出的消息(用户自己使用其他设备发出去的)所在消息队列就是目标用户端相关联的消息队列;又比如,其他用户向使用目标用户端的用户发出的消息(别人发给用户的消息)所在的消息队列。也就是,本申请所提供给的方案中,与目标用户端相关联的消息队列所存储的消息可以是使用目标用户端的用户通过操作其他网络端所发出的消息,也可以是其他用户向使用目标用户端的用户发出的消息。具体实现时,通常每个用户(通过账号来区分不同的用户)都应当有对应的一个消息队列,用于记录该用户与其他用户进行交互的消息。
当然,还可以是每个用户都拥有多个消息队列,比如任意两个用户之间所交互的消息可以形成一个消息队列,具体如有三个用户(用户A、B和C),如果这三个用户均两两之间进行消息交互,则应当产生3个消息队列(用户A与用户B进行消息交互的消息队列;用户B与用户C进行消息交互的消息队列;用户A与用户C进行消息交互的消息队列)。
又比如,每个群组(如聊天群,一个群组是由多个用户组成的)可以设置一个对应的消息队列,也就是,用户在该群组中发出的消息应当视为是向该群组中的全体用户都发送的。进而,该消息队列可以只用于记录各个用户在该群组中所发出的消息。
也就是,与目标用户端相关联的消息队列可以是指任一个和使用目标用户端的用户有关的消息队列。
具体的,如下表3所示,
表3
表3中示出了消息队列的交互方,表3中所列出的消息队列都是双方交互(实际实现时可以是多方交互,即群组中的多个用户进行交互),如编号为1的消息队列的交互双方为用户A和用户B;编号为2的消息队列的交互双方为用户C和用户D;编号为3的消息队列的交互双方为用户E和用户F。并且,编号为1的消息队列中共有三条消息,分别是消息A、消息B、消息C;编号为2的消息队列中共有三条消息,分别是消息D、消息E、消息F;编号为3的消息队列中共有三条消息,分别是消息H、消息I。如果目标用户端为用户A所使用的用户端,则编号为1的消息队列就是与目标用户端相关联的消息队列。进而,按照此种方式执行步骤S102的话,就是从消息A、消息B、消息C中选择第二消息,如第一消息的编号是对应消息A的话,则消息B和消息C可以作为第二消息。
类似的,如果目标用户端为用户E所使用的用户端,则编号为3的消息队列就是与目标用户端相关联的消息队列。进而,基于上述内容执行步骤S102的话,就是从消息G、消息I中选择第二消息,如第一消息的编号是对应消息G的话,则消息I就可以作为第二消息。
进而,在步骤S102中,消息记录端可以准确的确定出第二消息,并将第二消息发送给目标用户端。需要说明的是,步骤S102中,所查找到的第二消息可以对应着一个具体消息,比如目标用户端中只缺少一个消息(第一消息的编号所对应的消息),并且消息同步规则反映了只将第一消息的返回,则步骤S102中所查找到的消息可以就是查找到的这一个具体消息发送给目标用户端。当然,第二消息也可以是对应着多个具体消息,比如,消息同步规则反映了将位次在第一消息之后的消息均返回,则消息记录端可以将这多个具体消息发送给目标用户端。
本申请所提供的方法主要是在消息记录端向目标用户端同步消息的时候,先根据用户端所提供的第一消息的编号,确定了目标用户端期望得到的第二消息,而后,将第二消息向用户端发送,使得消息记录端发送给目标用户端的消息的数量降低了,缓解了由于发送消息而导致的网络资源被过多占用的情况。
本申请所提供的方法中,不论是消息记录端还是用户端,在存储消息(第一消息和第二消息)的时候,都要存储消息所对应的编号,如下表4所示,示出了在用户端存储消息的形式。
表4
编号 | 消息内容 | 编号 |
1 | 用户A向用户B发出“可以开始” | 12345 |
2 | 用户A向用户B发出“密码是多少” | 12346 |
3 | 用户B向用户A发出“密码是444” | 23574 |
从表4中可以看出,每个消息都对应有一个唯一的编号,这个编号是用来区分不同的消息的,因此,为了将不同的消息进行有效的区分,大部分的消息所对应的编号应当是不同的,或者是说重要的消息所对应的编号应当是不同的。
任意两个消息的编号都应当是不相同的,即消息队列中的每个消息均有唯一的一个编号。此处的任意两个消息中,消息通常是指单个的消息,如用户A向用户B所发出的某一条消息,或者是用户A在一个交流群(一个交流群中通常包括有大量的用户,因此,在一个交流群中所发出的消息可以认为是向该群中的全部用户所发出的)中所发出的消息。该消息如用户A向用户B发出的“请将报告发送给我”的文字,也可以是一封电子邮件,或者是其他种类的消息(如手机短信等)。
还可以是,在相同时间段生成的消息具有相同的编号,不同时间段生成的消息的编号不相同,也就是消息队列中每个消息的编号是根据消息的生成时间所在的时间段确定的。或者是说,同一个时间段所产生的消息的编号均是相同的,不同时间段所产生的消息的编号均是不相同的。具体而言,如10点-11点之间所生成的消息的编号均是相同的,编号均可以是“10-11”;11点-12点之间所生成的消息的编号均是相同的,编号均可以是“11-12”。这样,通过将不同时间段的消息设置不同的编号,使得消息记录端在将消息发送给目标用户端的时候,消息记录端可以一次性的将某个时间段的消息均发送给目标用户端,减少了对消息增加编号的难度(编号的种类少了,生成编号的时候,不容易出现错乱的情况)。此种情况下,一个消息就对应了多个具体内容,或者说一个消息中记录了在同一个时间段中所收发的多个子消息。
一般情况下,生成编号(或者是说给消息增加编号)的工作通常是由消息记录端完成的,这主要是消息记录端中应当保存有全部的消息(消息记录端通常是负责转发消息的,因此消息记录端中可以保存有全部的消息),因此,在生成编号的时候,不会发生错乱的情况(不会发生两个不应当使用相同编号的消息使用相同编号的情况)。
进而,本申请所提供的方法中,可以按照如下方式生成编号:
步骤201,消息记录端获取目标用户端上传的待传递消息;
步骤202,消息记录端按照预设编号顺序,根据与目标用户端相关联的所述消息队列中已经存储的消息的编号,为待传递消息生成编号,以使待传递消息的编号和所述消息队列中已经存储的消息的编号是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;
步骤203,消息记录端将所述待传递消息和所述待传递消息的编号关联存储在与目标用户端相关联的所述消息队列中;
步骤204,消息记录端将与待传递消息相对应的编号发送给目标用户端,以使目标用户端将所述待传递消息和与所述待传递消息相对应的编号进行关联存储。
其中,步骤201中,消息发送指令表示目标用户端期望将待传递消息发送给其他用户端。步骤202中,消息记录端可以直接生成与消息内容相对应的编号。该编号可以是每个消息均有唯一的一个编号,也可以是相同时间段的消息具有唯一的一个编号。生成编号的时候,可以是先查看消息队列中最后一个位次的消息编号,并按照预设编号顺序给待传递消息设置对应的编号(待传递消息的编号位次排在当前消息队列中最后一个位次的消息编号的下一个)。
步骤203中,消息记录端需要将待传递消息和为该消息内容所生成的编号对应的存储到与目标用户端相关联的所述消息队列中。此处,与目标用户端相关联的所述消息队列指的是使用目标用户端的用户的消息队列(消息队列的具体含义可以参照前文中的解释)。而后,消息记录端可以将消息队列存储在消息记录端的数据库中(即存储网络数据中,而不是目标用户端的数据库)。
步骤204中,消息记录端还需要将与消息内容相对应的编号发送给目标用户端,以使目标用户端存储将所述消息内容和编号对应的进行存储。这样,就可以保证消息记录端和目标用户端针对同一个消息内容使用相同的编号了。
实际使用时,对于其他的用户端也可以类似的采用上述步骤201-204的方式来保存消息内容和对应的编号。
除了由消息记录端来生成编号,也可以是消息记录端和用户端使用相同的策略分别生成编号,但此种方式可能会导致编号错误(针对相同的消息内容,消息记录端和用户端中所使用的编号不同),因此,优选采用由消息记录端生成编号的实现方式。
在步骤S103执行时,可能会遇到第二消息过多的情况,比如,目标用户端过长的时间没有上线同步消息的时候,再次上线的时候,必然有大量的消息需要同步,此时,如果直接将全部的第二消息都发送给目标用户端的话,那发送的消息量还是会很大,此时,可以采用先发送摘要的方式来让目标用户端进行选择,以控制发送第二消息的数量。
具体而言,如图3所示,本申请所提供的方法中,步骤S103可以按照如下方式实现:
S1031,消息记录端将多个第二消息的摘要发送给目标用户端,以使目标用户端生成用于选择第二消息的选择指令;
S1032,消息记录端将选择指令所对应的第二消息发送给目标用户端。
步骤S1031中,多个第二消息可以是全部的第二消息(就是根据第一消息的编号所查找到的目标用户端中所没有的全部消息),也可以是全部的第二消息中的一部分。第二消息的摘要具体可以是指第二消息的标题、首段中的内容、通过语义分析技术从第二消息中自动提炼出的摘要等。总体上来看,第二消息的摘要应当一定程度上反映出第二消息的一些特性(能够使一条第二消息与其他的消息产生区别的特性)。
步骤S1031中,在消息记录端将第二消息的摘要发送给目标用户端之后,目标用户端就可以根据摘要来选择接收哪个第二消息了,并且目标用户端需要将选择哪个第二消息记录在选择指令中。也就是,选择指令说明了目标用户端期望接收哪个第二消息。
而后,步骤S1032中,消息记录端在接收到选择指令后,就可以根据选择指令,将全部第二消息中的部分或者全部发送给目标用户端了。
步骤S1031中,选择指令的生成方式可以是多种的,比如可以是用户通过对目标用户端下达勾选操作的方式来生成选择指令;也可以是用户通过对目标用户端下达自动筛选操作(如按照时间自动筛选)的方式来生成选择指令。
如前文中所说,当第二消息过多的时候就需要采用步骤S1031和S1032的方式,因此,在执行步骤S1031之前,应当先判断第二消息的数量,也就是步骤S103在执行的时候,首选应当判断第二消息的总量是否超过预设数值,如果超过才执行步骤S1031。
也就是,步骤S103还包括:
判断第二消息的总量是否超过预设数值;
若第二消息的总量超过预设数值,则执行步骤S1031;
若第二消息的总量未超过预设数值,则将每个第二消息均发送给目标用户端。
其中,第二消息的总量可以有如下两种理解方式:
第一种理解方式是第二消息的个数/条数,也就是有多少条第二消息,第二消息的总量就是多少。比如第二消息中有15条用户A发送给用户B的消息,有12条用户B发送给用户A的消息,并且,没有其他消息了,则第二消息的总量就是27条。
第二种理解方式是第二消息所占用空间的大小。如第二消息共占用15M的空间,则发送第二消息时也要至少占用15M的网络资源。
这两种理解方式相比,第一种理解方式下,第二消息的总量很容易统计,但并不直观,第二种理解方式更适用于实际的使用场景(考虑发送第二消息的大小)。
前文中已经说明了消息记录端可以通过第一消息的编号来查找目标用户端中所没有的第二消息,并将第二消息向目标用户端发送,以使目标用户端只需接收其没有消息。
在某种典型的情况下,用户可以是在信息交互界面(目标用户与其他用户的聊天界面)上通过下达刷新指令(如将信息交互界面向下滑动)来刷新消息,此时,便可以执行本申请所提供的方法。
也就是,本申请所提供的方法中,步骤S101,包括:
步骤1011,消息记录端接收目标用户端在信息交互界面上通过响应用户的刷新操作而生成的消息同步请求;
步骤S102,包括:
步骤1021,消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息的编号之后,且消息生成时间最新的预定数量的消息作为第二消息。
也就是,在步骤S1011接收到消息同步请求后,在步骤S102中,就可以将编号顺序排在第一消息的编号之后,且消息生成时间最新的预定数量的消息作为第二消息。此处,编号的位次越靠后,消息的生成时间就越新,因此,可以凭借编号的位次,来确定编号的位次来执行步骤1021了。
除了以上基本的消息同步方式以外,本方案中还针对的提供了如下几种典型的实现方式:
第一种实现方式:将比第一消息生成时间晚的消息同步给目标用户端。
可以想象的是,本申请所提供的方法通常是使用在用户长时间没有登录的时候所使用的。此种情况下,用户在登录的时候,目标用户端中通常只保留了很长一段时间之前的消息。比如当前时间是5月5日,用户使用目标用户端最后一次登录的时间是3月1日,则目标用户端中只可能保留3月1日及以前的消息,3月1日-5月5日之间的消息均不可能有。此种情况下,目标用户端可以只将目标用户端中所存储的消息中,生成时间最晚的消息的编号发送给消息记录端,消息记录端可以根据该目标用户端中所存储的消息中,生成时间最晚的消息的编号,查找比这个消息生成时间更晚的消息,并将所有比这个消息生成时间更晚的消息都作为第二消息,或者是将比这个消息生成时间更晚的消息中的一部分作为第二消息。
也就是,本申请所提供的方法中,所述第一消息是已经存储在目标用户端内的消息中,生成时间最晚的消息(或者是,第一消息是已经存储在目标用户端内的消息中,编号位次排在最后的消息);
步骤S102可以按照如下方式实现:
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息之后的消息作为第二消息。
第二种实现方式:将比第一消息生成时间早的消息同步给目标用户端。
第二种实现方式与第一种实现方式相似,区别在于,第二种实现方式中,用户是期望查看比第一消息生成时间更早的消息(可能是因为用户将生成时间过早的消息删除掉了)。
也就是,步骤S102可以按照如下方式实现:
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息之前的消息作为第二消息。
上述第一种和第二种实现方式,可以是在用户期望进行消息的批量调取时执行的,此时,消息同步请求中应当还携带有批量调取指令。
第三种实现方式:将操作目标用户端的用户使用其他终端所发出的消息同步给目标用户端。
如图4所示,示出了同一个用户所使用的多个用户端与服务器(消息记录端)进行连接的示意图。图中示出了可以与服务器进行通讯的多个终端,分别是手机A、手机B和电脑。这三个终端均是同一个用户(指通过相同账号和密码登录的用户)所使用的,比如用户在家的时候会使用手机A发送消息,用户公司的时候会通过电脑发送消息,用户在家和公司以外的地区时,会通过手机B发送消息。也就是用户会使用相同的账号通过不同的终端登录,此时,就需要将不同终端所发出的消息进行同步。
进而,若消息同步请求中还携带有多终端同步指令;则步骤S102可以按照如下方式实现:
消息记录端将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,
消息记录端将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之前的消息作为第二消息;所述多端消息队列中存储有使用所述目标用户端的用户通过其他用户端登录时所发出或接收的消息。
其中,多终端同步指令反应了,操作目标用户端的用户期望将自己通过其他终端发出的消息也同步到目标用户端中,进而,消息记录端就可以从对应的第一消息队列中查找第二消息,此处的第一消息队列是专门用于存储使用所述目标用户端的用户通过指定终端登录时所发出的消息。也就是,此处的第一消息队列可以是存储有目标用户(操作目标用户端的用户)通过目标用户端所发出或接收的消息,也可以是存储有目标用户通过其他终端(非目标用户端的终端)所发出或接收的消息。
第四种实现方式:将操作目标用户端的用户所在群组的中的消息同步给目标用户端。
也就是使用所述目标用户端的用户可以会加入某个群组(通常,一个群组是由多个用户所组成的),进而,通过本申请所提供的方法可以将该群组中所发出的消息同步给目标用户端。群组中的消息与一般的消息有区别的是,群组中的消息(由群组中的某个用户所发出的消息)是面向加入了该群组中的全部用户发送的。
进而,本申请所提供的方法中,若消息同步请求中还携带有群消息同步指令;则步骤S102可以按照如下方式实现:
消息记录端查找与所述群消息同步指令相对应的群消息队列;
消息记录端将群消息队列中,编号顺序排在第一消息的编号之后的消息作为第二消息;或,消息记录端将群消息队列中,编号顺序排在第一消息的编号之前的消息作为第二消息。
其中,第二消息队列可以是专门用于记录记录指定的群组中各个用户所发出消息的消息队列。
第五种实现方式:将即不存在于目标用户端,并且使用目标用户端的用户也没有阅读过的消息同步给目标用户端。
进而,本申请所提供的方法中,步骤S102可以按照如下方式实现:
消息记录端根据所述第一消息的编号,从与目标用户端相关联的消息队列中查找符合消息同步规则,且未被使用目标用户端的用户所阅读的消息作为第二消息。
其中,使用目标用户端的用户是否阅读过某个消息,可以是有两种识别方式。
第一种识别方式是通过某消息是否向使用目标用户端的用户所使用的终端(可以是目标用户端,也可以是其他的终端)所发送过来识别。如果消息记录端或其他终端向使用目标用户端的用户发送过,则说明该消息已经被使用目标用户端的用户所阅读过。
第二种识别方式是使用目标用户端的用户是否针对某个消息回复过确认阅读过的说明,如果接收到过确认阅读过的说明,则说明该消息被使用目标用户端的用户阅读过。
与上述由消息记录端所执行的消息同步方法相对应的,本申请还对应的提供了由目标用户端所执行的消息同步方法,该由目标用户端所执行的消息同步方法,包括如下步骤:
目标用户端生成携带有第一消息的编号的消息同步请求;
目标用户端向消息记录端上传消息同步请求;以使消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
目标用户端接收消息记录端所返回的第二消息。
需要说明的是,目标用户端所执行的消息同步方法与由消息记录端所执行的消息同步方法只是执行主体有区别,具体实现的方式是相同的,因此,由目标用户端所执行的消息同步方法中没有说明的细节内容均可以参考前述由消息记录端所执行的消息同步方法的内容。
优选的,该由目标用户端所执行的消息同步方法,还包括:
目标用户端根据已经存储在目标用户端中的第一消息的编号与预设编号顺序的匹配情况,确定目标用户端中未存储的消息;
目标用户端根据目标用户端中未存储的消息,确定第一消息的编号。
也就是,由于目标用户端已经知晓预设编号顺序,因此,目标用户端(或者是目标用户端的使用者)可以很明显的知晓编号在哪个位置断开了,如下表5所示,示出了将表1中的部分消息进行省略后的表格。
表5
编号 | 生成时间 | 消息内容 |
1 | 10:12 | AAAA |
4 | 10:21 | DDDD |
5 | 10:22 | EEEE |
表5中,很明显的能够看出来,编号1和4之间缺少,编号2和3,也就是编号为2和3的消息是缺失的,此时,目标用户端就可以将编号2和3作为第一消息的编号。当然,也可以是将编号1和4作为消息的编号,并在消息同步请求中携带上“返回位次在编号1和4之间的消息”。
作为一种典型的是实时场景,该由目标用户端所执行的消息同步方法,还包括:
目标用户端在消息交互页面上接收到用户所下达的消息刷新指令后,根据目标用户端中已存储的编号顺序最后的消息的编号,确定第一消息的编号。
也就是,如果目标用户在和其他用户进行信息交互的界面(聊天界面)上进行刷新,则说明用户期望查看最新的几条信息,此时,目标用户端可以根据目标用户端中已存储的编号顺序最后的消息的编号,确定第一消息的编号。比如,可以将位次排在最后的消息的编号作为第一消息的编号。
需要说明的是,本申请所提供的方法尤其适用于消息记录端中所存储的消息极多的情况。在该种情况下,假如消息记录端内,与目标用户端相关联的消息队列中共存储有10000条消息,则按照现有的技术的方式,每次同步的时候,就需要消息记录端将这10000条消息均发送给目标用户端,以完成消息的同步。但如果采用本申请所提供的方案,则消息记录端可以以第一消息的编号为基准,来查找目标用户端所需要的第二消息,并将查找到的第二消息提供给目标用户端。如果用户选择每天同步10次的话,则使用本申请所提供的方法和使用传统方法所需要发送的消息的数量就差别十分巨大了。如果用户选择每天同步10次的话,使用本申请的方案,用户通常每次只需要接收几十条消息即可。
并且,本申请的方案中,如果消息记录端认为一次性需要发送给目标用户端的消息过多,则消息记录端可以先将每个消息的摘要发送给目标用户端,以使用户可以根据消息摘要选择同步哪个消息,而后消息记录端会根据用户的选择,将指定的消息发送给目标用户端,以进一步减少消息实际的发送量。
与上述由消息记录端所执行的消息同步方法相对应的,本申请还提供了一种消息同步装置,设置于消息记录端中,该消息同步装置包括:
第一接收模块,用于接收目标用户端上传的消息同步请求;消息同步请求中携带有第一消息的编号;
第一查找模块,用于以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
第一发送模块,用于将查找到的所述第二消息发送给目标用户端。
在一些实施例中,第一发送模块,包括:
第一发送单元,用于将多个第二消息的摘要发送给目标用户端,以使目标用户端生成用于选择第二消息的选择指令;
第二发送单元,用于将选择指令所对应的第二消息发送给目标用户端。
在一些实施例中,第一接收模块,包括:
第一接收单元,用于接收目标用户端在信息交互界面上通过响应用户的刷新操作而生成的消息同步请求;
第一查找模块,包括:
第一查找单元,用于将与目标用户端相关联的消息队列中,编号顺序排在第一消息的编号之后,且消息生成时间最新的预定数量的消息作为第二消息。
在一些实施例中,若消息同步请求中还携带有批量调取指令;则第一查找模块,包括:
第二查找单元,用于将与目标用户端相关联的消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,用于将与目标用户端相关联的消息队列中,编号顺序排在第一消息之前的消息作为第二消息。
在一些实施例中,若消息同步请求中还携带有多终端同步指令;则第一查找模块,包括:
第三查找单元,用于将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,用于将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之前的消息作为第二消息;所述多端消息队列中存储有使用所述目标用户端的用户通过其他用户端登录时所发出或接收的消息。
在一些实施例中,若消息同步请求中还携带有群消息同步指令;则第一查找模块,包括:
第四查找单元,用于查找与所述群消息同步指令相对应的群消息队列;
第四查找单元,用于将群消息队列中,编号顺序排在第一消息的编号之后的消息作为第二消息;或,用于将群消息队列中,编号顺序排在第一消息的编号之前的消息作为第二消息。
在一些实施例中,所述装置还包括:
第一获取模块,用于获取目标用户端上传的待传递消息;
第二生成模块,用于按照预设编号顺序,根据与目标用户端相关联的所述消息队列中已经存储的消息的编号,为待传递消息生成编号,以使待传递消息的编号和所述消息队列中已经存储的消息的编号是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;
第一存储模块,用于将所述待传递消息和所述待传递消息的编号关联存储在与目标用户端相关联的所述消息队列中;
第二发送模块,用于将与待传递消息相对应的编号发送给目标用户端,以使目标用户端将所述待传递消息和与所述待传递消息相对应的编号进行关联存储。
与上述由目标用户端所执行的消息同步方法相对应的,本申请还提供了一种消息同步装置,设置于目标用户端中,该消息同步装置包括:
第一生成模块,用于生成携带有第一消息的编号的消息同步请求;
第一上传模块,用于向消息记录端上传消息同步请求;以使消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
第二接收模块,用于接收消息记录端所返回的第二消息。
在一些实施例中,所述装置还包括:
第一确定模块,用于根据已经存储在目标用户端中的第一消息的编号与预设编号顺序的匹配情况,确定目标用户端中未存储的消息;
目标用户端根据目标用户端中未存储的消息,确定第一消息的编号。
在一些实施例中,所述装置还包括:
第二确定模块,用于在消息交互页面上接收到用户所下达的消息刷新指令后,根据目标用户端中已存储的编号顺序最后的消息的编号,确定第一消息的编号。
与上述方法相对应的,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行由消息记录端所执行的消息同步方法的步骤。
与上述方法相对应的,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行由目标用户端所执行的消息同步方法的步骤。
如图5所示,为本申请实施例所提供的第一电子设备示意图,该第一电子设备1000包括:处理器1001、存储器1002和总线1003,存储器1002存储有执行指令,当第一电子设备运行时,处理器1001与存储器1002之间通过总线1003通信,处理器1001执行存储器1002中存储的由消息记录端所执行的消息同步方法的步骤。
如图6所示,为本申请实施例所提供的第二电子设备示意图,该第二电子设备2000包括:处理器2001、存储器2002和总线2003,存储器2002存储有执行指令,当第二电子设备运行时,处理器2001与存储器2002之间通过总线2003通信,处理器2001执行存储器2002中存储的由目标用户端所执行的消息同步方法的步骤。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。
Claims (16)
1.一种消息同步方法,其特征在于,包括:
消息记录端接收目标用户端上传的消息同步请求;消息同步请求中携带有第一消息的编号;
消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
消息记录端将查找到的所述第二消息发送给目标用户端。
2.根据权利要求1所述的方法,其特征在于,消息记录端将查找到的所述第二消息发送给目标用户端,包括:
消息记录端将多个第二消息的摘要发送给目标用户端,以使目标用户端生成用于选择第二消息的选择指令;
消息记录端将选择指令所对应的第二消息发送给目标用户端。
3.根据权利要求1所述的方法,其特征在于,消息记录端接收目标用户端上传的消息同步请求,包括:
消息记录端接收目标用户端在信息交互界面上通过响应用户的刷新操作而生成的消息同步请求;
消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息的编号之后,且消息生成时间最新的预定数量的消息作为第二消息。
4.根据权利要求1所述的方法,其特征在于,若消息同步请求中还携带有批量调取指令;则消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,
消息记录端将与目标用户端相关联的消息队列中,编号顺序排在第一消息之前的消息作为第二消息。
5.根据权利要求1所述的方法,其特征在于,若消息同步请求中还携带有多终端同步指令;则消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之后的消息作为第二消息;或,
消息记录端将与目标用户端相关联的多端消息队列中,编号顺序排在第一消息之前的消息作为第二消息;所述多端消息队列中存储有使用所述目标用户端的用户通过其他用户端登录时所发出或接收的消息。
6.根据权利要求1所述的方法,其特征在于,若消息同步请求中还携带有群消息同步指令;则消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息,包括:
消息记录端查找与所述群消息同步指令相对应的群消息队列;
消息记录端将群消息队列中,编号顺序排在第一消息的编号之后的消息作为第二消息;或,消息记录端将群消息队列中,编号顺序排在第一消息的编号之前的消息作为第二消息。
7.根据权利要求1所述的方法,其特征在于,在所述消息记录端接收目标用户端上传的消息同步请求之前,所述方法还包括:
消息记录端获取目标用户端上传的待传递消息;
消息记录端按照预设编号顺序,根据与目标用户端相关联的所述消息队列中已经存储的消息的编号,为待传递消息生成编号,以使待传递消息的编号和所述消息队列中已经存储的消息的编号是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;
消息记录端将所述待传递消息和所述待传递消息的编号关联存储在与目标用户端相关联的所述消息队列中;
消息记录端将与待传递消息相对应的编号发送给目标用户端,以使目标用户端将所述待传递消息和与所述待传递消息相对应的编号进行关联存储。
8.一种消息同步方法,其特征在于,包括:
目标用户端生成携带有第一消息的编号的消息同步请求;
目标用户端向消息记录端上传消息同步请求;以使消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
目标用户端接收消息记录端所返回的第二消息。
9.根据权利要求8所述的方法,其特征在于,在所述目标用户端生成携带有第一消息的编号的消息同步请求之前,所述方法还包括:
目标用户端根据已经存储在目标用户端中的第一消息的编号与预设编号顺序的匹配情况,确定目标用户端中未存储的消息;
目标用户端根据目标用户端中未存储的消息,确定第一消息的编号。
10.根据权利要求8所述的方法,其特征在于,在所述目标用户端生成携带有第一消息的编号的消息同步请求之前,所述方法还包括:
目标用户端在消息交互页面上接收到用户所下达的消息刷新指令后,根据目标用户端中已存储的编号顺序最后的消息的编号,确定第一消息的编号。
11.一种消息同步装置,其特征在于,设置于消息记录端,所述消息同步装置包括:
第一接收模块,用于接收目标用户端上传的消息同步请求;消息同步请求中携带有第一消息的编号;
第一查找模块,用于以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
第一发送模块,用于将查找到的所述第二消息发送给目标用户端。
12.一种消息同步装置,其特征在于,设置于目标用户端,所述消息同步装置包括:
第一生成模块,用于生成携带有第一消息的编号的消息同步请求;
第一上传模块,用于向消息记录端上传消息同步请求;以使消息记录端以第一消息的编号为基准,从与目标用户端相关联的消息队列中查找符合消息同步规则的第二消息;所述目标用户端中和所述消息队列中的相同消息的编号是一致的;所述消息队列中每个消息的编号均是按照预设编号顺序和消息生成时间的先后顺序,连续排列的;消息同步规则用于描述第一消息的编号和第二消息的编号的关系;
第二接收模块,用于接收消息记录端所返回的第二消息。
13.一种计算机可读存储介质,其特征在于,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如权利要求1至7任一所述的消息同步方法的步骤。
14.一种计算机可读存储介质,其特征在于,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如权利要求8至10任一所述的消息同步方法的步骤。
15.一种电子设备,其特征在于,包括:处理器、存储介质和总线,所述存储介质存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,以执行如权利要求1至7任一所述的消息同步方法的步骤。
16.一种电子设备,其特征在于,包括:处理器、存储介质和总线,所述存储介质存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,以执行如权利要求8至10任一所述的消息同步方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811393611.1A CN109617949A (zh) | 2018-11-21 | 2018-11-21 | 一种消息同步方法、装置、存储介质和电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811393611.1A CN109617949A (zh) | 2018-11-21 | 2018-11-21 | 一种消息同步方法、装置、存储介质和电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109617949A true CN109617949A (zh) | 2019-04-12 |
Family
ID=66004465
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811393611.1A Pending CN109617949A (zh) | 2018-11-21 | 2018-11-21 | 一种消息同步方法、装置、存储介质和电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109617949A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111292084A (zh) * | 2020-03-10 | 2020-06-16 | 北京意锐新创科技有限公司 | 适用于支付设备的多方交互查账方法和装置 |
CN112217712A (zh) * | 2020-09-24 | 2021-01-12 | 福建天泉教育科技有限公司 | 消息多端同步的方法、客户端 |
CN113765985A (zh) * | 2021-01-15 | 2021-12-07 | 北京京东拓先科技有限公司 | 用于同步消息的方法和装置 |
CN117520460A (zh) * | 2024-01-05 | 2024-02-06 | 成都安世赛斯特软件技术有限公司 | 一种自定义编号生成管理方法及系统 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103051520A (zh) * | 2013-01-05 | 2013-04-17 | 北京小米科技有限责任公司 | 即时通信工具中同步离线会话消息的方法及装置 |
CN103220334A (zh) * | 2013-03-20 | 2013-07-24 | 深圳市理邦精密仪器股份有限公司 | 一种分布式中央监护系统及其方法 |
WO2013151899A1 (en) * | 2012-04-05 | 2013-10-10 | Box, Inc. | Device pinning capability for enterprise cloud service and storage accounts |
CN103516723A (zh) * | 2013-09-22 | 2014-01-15 | 大唐移动通信设备有限公司 | Sip消息处理方法与装置 |
CN104901865A (zh) * | 2015-04-20 | 2015-09-09 | 上海云睦网络科技有限公司 | 一种基于全局单调序列号的移动端即时通讯信号同步方法 |
CN108512741A (zh) * | 2018-02-06 | 2018-09-07 | 北京云中融信网络科技有限公司 | 即时通讯方法、装置及系统 |
-
2018
- 2018-11-21 CN CN201811393611.1A patent/CN109617949A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013151899A1 (en) * | 2012-04-05 | 2013-10-10 | Box, Inc. | Device pinning capability for enterprise cloud service and storage accounts |
CN103051520A (zh) * | 2013-01-05 | 2013-04-17 | 北京小米科技有限责任公司 | 即时通信工具中同步离线会话消息的方法及装置 |
CN103220334A (zh) * | 2013-03-20 | 2013-07-24 | 深圳市理邦精密仪器股份有限公司 | 一种分布式中央监护系统及其方法 |
CN103516723A (zh) * | 2013-09-22 | 2014-01-15 | 大唐移动通信设备有限公司 | Sip消息处理方法与装置 |
CN104901865A (zh) * | 2015-04-20 | 2015-09-09 | 上海云睦网络科技有限公司 | 一种基于全局单调序列号的移动端即时通讯信号同步方法 |
CN108512741A (zh) * | 2018-02-06 | 2018-09-07 | 北京云中融信网络科技有限公司 | 即时通讯方法、装置及系统 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111292084A (zh) * | 2020-03-10 | 2020-06-16 | 北京意锐新创科技有限公司 | 适用于支付设备的多方交互查账方法和装置 |
CN112217712A (zh) * | 2020-09-24 | 2021-01-12 | 福建天泉教育科技有限公司 | 消息多端同步的方法、客户端 |
CN113765985A (zh) * | 2021-01-15 | 2021-12-07 | 北京京东拓先科技有限公司 | 用于同步消息的方法和装置 |
CN117520460A (zh) * | 2024-01-05 | 2024-02-06 | 成都安世赛斯特软件技术有限公司 | 一种自定义编号生成管理方法及系统 |
CN117520460B (zh) * | 2024-01-05 | 2024-04-02 | 成都安世赛斯特软件技术有限公司 | 一种自定义编号生成管理方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109617949A (zh) | 一种消息同步方法、装置、存储介质和电子设备 | |
CN103916482B (zh) | 一种基于sqlite的数据同步传输方法 | |
CN104283926B (zh) | 一种数据同步方法、装置及服务器 | |
CN102368261A (zh) | 一种可扩展的运维报表生成方法 | |
CN102495910A (zh) | 实现异构系统数据定时同步的装置和方法 | |
CN109040298A (zh) | 基于边缘计算技术的数据处理方法及装置 | |
US20140006523A1 (en) | System and Method to Enable Communication Group Identification | |
CN110380954A (zh) | 数据分享方法和装置,存储介质及电子装置 | |
CN114189052B (zh) | 电厂状态监控系统与监控方法 | |
CN102868936B (zh) | 存储视频日志的方法和系统 | |
CN109062489A (zh) | 消息处理方法、装置、存储介质及电子装置 | |
CN101883094B (zh) | 嵌入式通用即插即用工业监控网络数据库服务系统 | |
CN106453050A (zh) | 基于社交应用的信息处理方法、系统以及相关设备 | |
CN104935660A (zh) | 一种云程序开发运行系统、方法及装置 | |
CN104869048A (zh) | 微博数据的分组处理方法、装置及系统 | |
CN103581317B (zh) | 一种网络资源共享的方法 | |
CN105205062B (zh) | 数据存储方法、数据读取方法和装置 | |
CN101505285A (zh) | 内容分发方法、业务交付平台、业务终端和系统 | |
CN103299298B (zh) | 处理业务的方法和系统 | |
CN108173899B (zh) | 区块链的信息处理方法及装置 | |
CN106446050A (zh) | 一种针对数据库的变化数据进行订阅的方法及系统 | |
CN110389817A (zh) | 多云系统的调度方法、装置和计算机程序产品 | |
CN109683898A (zh) | 一种基于云编译的编译方法及云编译系统 | |
CN106469330A (zh) | 信息查找方法、信息存储方法及装置 | |
CN109525469A (zh) | 智能家居设备的联网方法及智能家居设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190412 |