本发明涉及通信技术领域，尤其涉及一种实时消息传递方法及系统。
背景技术：
随着科技的发展，即时通讯(instantmessaging)是目前internet上最为流行的通讯方式，各种各样的即时通讯软件也层出不穷，服务提供商也提供了越来越丰富的通讯服务功能。
当前对于即时通讯的消息处理方法，两个用户之间进行消息传递，服务器为保证高效率利用资源，一般采用并行的方式处理用户发送的实时消息，用户发送的实时消息往往会被多条线程同时处理，由于网络、cpu调度和多服务器同时运行等原因可能会出现消息顺序错乱，并且进行消息推送的时候，都会选择直接推送消息内容到客户端，容易因为网络抖动等原因发生消息错落。
因此，导致了当前的实时消息传递方法稳定性差，容易导致消息传递顺序错乱，一致性被破坏的技术问题。
技术实现要素：
本发明提供了一种实时消息传递方法及系统，解决了当前的实时消息传递方法稳定性差，容易导致消息传递顺序错乱，一致性被破坏的技术问题。
本发明提供了一种实时消息传递方法，包括：
s1：第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中；
s2：第二接入层通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取；
s3：消息引擎根据实时消息中发送端的第一用户id和接收端的第二用户id生成递增的消息序列号，将实时消息和消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；
s4：接收端判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号。
优选地，步骤s1具体包括：第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中并且不同的发送端对应不同的消息队列。
优选地，步骤s2具体包括：第二接入层通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理并且每一个消息队列对应不同的处理线程，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取。
优选地，步骤s3具体包括：
s31：消息引擎根据实时消息中发送端的第一用户id和接收端的第二用户id获取上一次生成的消息序列号，将上一次生成的消息序列号加上预置数值生成实时消息对应的消息序列号，其中，每一组第一用户id和第二用户id对应的消息序列号独立生成，预置数值大于0；
s32：消息引擎将实时消息和实时消息对应的消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；
s33：消息引擎判断上一次生成的消息序列号是否能够整除序列号批量申请数量，若是，则将用户最大序列号加上序列号批量申请数量得到新的用户最大序列号，并将新的用户最大序列号存入持久化服务端中替换原有的用户最大序列号。
优选地，步骤s5具体包括：接收端判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号，若否，则不对第三接入层发送的消息序列号进行处理。
本发明提供了一种实时消息传递系统，包括：
第一接入层，用于接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中；
第二接入层，用于通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取；
消息引擎，用于根据实时消息中发送端的第一用户id和接收端的第二用户id生成递增的消息序列号，将实时消息和消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；
接收端，用于判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号。
优选地，第一接入层，具体用于接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中并且不同的发送端对应不同的消息队列。
优选地，第二接入层，具体用于通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理并且每一个消息队列对应不同的处理线程，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取。
优选地，消息引擎具体包括：
序列号生成单元，用于根据实时消息中发送端的第一用户id和接收端的第二用户id获取上一次生成的消息序列号，将上一次生成的消息序列号加上预置数值生成实时消息对应的消息序列号，其中，每一组第一用户id和第二用户id对应的消息序列号独立生成，预置数值大于0；
消息存储单元，用于将实时消息和实时消息对应的消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；
最大序列号单元，用于判断上一次生成的消息序列号是否能够整除序列号批量申请数量，若是，则将用户最大序列号加上序列号批量申请数量得到新的用户最大序列号，并将新的用户最大序列号存入持久化服务端中替换原有的用户最大序列号。
优选地，接收端，具体用于判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号，若否，则不对第三接入层发送的消息序列号进行处理。
从以上技术方案可以看出，本发明具有以下优点：
本发明提供了一种实时消息传递方法，包括：
s1：第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中；s2：第二接入层通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取；s3：消息引擎根据实时消息中发送端的第一用户id和接收端的第二用户id生成递增的消息序列号，将实时消息和消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；s4：接收端判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号。
本发明中的实时消息传递方法中单用户的消息串行化处理，同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列并且同一个消息队列的实时消息由同一个处理线程进行处理，只有当前一条实时消息处理完毕后才获取下一条实时消息，保障用户实时消息的顺序性和一致性，并且将实时消息发送给接受消息的接收端时并不是直接将实时消息发送到接收端，而是只发送消息序列号，然后客户端根据消息序列号拉取消息，这种客户端消息拉取(同步)机制，结合服务器的消息绝对顺序性，有效保障消息顺序性及一致性同时减少ack风暴存在的可能，解决了当前的实时消息传递方法稳定性差，容易导致消息传递顺序错乱，一致性被破坏的技术问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1为本发明实施例提供的一种实时消息传递方法的一个实施例的流程示意图；
图2为本发明实施例提供的一种实时消息传递方法的另一个实施例的流程示意图；
图3为本发明实施例提供的一种实时消息传递系统的一个实施例的连接关系示意图。
具体实施方式
本发明实施例提供了一种实时消息传递方法及系统，解决了当前的实时消息传递方法稳定性差，容易导致消息传递顺序错乱，一致性被破坏的技术问题。
为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
请参阅图1，本发明实施例提供了一种实时消息传递方法的一个实施例，包括：
步骤101：第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中；
需要说明的是，接入层负责各个客户端的长连接，接受发送端发送的消息和发送消息到接收端；
发送端指代发送消息的客户端，接收端指代接收消息的客户端；
每一个发送端发送的实时消息包含相同的第一用户id，不同发送端发送的实时消息包含的第一用户id不同；
第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中，这样保证同一个发送端发送的消息不会因为进入不同的消息队列而导致各个实时消息的处理顺序与发送端发送的顺序不符。
步骤102：第二接入层通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取；
需要说明的是，同一个消息队列的的实时消息由第二接入层的同一个处理线程进行处理，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取，对于相同的发送端而言，这样可以保证后续的消息必然只会被相同的单条线程进行处理，不会出现消息处理混乱的现象；
同时利用消息队列限流。若消息引擎所在的服务器无法及时处理，后续的实时消息只会堆积在消息队列，而不会导致消息引擎所在的服务器资源耗尽。
步骤103：消息引擎根据实时消息中发送端的第一用户id和接收端的第二用户id生成递增的消息序列号，将实时消息和消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；
需要说明的是，每一组第一用户id和第二用户id对应的消息序列号独立生成；
通过消息序列号进行对实时消息顺序的标记，则必须保证在后生成的消息序列号要小于在先生成的消息序列号，所以消息引擎根据实时消息的发送端的第一用户id和接收端的第二用户id生成递增的消息序列号，这样确保了在后生成的消息序列号要小于在先生成的消息序列号；
生成消息序列号后将实时消息和消息序列号存入缓存服务端可以使得接收端快速地提取消息，但是由于缓存服务端并非持续性存储，所以当服务器重启或者数据存储超过缓存服务端的存储时间时，将实时消息和消息序列号存入持久化服务端中可以保证接收端能够在服务器重启后或者数据存储超过缓存服务端的存储时间之后依然可以提取到实时消息和消息序列号；
消息引擎可以通过通讯录服务端获取收发双方的信息，可根据第二用户id调用会话服务端查询与接收端连接的接入层，即第三接入层，然后消息引擎通过第三接入层将消息序列号发送到与第二用户id对应的接收端。
步骤104：接收端判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号。
需要说明的是，接收端接收到第三接入层转发的消息序列号之后，判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则说明服务器中有新的实时消息待拉取，若否，则说明这是之前已经接受过的实时消息的消息序列号，所以若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号。
本实施例中的实时消息传递方法中，单用户的消息串行化处理，同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列并且同一个消息队列的实时消息由同一个处理线程进行处理，只有当前一条实时消息处理完毕后才获取下一条实时消息，保障用户实时消息的顺序性和一致性，并且将实时消息发送给接受消息的接收端时并不是直接将实时消息发送到接收端，而是只发送消息序列号，然后客户端根据消息序列号拉取消息，这种客户端消息拉取(同步)机制，结合服务器的消息绝对顺序性，有效保障消息顺序性及一致性同时减少ack风暴存在的可能，解决了当前的实时消息传递方法稳定性差，容易导致消息传递顺序错乱，一致性被破坏的技术问题。
以上为本发明实施例提供的一种实时消息传递方法的一个实施例，以下为本发明实施例提供的一种实时消息传递方法的另一个实施例。
请参阅图2，本发明实施例提供了一种实时消息传递方法的另一个实施例，包括：
步骤201：第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中并且不同的发送端对应不同的消息队列；
需要说明的是，每一个发送端发送的实时消息包含相同的第一用户id，不同发送端发送的实时消息包含的第一用户id不同；
第一接入层接收到各个发送端发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列中，这样保证同一个发送端发送的消息不会因为进入不同的消息队列而导致各个实时消息的处理顺序与发送端发送的顺序不符；
同时不同的发送端对应不同的消息队列则使得发送端与消息队列为一一对应的关系，这样设置可以提高不同的发送端的实时消息可以并行处理，提高消息处理效率。
步骤202：第二接入层通过订阅消息队列服务端获取到消息队列中的实时消息并将实时消息发送到消息引擎进行处理，同一个消息队列的实时消息由第二接入层的同一个处理线程进行处理并且每一个消息队列对应不同的处理线程，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取；
需要说明的是，同一个消息队列的的实时消息由第二接入层的同一个处理线程进行处理，第二接入层的处理线程接收到消息引擎返回的处理完成通知才进行下一次实时消息的获取，对于相同的发送端而言，这样可以保证后续的消息必然只会被相同的单条线程进行处理，不会出现消息处理混乱的现象；
同时利用消息队列限流。若消息引擎所在的服务器无法及时处理，后续的实时消息只会堆积在消息队列，而不会导致消息引擎所在的服务器资源耗尽；
每一个消息队列对应不同的处理线程使得各个消息队列可以被第二接入层并行处理，充分利用第二接入层所在服务器的cpu资源，提高系统的并发量。
步骤203：消息引擎根据实时消息中发送端的第一用户id和接收端的第二用户id获取上一次生成的消息序列号，将上一次生成的消息序列号加上预置数值生成实时消息对应的消息序列号，其中，每一组第一用户id和第二用户id对应的消息序列号独立生成，预置数值大于0；
需要说明的是，通过消息序列号进行对实时消息顺序的标记，则必须保证在后生成的消息序列号要小于在先生成的消息序列号，所以消息引擎根据实时消息的发送端的第一用户id和接收端的第二用户id获取为第一用户id上一次生成的消息序列号，预置数值大于0，这样确保了在后生成的消息序列号要小于在先生成的消息序列号，预置的数值可以根据应用过程中的需要进行选择，优选为1；
每一组第一用户id和第二用户id对应的消息序列号独立生成是指a和b的消息序列号生与c和d的消息序列号生成不会互相影响。
步骤204：消息引擎将实时消息和实时消息对应的消息序列号存入缓存服务端和持久化服务端中，返回处理完成通知到第二接入层，并通过第三接入层将消息序列号发送到与第二用户id对应的接收端；
需要说明的是，消息引擎将实时消息和实时消息对应的消息序列号存入缓存服务端和持久化服务端中并返回处理完成通知到第二接入层，第二接入层即进入下一次实时消息的获取，进行下一个处理进程；
生成消息序列号后将实时消息和消息序列号存入缓存服务端可以使得接收端快速地提取消息，但是由于缓存服务端并非持续性存储，所以当服务器重启或者数据存储超过缓存服务端的存储时间时，将实时消息和消息序列号通过消息管理器存入持久化服务端中可以保证接收端能够在服务器重启后或者数据存储超过缓存服务端的存储时间之后依然可以提取到实时消息和消息序列号；
会话服务端会保存各个客户端的连接信息，如客户端连接哪个服务器的接入层；
消息引擎可以通过通讯录服务端获取收发双方的信息，可根据第二用户id调用会话服务端查询与接收端连接的接入层，即第三接入层，然后消息引擎通过第三接入层将消息序列号发送到与第二用户id对应的接收端。
步骤205：消息引擎判断上一次生成的消息序列号是否能够整除序列号批量申请数量，若是，则将用户最大序列号加上序列号批量申请数量得到新的用户最大序列号，并将新的用户最大序列号存入持久化服务端中替换原有的用户最大序列号；
需要说明的是，消息引擎通过序列号生成器生成消息序列号可以每一次获取到实时消息时调用序列号生成器生成消息序列号，但是这种生成方式效率低下；
本实施例中一次性批量生成预置数量的消息序列号，其中的预置数量为序列号批量申请数量，批量生成后的最大的消息序列号为用户最大序列号，这样消息引擎就不需要每一次获取序列号都通过序列号生成器生成消息序列号，提高了消息序列号的生成效率；
并且同时将最大的消息序列号存入持久化服务端中，这样当发生意外服务器中缓存数据丢失时，可以直接提取持久化服务端中的用户最大序列号作为最新生成的消息序列号，中间因为故障未能确地是否被使用的消息序列号全部跳过，保证消息序列号单调增长以保证实时消息发送的顺序性和一致性；
消息引擎判断上一次生成的消息序列号是否能够整除序列号批量申请数量，则说明此时上一批批量生成的消息序列号已经用完，需要重新通过序列号生成器生成下一批的消息序列号，得到新的用户最大序列号，并将新的用户最大序列号存入持久化服务端中替换原有的用户最大序列号；
当服务器故障丢失数据，如服务器重启，则直接使用用户最大序列号作为当前生成的消息序列号，如上一次消息序列号为207，用户最大序列号为300，但是数据丢失，重启后无法判断中间的消息序列号是否已经被使用，则直接跳过中间的消息序列号，本次需要生成消息序列号时直接采用用户最大消息序列号300作为当前生成的消息序列号；
消息序列号生成采用的序列号生成器可以调用redislua脚本，利用redislua脚本的高性能及原子性特点，生成消息序列号。
步骤206：接收端判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号，若否，则不对第三接入层发送的消息序列号进行处理。
需要说明的是，接收端接收到第三接入层转发的消息序列号之后，判断第三接入层发送的消息序列号是否大于接收端本地的消息序列号，若是，则说明服务器中有新的实时消息待拉取，所以发送消息拉取请求到消息管理器使得消息管理器从缓存服务端或者持久化服务端中返回所有消息序列号大于接收端本地的消息序列号的实时消息到接收端，并将实时消息中最大的消息序列号作为新的接收端本地的消息序列号；
若否，则说明这是之前已经接受过的实时消息的消息序列号，所以不对第三接入层发送的消息序列号动作处理；
在完成写入缓存服务端和持久化服务端前是串行处理，一旦存储成功，则后续推送序列号到客户端可以恢复并行操作，因为写入缓存后，消息顺序已经固定，后续操作恢复多线程也能保证消息顺序性，如并行处理中可能消息序列号205比189先到达接收端，接收端本地消息序列号为188，接收端对205进行动作，拉取188之后所有未读取的消息，将205作为新的本地消息序列号，对后到达的189不动作，但是获取到的消息顺序与先接收189对189动作再对205动作得到的消息顺序是一致的；
通过消息拉取机制，有效防止客户端消息顺序错乱，保证收发双方的消息一致性，且减少一次客户端到服务器端的ack确认，有效降低ack风暴；
整个实时消息传递方法中涉及的各个接入层、消息引擎和服务端等可以是在同一台服务器上也可以分布设置在不同的服务器上，第一接入层、第二接入层和第三接入层可以是相同的接入层也可以是不同的接入层。
本实施例中的实时消息传递方法中，单用户的消息串行化处理，同一个发送端发送的实时消息转发到消息队列服务端的同一个消息队列并且同一个消息队列的实时消息由同一个处理线程进行处理，只有当前一条实时消息处理完毕后才获取下一条实时消息，保障用户实时消息的顺序性和一致性，并且将实时消息发送给接受消息的接收端时并不是直接将实时消息发送到接收端，而是只发送消息序列号，然后客户端根据消息序列号拉取消息，这种客户端消息拉取(同步)机制，结合服务器的消息绝对顺序性，有效保障消息顺序性及一致性同时减少ack风暴存在的可能，解决了当前的实时消息传递方法稳定性差，容易导致消息传递顺序错乱，一致性被破坏的技术问题；
同时，通过多用户并行化处理的机制可以提高资源利用率，提高实时消息传递系统的整体处理速度，通过消息序列号的批量生成机制可提高消息序列号的生成速度以提高实时消息处理的速度。
以上为本发明实施例提供的一种实时消息传递方法的另一个实施例，以下为本发明实施例提供的一种实时消息传递系统的一个实施例。
请参阅图3，本发明实施例提供了一种实时消息传递系统的一个实施例，包括：
第一接入层301，用于接收到各个发送端300发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端300发送的实时消息转发到消息队列服务端305的同一个消息队列中；
第二接入层302，用于通过订阅消息队列服务端305获取到消息队列中的实时消息并将实时消息发送到消息引擎303进行处理，同一个消息队列的实时消息由第二接入层302的同一个处理线程进行处理，第二接入层302的处理线程接收到消息引擎303返回的处理完成通知才进行下一次实时消息的获取；
消息引擎303，用于根据实时消息中发送端的第一用户id和接收端的第二用户id生成递增的消息序列号，将实时消息和消息序列号存入缓存服务端309和持久化服务端310中，返回处理完成通知到第二接入层302，并通过第三接入层308将消息序列号发送到与第二用户id对应的接收端304；
接收端304，用于判断第三接入层308发送的消息序列号是否大于接收端304本地的消息序列号，若是，则发送消息拉取请求到消息管理器311使得消息管理器311从缓存服务端309或持久化服务端310中返回所有消息序列号大于接收端304本地的消息序列号的实时消息到接收端403，并将实时消息中最大的消息序列号作为新的接收端304本地的消息序列号。
进一步地，第一接入层301，具体用于接收到各个发送端300发送的实时消息，并根据各个实时消息中的第一用户id将同一个发送端300发送的实时消息转发到消息队列服务端305的同一个消息队列中并且不同的发送端300对应不同的消息队列。
进一步地，第二接入层302，具体用于通过订阅消息队列服务端305获取到消息队列中的实时消息并将实时消息发送到消息引擎303进行处理，同一个消息队列的实时消息由第二接入层302的同一个处理线程进行处理并且每一个消息队列对应不同的处理线程，第二接入层302的处理线程接收到消息引擎303返回的处理完成通知才进行下一次实时消息的获取。
进一步地，消息引擎303具体包括：
序列号生成单元3031，用于根据实时消息中发送端300的第一用户id和接收端304的第二用户id获取上一次生成的消息序列号，将上一次生成的消息序列号加上预置数值生成实时消息对应的消息序列号，其中，每一组第一用户id和第二用户id对应的消息序列号独立生成，预置数值大于0；
消息存储单元3032，用于将实时消息和实时消息对应的消息序列号存入缓存服务端309和持久化服务端310中，返回处理完成通知到第二接入层302，并通过第三接入层308将消息序列号发送到与第二用户id对应的接收端304；
最大序列号单元3033，用于判断上一次生成的消息序列号是否能够整除序列号批量申请数量，若是，则将用户最大序列号加上序列号批量申请数量得到新的用户最大序列号，并将新的用户最大序列号存入持久化服务端310中替换原有的用户最大序列号。
进一步地，接收端304，具体用于判断第三接入层308发送的消息序列号是否大于接收端304本地的消息序列号，若是，则发送消息拉取请求到消息管理器311使得消息管理器311从缓存服务端309或持久化服务端310中返回所有消息序列号大于接收端304本地的消息序列号的实时消息到接收端304，并将实时消息中最大的消息序列号作为新的接收端304本地的消息序列号，若否，则不对第三接入层308发送的消息序列号进行处理。
以上为本发明实施例提供的一种实时消息传递系统的一个实施例，以下为本发明实施例提供的一种实时消息传递系统的一个应用例。
本发明实施例提供了一种实时消息传递系统的一个应用例，包括：
1、发送端发送了实时消息a到第一接入层；、
2、第一接入层将实时消息a发送到消息队列服务端rabbitmq(4条消息队列)中，并返回发送时间ack到发送端；
3、消息队列服务端将消息a入队，返回入队通知到第一接入层，其中同一个发送端发送的实时消息存入同一个消息队列中；
4、第二接入层订阅了消息队列服务端，如消息队列中包含a-、a和a+，同一个消息队列由第二接入层的同一个处理进程进行处理，则第二接入层在处理完实时消息a-之前不会获取实时消息a，第二接入层获取到实时消息a后将实时消息a发送到消息引擎进行处理，并返回实时消息a的出队通知到消息队列服务端中；
5、消息引擎调用通讯录服务端获取收发双方的信息，根据第一用户id和第二用户id获取上一次生成的消息序列号，将上一次生成的消息序列号加上预置数值生成实时消息a对应的消息序列号，如上一次生成的消息序列号为200，则将200+1生成实时消息a对应的消息序列号201，并且判断上一次生成的消息序列号200是否能够整除序列号批量申请数量100，如果可以整除，则说明上一次批量申请的消息序列号已经用尽，则再次批量申请100个，将用户最大序列号200加上序列号批量申请数量100得到新的用户最大序列号300并存入持久化服务端中，即缓存服务端和持久化服务端中都存有两个序列号关键信息，当前生成的消息序列号和用户最大序列号，存储方式可以用2个hash结构存储；
6、消息引擎将实时消息a和消息序列号201存入缓存服务端redis和持久化服务端mongodb中；
7、消息引擎调用会话服务端获取接收端所在第三接入层(消息路由)，将消息序列号201通过第三接入层发送到接收端，并返回处理完成通知到第二接入层，使得第二接入层从消息队列服务端中获取下一条实时消息a+进行处理；
8、接收端将消息序列号201与本地的消息序列号进行比较，如本地的消息序列号为195，则将201作为新的本地序列号，并发送消息拉取请求到消息管理器中，使得消息管理器拉取所有消息序列号大于旧的接收端本地的消息序列号195的实时消息到接收端，如本地的消息序列号为202，则不对消息序列号201动作处理。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。