推送事件的扩展 - 最佳拓扑？

Question

我已经构建了一个TCP服务器来处理来自客户端的RPC（请求/回复）类型请求，但它也允许服务在特定时间推送事件。

如果我需要在未来进行扩展，RPC的内容非常简单，比如Web基础架构，我只会添加更多节点和负载平衡。

要扩展推送消息，我需要所有服务器进行协调，因为订阅事件的客户端可以在任何服务器上。

我的选择是：

1. 使用UDP多播/广播（例如，emcaster）
将事件广播到所有服务器
2. 使用TCP
将服务器完全互连
3. 发送所有事件的中央服务器以及所有工作人员 服务器连接到那个
4. [3]但有几层形成一棵树

我的诱惑是与[1]一起使用，因为它很简单，并且可能适用于多达20-30个节点。关于N的不同范围的最佳策略是否存在共识，其中N是节点数？

Answer 1

您应该查看zeromq指南。如果您需要udp广播来补偿丢失的数据包，那么zeromq将是一个很好的方法。它是一个轻量级的消息传递接口，旨在提高效率。这是C（库语言）和python中的介绍指南：

C：http://zguide.zeromq.org/page:all
Python：http://zguide.zeromq.org/py:all

这些示例也被翻译成C ++，C＃，CL，Erlang，F＃，Felix，Haskell，Java，Objective-C，Ruby，Ada，Basic，Clojure，Go，Haxe，Node.js，ooc的包装器， Perl，Scala，Lua，Haxe和PHP。

---- ---更新

很抱歉，链接似乎没有将所有代码示例从C更改为python，但您可以获得备用语言翻译...

专门针对您的推送拓扑，他们有一个关于如何在zeromq中实现pub / sub的页面：http://www.zeromq.org/whitepapers:0mq-3-0-pubsub

Answer 2

如果不了解更多细节，很难建议哪种方法是最好的策略。也许可能有用的是列出每个项目要考虑的一些事项：

1. UDP广播

   • 如您所述，这将是最容易实施的。
   • 为什么限制20-30个节点？限制是否符合您的要求？如果是这样，那就去吧。
   • UDP广播消息是否可能受到火元素等NW元素的影响？

2. 互连的TCP NW

   • 此选项似乎可能是配置和维护一致IP地址列表的维护噩梦。
   • 特定服务器如何知道将消息发送到的下一个服务器？这种逻辑可能变得复杂。

3. 中央服务器

   • 我个人认为这是[1。]
   之后的第二种可能解决方案
   • 这个中央服务器可能需要一些非常复杂的处理来知道在哪里发送消息。

4. 带树的中央服务器

   • 配置和维护噩梦
   • 使用此解决方案，4中提到的复杂逻辑会更糟。

就个人而言，我会考虑每种方法的优缺点，并考虑每种解决方案如何满足要求。希望这一课能让决策变得更容易。

Answer 3

尝试在中间使用一些已经发明的轮式开源软件。我当时可以想到一个，但我900％肯定市场上会有帐篷的帐篷。

Redis是一个很好的例子，可扩展，快速，并且已经有很多玩具，插件和客户端。使用或多或少3行代码，您可以实现发布者/订阅者。

Answer 4

您的客户是否具有独特的可识别性？如果是这样，您可以跨各种服务器对它们进行分区，并将要连接到哪个服务器的逻辑（UNIQUE_ID mod N？）集成到每个客户端/服务器中

Answer 5

我会选择＃3 - 中央服务器。它可以比其他选项更好地扩展，并且可以设计为像路由器表一样运行，以确保仅在必要时为服务器生成流量。可以即时添加其他服务器节点。

出于好奇，你用什么语言开发了服务器？