一种用户消息发布方法及系统与流程

本发明涉及互联网技术领域，特别涉及一种用户消息发布方法及系统。

背景技术：

随着互联网技术的发展，网络变得越来越重要。而随着用户数量的增长，网络服务器的压力也越来越大。用户消息的发布以及对应用户的各种操作都需要通过服务器完成，大用户量尤其是瞬时用户量的增大，给服务器带来的巨大的压力。

为了保证服务器的顺利运作，出现了各种负载均衡的解决方案。负载均衡，英文名称为Load Balance，其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。

软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。

硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量 管理，可达到最佳的负载均衡需求。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群做负载均衡，全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。

本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，充分利用现有设备，避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级，也只是简单地增加一个新的服务器到服务群中，而不需改变现有网络结构、停止现有的服务。

全局负载均衡主要用于在一个多区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度，也可用于子公司分散站点分布广的大公司通过Intranet(企业内部互联网)来达到资源统一合理分配的目的。

负载均衡有三种部署方式：路由模式、桥接模式、服务直接返回模式。

路由模式部署灵活，约60％的用户采用这种方式部署；桥接模式不改变现有的网络架构；服务直接返回(DSR)比较适合吞吐量大特别是内容分发的网络应用。约30％的用户采用这种模式。

现有技术中，各种负载均衡方案均可以解决负载均衡的问题，但是，效果不一而足。同时，针对具体应用环境而产生的负载均衡机制目前均有不完善之处。尤其是对于用户服务器之间的负载均衡问题，目前大多采用轮询的方式进 行，尚没有一种可以有效解决负载均衡问题，同时又能够提高效率，不会对现有网络造成很大改变的方案。

技术实现要素：

本发明提供一种用户消息发布方法及系统，用以解决现有技术中用户消息发布负载均衡的问题。

本发明提供一种用户消息发布方法，包括：

发布服务器将发布消息发布到消息队列；

用户服务器监听所述消息队列；

用户服务器将监听到的发布消息在自身所属用户中发布。

所述方法还包括：

所述用户服务器通过web socket协议连接到所述发布服务器。

所述方法还包括：

所述用户服务器将监听到的发布消息保存到本地，并在自身所属用户中广播。

所述方法还包括：

所述用户服务器监听所述消息队列，若监听到发送给自身所属用户的发布消息，则将所述发布消息发送对应用户；否则，不作处理。

所述方法还包括：

所述消息队列中按照先入先出的原则顺序排列需要发布的发布消息。

所述方法还包括：

所述用户分别接入对应的用户服务器，并从所述用户服务器获取所述发布消息。

一种用户消息发布系统，包括：

发布服务器，用于将发布消息发布到消息队列；

用户服务器，用于监听所述消息队列；并将监听到的发布消息在自身所属 用户中发布。

所述发布服务器包括消息队列，用于按照先入先出的原则顺序排列需要发布的发布消息。

所述用户服务器通过web socket协议连接到所述发布服务器。

所述系统还包括用户终端，用于分别接入对应的用户服务器，并从所述用户服务器获取所述发布消息。

本发明实施例中，通过发布服务器将发布消息发布到消息队列；用户服务器监听所述消息队列；用户服务器将监听到的发布消息在自身所属用户中发布。本发明实施例的方案，能够在用户消息发布时候，发布服务器进行消息队列的发布，各用户服务器通过监听消息队列获取对应的发布消息，从而发布给自身所属的用户，提高了用户消息发布的效率，同时，在各个用户服务器之间实现了负载均衡配置，不会造成网络拥堵，降低了系统负担，极大的提高了用户体验度。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例1提供的一种用户消息发布方法原理流程图；

图2为本发明实施例2提供的一种用户消息发布系统结构示意图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

如图1所示，为本发明实施例1提供的一种用户消息发布方法原理流程图，其中，

步骤11，发布服务器将发布消息发布到消息队列。

发布服务器实际上是一台或者一组服务器，用以发布需要针对用户的消息。这些消息可以是针对某一用户的，也可以是针对多个或者全部用户的。发布服务器仅完成消息的发布，并不直接连接用户。

发布服务器获得需要发布的消息后，需要将该发布消息发布到消息队列。消息队列是一个特定的分组，可以按照堆栈的原理进行先入先出的消息顺序排列，也可以是根据其他方式进行消息排列。消息队列的作用就在于将发布消息进行排列，或者也可以存储发布消息本身。

“消息队列”是在消息的传输过程中保存消息的容器。消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

“消息队列”是一种消息处理技术，它为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。

“消息队列网络”是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。

“消息队列”安装期间，管理员确定哪些服务器可以互相通信，并设置特定服务器的特殊角色。构成此“消息队列”网络的计算机称为“站点”，它们之间通 过“站点链接”相互连接。每个站点链接都有一个关联的“开销”，它由管理员确定，指示了经过此站点链接传递消息的频率。

消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。

现有技术中，主要有两种类型的消息队列：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。考虑到程序的可移植性，新开发的应用程序应尽量使用POSIX消息队列。本实施例对消息队列的形式不做限定。

系统V消息队列是随内核持续的，只有在内核重起或者显示删除一个消息队列时，该消息队列才会真正被删除。因此系统中记录消息队列的数据结构(struct ipc_ids msg_ids)位于内核中，系统中的所有消息队列都可以在结构msg_ids中找到访问入口。消息队列就是一个消息的链表。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息，包括消息队列键值、用户ID、组ID、消息队列中消息数目等等，甚至记录了最近对消息队列读写进程的ID。读者可以访问这些信息，也可以设置其中的某些信息。

“消息队列”管理员还在网络中设置一台或多台作为“路由服务器”的计算机。路由服务器查看各站点链接的开销，确定经过多个站点传递消息的最快和最有效的方法，以此决定如何传递消息。

步骤12，用户服务器监听所述消息队列。

用户服务器是与用户终端建立直接连接的服务器，其不仅要直接连接用户终端，处理用户终端的消息，同时，为了及时发布用户消息，还需要监听消息队列。

通常，用户服务器通过web socket协议连接到发布服务器。WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)。

在浏览器中通过http仅能实现单向的通信,comet可以一定程度上模拟双向通信,但效率较低,并需要服务器有较好的支持；flash中的socket和xmlsocket可以实现真正的双向通信,通过flex ajax bridge,可以在javascript中使用这两项功能.可以预见,如果websocket一旦在浏览器中得到实现,将会替代上面两项技术,得到广泛的使用.面对这种状况，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽并达到实时通讯。

现有技术中，为了实现即时通讯，所用的技术都是轮询(polling)。轮询是在特定的的时间间隔(如每1秒)，由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给客服端的浏览器。这种传统的HTTP request的模式带来很明显的缺点–浏览器需要不断的向服务器发出请求，然而HTTP request的header是非常长的，里面包含的有用数据可能只是一个很小的值，这样会占用很多的带宽。而比较新的技术去做轮询的效果是Comet–用了AJAX。但这种技术虽然可达到全双工通信，但依然需要发出请求。

HTML5 WebSocket设计出来的目的就是要取代轮询和Comet技术，使客户端浏览器具备像C/S架构下桌面系统的实时通讯能力。浏览器通过JavaScript向服务器发出建立WebSocket连接的请求，连接建立以后，客户端和服务器端就可以通过TCP连接直接交换数据。因为WebSocket连接本质上就是一个TCP连接，所以在数据传输的稳定性和数据传输量的大小方面，和轮询以及Comet技术比较，具有很大的性能优势。

在WebSocket API，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。在实现websocket连线过程中，需要通过浏览器发出websocket连线请求，然后服务器发出回应，这个过程通常称为“握手”(handshaking)。

WebSocket协议本质上是一个基于TCP的协议。为了建立一个 WebSocket连接，客户端浏览器首先要向服务器发起一个HTTP请求，这个请求和通常的HTTP请求不同，包含了一些附加头信息，其中附加头信息”Upgrade:WebSocket”表明这是一个申请协议升级的HTTP请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的WebSocket连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。

特别的，用户服务器将监听到的发布消息可以保存到本地，并在自身所属用户中广播。

步骤13，用户服务器将监听到的发布消息在自身所属用户中发布。

用户服务器监听到发布服务器发布到消息队列中的发布消息后，获取该消息，可以保存到本地，或者不作保存。用户服务器监听所述消息队列，若监听到发送给自身所属用户的发布消息，则将所述发布消息发送对应用户；否则，不作处理。

用户分别接入对应的用户服务器，并从所述用户服务器获取所述发布消息。用户与用户服务器之间的对应，通常可以是根据地域就近原则或者地址就近原则，所有的用户均有针对的用户服务器。

本发明实施例中，通过发布服务器将发布消息发布到消息队列；用户服务器监听所述消息队列；用户服务器将监听到的发布消息在自身所属用户中发布。本发明实施例的方案，能够在用户消息发布时候，发布服务器进行消息队列的发布，各用户服务器通过监听消息队列获取对应的发布消息，从而发布给自身所属的用户，提高了用户消息发布的效率，同时，在各个用户服务器之间实现了负载均衡配置，不会造成网络拥堵，降低了系统负担，极大的提高了用户体验度。

如图2所示，为本发明实施例2提供的一种用户消息发布系统结构示意图， 其中，

发布服务器21，用于将发布消息发布到消息队列；

用户服务器22，用于监听所述消息队列；并将监听到的发布消息在自身所属用户中发布。

特别的，上述发布服务器21包括消息队列，用于按照先入先出的原则顺序排列需要发布的发布消息。

特别的，上述用户服务器22通过web socket协议连接到发布服务器21。

特别的，上述系统还包括用户终端23，用于分别接入对应的用户服务器22，并从所述用户服务器22获取所述发布消息。

综上所述，本发明实施例中，通过发布服务器将发布消息发布到消息队列；用户服务器监听所述消息队列；用户服务器将监听到的发布消息在自身所属用户中发布。本发明实施例的方案，能够在用户消息发布时候，发布服务器进行消息队列的发布，各用户服务器通过监听消息队列获取对应的发布消息，从而发布给自身所属的用户，提高了用户消息发布的效率，同时，在各个用户服务器之间实现了负载均衡配置，不会造成网络拥堵，降低了系统负担，极大的提高了用户体验度。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入 式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。