3

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

如果我将来需要扩展，RPC 的东西很容易，比如 Web 基础设施，我只需添加更多节点和负载平衡。

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

我的选择是：

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

我倾向于选择 [1]，因为它很简单，并且可能适用于多达 20-30 个节点。对于不同范围的 N（其中 N 是节点数）的最佳策略是什么，是否达成共识？

4

5 回答 5

4

您应该查看 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

于 2012-09-28T02:05:36.823 回答
1

在不了解更多细节的情况下，很难建议哪种策略是最佳策略。也许可能有帮助的是列出每个项目要考虑的一些事项：

  1. UDP广播

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

  2. 互连 TCP NW

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

  3. 中央服务器

    • 就个人而言，我认为这是 [1.] 之后的第二种可能的解决方案。
    • 这个中央服务器可能需要一些相当复杂的处理才能知道将消息发送到哪里。

  4. 有树的中央服务器

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

就个人而言，我会查看每种解决方案的优缺点，并考虑每种解决方案如何满足需求。希望这一课能让你更容易做出决定。

于 2012-09-19T14:43:30.467 回答
1

尝试在中间使用一些已经发明的开源软件。我当时只能想到一个，但我 900% 肯定市场上会有成堆的模仿者。

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

于 2012-09-27T20:12:04.010 回答
1

您的客户是唯一可识别的吗？如果是这样，您可以将它们划分到各个服务器上，并将连接到哪个服务器的逻辑（UNIQUE_ID mod N？）集成到每个客户端/服务器中

于 2012-09-28T01:32:02.033 回答
0

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

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

于 2012-09-28T01:20:56.547 回答