2011-09-20 58 views
2

我想在我的特定应用程序中获得关于服务“名单”的建议的一些反馈。我有一个服务器应用程序来维护与客户端的持久套接字连接。我想进一步开发服务器来支持分布式实例。服务器“A”需要能够将数据广播到其他在线服务器实例。所有其他活动实例也一样。分布式服务器实例之间的数据广播

选项我试图研究:

  1. 的Redis /动物园管理员/道崎 - 每个服务器实例将其自身注册到配置服务器,并且它改变了所有连接的服务器将获得配置更新。然后怎样呢?
    1. 维护与每个服务器实例的端到端连接并使用每个传出数据遍历列表?
    2. 一些自定义的UDP组播,但我需要推出自己增加的可靠性。
  2. 自定义消息代理 - 每个服务器连接并通知它时运行和维护注册表的服务。保持与每个服务器的连接以接受数据并将其重新广播给其他服务器。
  3. 一些可靠的UDP多播传输,其中每个服务器实例只是直接广播,并且没有维护名单。

这里是我的顾虑:

  • 我很想避免依赖于外部的应用程序,像动物园管理员或道崎,但我显然会使用他们,如果它的最佳解决方案
  • 通过自定义消息代理,我不希望它成为吞吐量的瓶颈。这意味着我可能还必须能够运行多个消息代理并在扩展时使用负载均衡器?
  • 多播并不需要任何外部过程,如果我设法推出我自己的,但否则我需要也许使用ZMQ,这又使我处于依赖的情况。

我意识到我也在谈论邮件传递,但它与我一起提供的解决方案携手并进。 顺便说一句,我的服务器是用Go编写的。任何关于保持可伸缩性的最佳推荐方式的想法?

*的目标编辑*

什么我真的问的是什么,是落实在分布式服务器实例之间广播数据的最佳方式如下:

  1. 每个服务器实例维护与其远程客户端的持续TCP套接字连接并在它们之间传递消息。
  2. 消息需要能够广播到其他正在运行的实例,以便它们可以传送到相关的客户端连接。
  3. 低延迟非常重要,因为消息传递速度很快。
  4. 序列和可靠性很重要。

*更新问题内容*

如果你有多个服务器需要的pub/sub相互之间/多个端点,什么是它们之间的通信的推荐模式?一个或多个消息代理将消息重新发布到已发现服务器的名单中?从每个服务器直接可靠的组播? 如何在分布式系统中连接多个端点,同时保持低延迟,高速和交付可靠?

+0

现在想提一下,Redis可能不可避免地成为系统的一部分,无论如何作为数据历史的持久存储。所以我认为它可能是注册服务和通过其pub/sub功能通知的明显途径。 – jdi

+0

你的延迟请求是什么? – lunixbochs

+0

它是一个高速消息服务器,所以延迟时间要低。消息进入并传播给频道订阅者,但最终使用持久套接字服务器时,我会遇到两个文件描述符限制,并最终达到客户端端口范围限制。因此,我将不得不运行多个实例,并仍允许消息跳入其他实例中的队列,以便分发给可能在这些实例中订阅相同频道的任何人。 – jdi

回答

2

假设所有面向客户端的端点都位于同一个局域网上(它们可以用于扩展的第一个合理步骤),可靠的UDP多播将允许您直接从发布端点发送发布的消息到任何有客户订阅该频道的终端。这也比通过持久存储层代理数据更好地满足低延迟要求。

多点传送组

  • 中央数据库(比如说,Redis的)可以跟踪地图上的组播组(IP:PORT)< - >信道。
  • 当一个端点接收到一个新的客户端并有一个新的频道订阅时,它可以向数据库询问该频道的多播地址并加入多播组。

可靠UDP多播

  • 当端点接收用于信道发布的消息时,它将该消息发送到该信道的多播套接字。
  • 消息数据包将包含每个服务器每个多播组的有序标识符。如果端点在未收到来自服务器的前一条消息的情况下收到消息,则它会发送“未确认”消息,以显示任何错过它回发布服务器的消息。
  • 发布服务器跟踪最近消息的列表,并重新发送NAK'd消息。
  • 要处理服务器的边缘情况,只发送一条消息,并且无法到达服务器,服务器可以在其NAK队列的整个生存期内向组播组发送数据包计数:“我发送了24条消息” ,为其他服务器提供NAK先前消息的机会。

您可能想要实施PGM。

持久性存储

如果最终存储数据长期存储服务可以加入组播组就像终点......但邮件,而不是存储在数据库将它们发送到客户端。