假设您有 2 台服务器，每台服务器有 8 个 CPU 核心。
每个服务器运行 8 个网络服务，每个网络服务承载任意数量的长寿命 TCP/IP 客户端连接。
客户端向服务发送消息。
服务做一点事根据消息，并可能将状态变化通知给 N>1 个客户端。
当然，这听起来像僵尸网络，但事实并非如此。考虑一下 IRC 如何与 c2s 和 s2s 连接以及 s2s 消息中继配合使用。
- 这些服务器位于同一个数据中心。
- 服务器可以通过私有 VLAN @1GigE 进行通信。
- 消息大小小于 1KB。
您如何协调哪个主机上的哪些服务应该接收消息并将其转发给连接的客户端以获取状态改变消息？
有无数种方法可以有效地解决这个问题。
- AMQP（RabbitMQ、ZeroMQ 等）
- 传播工具包
- 所有服务之间有 N^2 个连接（不好）
- 哎呀，甚至运行 IRC！
- ...
我正在寻找一个解决方案：
- 也许利用了只有一个小的封闭簇这一事实
- 易于管理
- 规模很好
- 是“愚蠢的”（没有奇怪的边缘情况）
你有什么经历？
你有什么建议吗？
谢谢！
答案1
如果：
- 您反对使用现有的中间件总线。
- 您的交换机支持 IGMP 监听（基本上，您购买的任何 Cisco 交换机都会默认启用此功能 - 我认为 Dell/HP 交换机也会有此功能）
- 你们都在同一个 VLAN 上
然后 IPv4 多播将立即发挥作用，完全满足您的要求。接收方订阅频道（多播组），发送方将 UDP 数据报发送到组的多播地址，交换机确定谁获得了什么。它使您的网络设备能够智能地处理消息路由。
如果您的交换机没有支持 IGMP 监听，那么它将把（以太网）多播帧视为广播，并将它们发送到 VLAN 上的所有主机，无论主机是否要求它们。因此，即使主机操作系统在数据包到达任何应用程序之前将其丢弃，您也会堵塞交换机和主机之间的管道。
如果它们不都在同一个 VLAN 上，您仍然可以使用 IPv4 多播，但是您必须对设备进行更多配置才能使其运行，但它仍然可以正常工作。