2

我正在尝试就我的特定应用程序中的服务“名册”建议获得一些反馈。我有一个与客户端保持持久套接字连接的服务器应用程序。我想进一步开发服务器以支持分布式实例。服务器“A”需要能够将数据广播到其他在线服务器实例。所有其他活动实例也是如此。

我正在尝试研究的选项:

  1. Redis / Zookeeper / Doozer - 每个服务器实例都会将自己注册到配置服务器,并且所有连接的服务器都会在配置更改时接收到配置更新。然后怎样呢?
    1. 维护与每个服务器实例的端到端连接并使用每个传出数据迭代列表?
    2. 一些自定义的 UDP 多播,但我需要在它之上增加我自己的可靠性。
  2. 自定义消息代理 - 在每个服务器连接并通知它时运行和维护注册表的服务。与每个服务器保持连接以接受数据并将其重新广播到其他服务器。
  3. 一些可靠的 UDP 多播传输,其中每个服务器实例只是直接广播并且不维护名册。

以下是我的担忧:

  • 我很想避免依赖外部应用程序,例如 zookeeper 或 doozer,但如果它是最好的解决方案,我显然会使用它们
  • 使用自定义消息代理,我不希望它成为吞吐量的瓶颈。这意味着我可能还必须能够运行多个消息代理并在扩展时使用负载均衡器?
  • 如果我设法自己滚动,多播不需要任何外部进程,但否则我可能需要使用 ZMQ,这再次使我处于依赖的情况。

我意识到我也在谈论消息传递,但它与我采用的解决方案密切相关。顺便说一句,我的服务器是用 Go 编写的。关于保持可扩展性的最佳推荐方法的任何想法?

* 目标编辑 *

我真正要问的是,在给定以下条件的情况下,在分布式服务器实例之间实现广播数据的最佳方法是什么:

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

*更新的问题摘要*

如果您有多个服务器/多个端点需要在彼此之间发布/订阅,那么它们之间的推荐通信模式是什么?一个或多个消息代理将消息重新发布到一组已发现的服务器?直接来自每台服务器的可靠多播?如何在分布式系统中连接多个端点,同时保持低延迟、高速度和可靠交付?

4

1 回答 1

2

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

组播组

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

可靠的 UDP 组播

  • 当端点接收到通道的发布消息时,它会将消息发送到该通道的多播套接字。
  • 消息包将包含每个服务器每个多播组的有序标识符。如果端点接收到一条消息而没有从服务器接收到先前的消息,它将为它错过的任何消息发送一条“未确认”消息给发布服务器。
  • 发布服务器跟踪最近消息的列表,并重新发送 NAK 的消息。
  • 为了处理服务器仅发送一条消息并且无法到达服务器的边缘情况,服务器可以在其 NAK 队列的生命周期内向多播组发送数据包计数:“我已发送 24 条消息”,给出其他服务器有机会拒绝以前的消息。

您可能只想实现 PGM。

持久存储

如果您最终长期存储数据,存储服务可以像端点一样加入多播组......但将消息存储在数据库中而不是将它们发送到客户端。

于 2011-09-20T20:21:31.387 回答