3

我目前正在运行一个发布/订阅系统，它允许客户端连接到中央消息路由守护进程，订阅一系列消息，然后开始聊天。路由守护进程跟踪和维护每个订阅者感兴趣的消息（基于一个简单的标签），并在每个订阅者生成它们时传递适当的感兴趣消息。本质上，每个连接都被认为是潜在的发布者或订阅者，并且通常两者，守护进程根据需要处理路由和传递。

例如，三个客户端都连接并订阅他们感兴趣的消息标签（MT）：

Client 1(C1) subscribes to MT => 123
Client 2(C2) subscribes to MT => 123 & 456
Client 3(C3) subscribes to MT => 123 & 456 & 789

C1 produces MT 456: daemon delivers a copy to C2 and C3
C2 produces MT 123: daemon delivers a copy to C1 and C3 (not self)
C3 produces MT 999: daemon delivers it to none (nobody subscribed)

ZeroMQ 在与一位同事的讨论中提出，经过几天的修补后，我认为我没有看到实施/替换我们目前拥有的系统的正确模式。此外，我想使用 EPGM 来利用多播收益并消除我目前拥有的基于 TCP 的守护进程，即中间的猴子。

有什么建议么？

4

1 回答 1

2

使用 ZeroMQ 可以设计出类似的系统。基本上，您可以创建一个绑定两个套接字的守护进程：PULL 用于接收来自客户端的消息，而 PUB 用于发布消息。每个客户端都将SUB 套接字和 PUSH 套接字连接到服务器。EPGM 可能用于 PUB/SUB 套接字，但 PUSH/PULL 套接字仍然是 TCP。

这种设计的缺点是主题过滤和丢弃自己的消息必须手动完成。例如，您可以创建三部分的消息：

  1. 话题
  2. 生产者标识
  3. 邮件正文

客户端应立即逐部分阅读消息，丢弃它不感兴趣的消息尾部。指南的本节详细描述了使用 PUB/SUB 消息信封：http: //zguide.zeromq.org/page :all#Pub -子消息信封。客户端过滤不应影响性能，因为无论如何都必须将所有 PGM 数据包传递给所有连接的接收器。

这种设计非常简单但非常有效。它不包括可靠性、高可用性、故障恢复和其他重要方面——这些都可以使用 ZeroMQ 并在指南中介绍。ZeroMQ 的最佳特性可能是能够从简单的东西开始，并根据需要添加功能，而无需痛苦和/或进行重大重写。

指南的“可靠的 Pub-Sub（克隆模式）”一章中描述了非常相似的东西（加上状态快照、可靠性等等）：http://zguide.zeromq.org/page: all#toc119

顺便说一句，也可以设计 p2p 系统，中央守护进程仅用作名称服务器，但肯定会更复杂。

于 2013-04-23T22:46:04.073 回答